<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blog · Webdex</title><link>https://webdex.co.uk/blog/</link><description>Notes on software delivery, architecture and AI-augmented engineering.</description><language>en-GB</language><lastBuildDate>Thu, 05 Nov 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://webdex.co.uk/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>The front door</title><link>https://webdex.co.uk/blog/librechat-front-door/</link><guid isPermaLink="true">https://webdex.co.uk/blog/librechat-front-door/</guid><pubDate>Thu, 05 Nov 2026 00:00:00 +0000</pubDate><category>AI-Augmented Engineering</category><category>Architecture</category><category>System Design</category><description>&#10;Introduction A chat application is the smallest part of a chat deployment.&#10;I have written that sentence in notes three times since September, and each time it arrived from a different side. This time it was the model list. The picker offers two models, and both are named combos the router serves. The list is typed by hand into a configuration file because discovery is switched off for that endpoint. Switch it on and the app asks the router what it has; the router answers with 56 model ids — the two combos, and 54 provider models sitting behind them — and the picker stops being a short list of things this deployment is for and becomes a catalogue of everything the estate could reach. So discovery stays off, the list is curated, and it will go on naming two combos after one of them is renamed, with no warning when the day comes.&#10;</description></item><item><title>One endpoint, many providers</title><link>https://webdex.co.uk/blog/one-endpoint-many-providers/</link><guid isPermaLink="true">https://webdex.co.uk/blog/one-endpoint-many-providers/</guid><pubDate>Thu, 29 Oct 2026 00:00:00 +0000</pubDate><category>AI-Augmented Engineering</category><category>Architecture</category><category>System Design</category><description>&#10;Introduction At about 11:00 PM an editor agent declined a directory. Not the repository: a subtree, a few hundred thousand tokens of code it had already read once that day, in a session that had been going for an hour. It said the model&amp;rsquo;s context was 128,000 tokens, so it would summarise first and work from the summary.&#10;</description></item><item><title>A shared OpenCode configuration</title><link>https://webdex.co.uk/blog/shared-opencode-config/</link><guid isPermaLink="true">https://webdex.co.uk/blog/shared-opencode-config/</guid><pubDate>Wed, 28 Oct 2026 00:00:00 +0000</pubDate><category>AI-Augmented Engineering</category><category>MCP Servers</category><category>Architecture</category><description>&#10;Introduction A working agent setup is easy to build and hard to hand over. It accumulates in one person&amp;rsquo;s home directory: an agent prompt here, a permission rule there, a skill that encodes what the team agreed about tests. The second machine gets a copy that is already a week old, the second person gets a screenshot and a list of things to paste, and six weeks later nobody can say which version is current.&#10;</description></item><item><title>Evaluating RAG systems</title><link>https://webdex.co.uk/blog/evaluating-rag-systems/</link><guid isPermaLink="true">https://webdex.co.uk/blog/evaluating-rag-systems/</guid><pubDate>Tue, 27 Oct 2026 00:00:00 +0000</pubDate><category>RAG</category><category>Evaluation</category><category>AI-Augmented Engineering</category><description>&#10;Introduction A retrieval-augmented generation system is the easiest AI feature to demo and one of the harder ones to keep honest. You point it at a corpus, ask a question the corpus answers plainly, and it answers; whoever is watching nods. The next question, from somebody who actually works with the material, comes back wrong in a way nobody notices until it matters: a fluent paragraph citing a page that says something else, an answer silently missing the one document that mattered, a confident figure assembled from two versions of the same record.&#10;</description></item><item><title>MCP servers in production</title><link>https://webdex.co.uk/blog/mcp-servers-in-production/</link><guid isPermaLink="true">https://webdex.co.uk/blog/mcp-servers-in-production/</guid><pubDate>Mon, 26 Oct 2026 00:00:00 +0000</pubDate><category>MCP Servers</category><category>AI-Augmented Engineering</category><category>Architecture</category><description>&#10;Introduction The first MCP server I wrote took an afternoon: one file, a handful of functions, a client configuration pointing at a local path, and a model that could suddenly reach something real. As a demo it convinced, because the argument that a language model can call a well-described function is not a hard one to win any more.&#10;</description></item><item><title>Micro Mono Modu</title><link>https://webdex.co.uk/blog/micro-mono-modu/</link><guid isPermaLink="true">https://webdex.co.uk/blog/micro-mono-modu/</guid><pubDate>Sun, 25 Oct 2026 00:00:00 +0000</pubDate><category>Microservice</category><category>Monolith</category><category>Architecture</category><category>Repository</category><category>System Design</category><description>Introduction Software engineering is hard and volatile. As software craftspeople we adapt constantly to changing business needs and strategy. On top of that, we have our own technical needs to cater for. Beyond choosing a tech stack — which languages, frameworks, infrastructure and open-source tools to lean on — pinning down the right architecture from the get-go can be an absolute conundrum. In this post we look at the different scenarios a system passes through and how to make the best of each, as well as the decisions that might paint us into a corner too early.&#10;</description></item></channel></rss>