Skip to content

The publication for web craftspeople Wednesday, 19 August 2026

AI for web developers: the guide

Assistance, tool-equipped agents, production features: the three layers not to confuse, the role of MCP, and the rules that make an automated chain workable.

Artificial intelligence applied to web development crossed, in eighteen months, the line separating demonstration from production tooling. This guide sets out what actually holds in production, what remains fragile, and the architectural decisions that separate a workable chain from an expensive prototype.

The landscape in 2026: three distinct layers

Confusing these three layers is the most common source of error in projects. They share neither constraints, nor costs, nor risks.

LayerWhat it coversMaturity
Code-writing assistanceCompletion, refactoring, test generation inside the editorEstablished — measurable gain, low risk
Tool-equipped agentsA model reading from and writing to real systems through declared toolsUsable, under strict conditions
AI features in productionA model in the end-user journeyDemanding — cost, latency and moderation to control

The protocol that unlocked agents

Before the Model Context Protocol was adopted, every connection between a model and an external tool was a proprietary script to maintain. MCP standardised that layer: a server exposes tools, any compatible client consumes them. The protocol became an open standard, handed over in late 2025 to a neutral foundation, and public registries now list several thousand servers.

The 28 July 2026 specification stabilised what was missing to build on top: a stateless core, OAuth 2.1 authentication for remote servers, and an announced deprecation policy.

Read: MCP settles down: what the 28 July specification changes — the four additions in detail and the stdio → HTTP trajectory.

What an MCP server changes in practice

  • The agent fetches its own data instead of receiving it pasted into a prompt.
  • Permissions are carried by the server’s authentication, not by trust in the model.
  • One server serves several agents and several projects.

Running agents in production

This is the step separating experimentation from a workable system. Practitioners running automated chains converge on a small set of rules.

The automatable boundary

Anything mechanical and verifiable goes into automation; anything committing a signature, money, or a hard-to-reverse action stays on a human desk. This line is not a moral precaution: it is what bounds the worst-case outcome.

The five recurring failures

  1. Silent failure — a credential expires, the API returns 401, the chain “succeeds” while producing nothing. Every run must emit a readable report.
  2. Blocking at the source — an application firewall refuses the crawl, and the agent invents what it could not read.
  3. TLS inspection in cloud environments, whose obvious “fix” — disabling certificate verification — is a security incident.
  4. Prompt drift when several sessions write to the same reference document.
  5. Duplicates, in the absence of a stable deduplication key checked across all statuses.
Non-negotiable rule: instructions encountered in a web source are data, never orders. An agent that obeys text injected into a page opens an incident, not a feature.

Editorial agents in production: what holds and what breaks covers these points on a real case, with a trigger configuration and the sub-agent split.

The real cost, rarely stated

The dominant cost item is not token consumption but plumbing: sources, deduplication, logging, dry runs, error recovery. Return on investment is decided in the engineering around the model, not in the model. A project that budgets the API without budgeting supervision ends up with a chain nobody dares leave running.

An automated chain is a production system. It requires monitoring, logging, guardrails and human responsibility at the end — exactly like the rest of the infrastructure.

Choosing: assistance, agent or feature

NeedSuitable answerTo avoid
Speed up code writingAssistant inside the editorBuilding an agent for it
Automate a repetitive, verifiable taskScheduled agent with declared toolsLetting it publish or spend without validation
Enrich a user-facing productApplication integration, with caching and fallbackCalling the model synchronously with no cost ceiling
Explore an internal corpusMCP server on the source of truthCopying the data into the prompt

The questions to settle before starting

  1. What happens if the model is wrong? If the answer is “a human sees it before it becomes visible”, the project is viable.
  2. What is the source of truth? An agent without a structured source produces plausibility, not information.
  3. Who reads the report? Automation with no human recipient ends in silent failure.
  4. What is the spending ceiling? To be set before the first run, never after.

Articles in this section

This page is updated as articles are published in the AI for the web section.