In March we let an agent run a mechanical refactor across a 2,400 file template repo: replace every physical CSS property with its logical equivalent. It touched 340 files, the build passed, visual regression on the LTR demos was clean, and we merged it. Two days later an RTL demo rendered with its sidebar overlapping the footer, because the agent had helpfully “simplified” three padding-inline declarations back into shorthand that dropped a value. Nothing in our test suite checked direction. The agent wasn’t wrong, exactly. Our verification was.

That is the whole story of ai developer tools in 2026 compressed into one incident. The models got good enough that the bottleneck moved. It is no longer “can the machine write the code”, it’s “can you prove the code it wrote is correct in under thirty seconds”. Most teams still haven’t done the boring work that makes the exciting tools safe.

So this is not a listicle. It’s the set of tools that survived a year of client work, the ones we removed, and the rules we wrote after they bit us.

Your verification loop is the real product

An agent working with a fast, strict feedback loop behaves like a competent mid-level developer. The same agent with a slow or permissive loop behaves like someone pattern-matching from Stack Overflow with their eyes closed. The model is identical. The loop is everything.

Concretely, before you adopt anything else, get these under control:

• Typecheck under 10 seconds incrementally. tsc --incremental with a warm cache, or project references if the repo is large enough to need them.
• A unit test subset the agent can run in isolation. Vitest’s related mode, or pytest with a path filter. Running the full suite on every iteration wastes minutes and tokens.
• Formatter and linter as a single non-interactive command with a non-zero exit code. Agents read exit codes far more reliably than they read prose.
• A smoke check that actually renders something. For front end work this is the one most teams skip, and it’s the one that caught our RTL bug after we added it.

{
  "scripts": {
    "check": "pnpm typecheck && pnpm lint && pnpm test:unit",
    "typecheck": "tsc -p tsconfig.json --noEmit --incremental",
    "test:unit": "vitest run --changed HEAD~1 --passWithNoTests",
    "test:rtl": "playwright test --grep @rtl"
  }
}

One command, one exit code. We put pnpm check in the agent instructions and told it not to report completion until that command passes. Hit rate on first-pass merges roughly doubled, from “about a third of tasks” to “most of them”. No model change involved.

The AI developer tools that earn a permanent slot

Four categories survived. Everything else rotated out.

Inline completion

Still the highest return per dollar, and the least discussed now that agents are fashionable. It’s a typing accelerator for code you already know how to write: DTOs, switch arms, repetitive Tailwind-ish class strings, test fixtures. Where it hurts is unfamiliar APIs. It will confidently complete a method that does not exist on that SDK version. The rule we give juniors: accept completions for shapes you can verify by reading, never for APIs you’d have to look up.

An agentic CLI wired to the loop

Claude Code, Codex CLI, Aider, Cursor’s agent mode: the differences matter less than people argue. What matters is that the tool can read files, run your check command, read the failure, and iterate without a human pressing a button each cycle. This is where real work gets done: migrating a component library off a deprecated prop API, adding idempotency keys to twelve handlers, converting a JS build config to TS.

Codebase-wide semantic search

Underrated. On a large legacy WordPress or Bootstrap codebase, “where is the thing that decides whether the mini-cart renders” takes a human 20 minutes of grep and guesswork. A decent embedding index answers it in one query with three candidate files. We don’t use this to generate code. We use it to orient before we write any.

Mechanical migration at volume

Repetitive, verifiable, boring, and large. Converting hundreds of demo pages to CSS logical properties is a perfect fit, which is exactly what we did across Canvas, and why we wrote up what actually breaks in RTL and how logical properties fix it. The task is well specified, the correctness criterion is visual plus mechanical, and no human wants to do it. Deterministic codemods still beat an agent when the transform is expressible in ts-morph or jscodeshift. Use the agent to write the codemod, not to do the edits.

What we cut

Automated PR review bots lasted four months. The findings were not wrong so much as undifferentiated: 14 comments per PR, two of them useful, and engineers learned to scroll past all 14. We now scope review bots to specific paths only (migrations, auth, anything that signs or verifies a request) and the signal came back. We also stopped generating test suites wholesale. AI-written tests tend to assert what the code currently does, which locks in bugs and gives you a green suite that proves nothing. The exception is characterisation tests on untested legacy code you’re about to change, where “freeze current behaviour” is precisely what you want.

Context engineering beats model shopping

Most complaints about bad output are really complaints about bad context. The fix is committed to the repo, not typed into a chat box.

# AGENTS.md

Commands

Verify everything with: pnpm check (typecheck + lint + unit)
RTL visual checks: pnpm test:rtl (required for any CSS change)

Hard rules

Bootstrap 5.3 utilities first. Do not add custom CSS if a utility exists.
Logical properties only: margin-inline-start, not margin-left. No exceptions.
No new runtime dependencies without asking.
Do not edit files under /vendor, /dist or .min.
Form endpoints go to WebForms; do not scaffold an Express server.

Conventions

PHP: WordPress coding standards, scw_ prefix on all globals.
Tests live beside source as *.test.ts.

Keep it under roughly 150 lines. Past that, adherence drops noticeably. We’ve watched agents ignore rule 40 of 60 in a long file while following the first ten. Prune it like code. Delete rules that the linter can enforce instead, because an exit code is a stronger instruction than a sentence.

On MCP servers: useful, and easy to overdo. Each connected server injects tool definitions into every request, which eats context and raises cost. We run three at most on a given project, typically a database read-only server, a docs or issue tracker server, and a browser automation one. Connecting nine servers “just in case” measurably degrades reasoning on the actual task.

Running agents in anger

Parallelism is where agentic work stops feeling like a demo. The pattern that works is one worktree per task, so two or three agents never fight over the same working directory.

# One isolated checkout per task, shared git history, separate node_modules
git worktree add ../repo-rtl-fix -b fix/rtl-shorthand
cd ../repo-rtl-fix && pnpm install --prefer-offline

Run the agent here, sandboxed to this directory with no network
except your package registry. Then review the diff like any human PR.

Non-negotiables we landed on after a few scares:

• No write access outside the worktree. Deny by default, allowlist the registry.
• A tool-call ceiling. If a task hasn’t converged in around 40 calls, it’s thrashing. Kill it and re-scope the prompt rather than letting it spend another dollar rediscovering the same failing test.
• Human review on every diff, with a hard blocklist. Authentication, payments, DB migrations and anything that changes a public API contract get human-authored code. The reasoning is in our piece on versioning webhook payloads without breaking consumers: an agent optimises the diff in front of it, and it has no concept of the five integrators who will silently break at 3am.
• Commit messages say the model and the prompt intent. When you bisect a regression six weeks later, you want to know this hunk came from an agent and what it was told.

Where it still reliably fails

Judgement, taste and anything whose correctness lives outside the repo.

Accessibility is the clearest case. Agents produce syntactically valid ARIA with enthusiasm and will happily add role="button" to a div instead of using a button, or wire up a focus trap that traps keyboard users permanently. Axe passes. The component is unusable. Same story with performance: an agent will cheerfully add a 90KB dependency to format a date.

Design decisions are worse. Ask for a hero section and you get a centred headline, a gradient, two buttons and a stock-photo placeholder, every time, because that’s the mode of the training data. Novel layout and genuine information hierarchy need a person who has watched users fail to find the pricing link.

Anything requiring knowledge of a system boundary is in the same category: queue semantics, rate limits on an third-party API, how your CDN caches Vary. The model does not know your infrastructure, and it will not tell you that it doesn’t.

Cost and tracing, because the bill is real

Token spend behaves like CI minutes: invisible until it isn’t, then a line item someone asks about. Two numbers are worth tracking per engineer per week: total spend, and cost per merged PR. The second one is the interesting one. A task that costs four dollars and ships is fine. A task that costs eleven dollars across six attempts and gets rewritten by hand is a signal that the scope was wrong or the loop is too slow.

If you’re shipping LLM features to users rather than just using them internally, the same instrumentation applies with higher stakes, and we covered the tracing and regression side of that in observability for LLM features. Internal tooling spend deserves a fraction of that rigour. A weekly dashboard is enough.

The stack we actually run

Per project, nothing exotic: inline completion in the editor for every engineer, one agentic CLI for scoped multi-file tasks, semantic codebase search for orientation, a committed AGENTS.md, two or three MCP servers, and a check script that runs in under 30 seconds. Review bots scoped to risky paths only. Token spend reported weekly.

What we deliberately do not do: auto-merge, AI-generated commit messages (they describe the diff, which you can already read), chat-driven architecture decisions, and model-hopping. We re-evaluate models quarterly and otherwise leave it alone, because the switching cost in re-tuned prompts and re-learned failure modes usually outweighs the few percent of benchmark difference. Specialised cases do exist: for SEO and content-shaped automation the tradeoffs are different enough that we wrote them up separately in AI for technical SEO.