Field notes — the blog

Notes from inside the system.

Specific write-ups on decisions that moved the needle: architecture trade-offs, delivery pipelines, and leading engineers who are better than you at their part of it.

              {{ totalPosts }} notes
              {{ totalMinutes }} min total
              Monthly
            

/

                Latest
                {{ featured.date }}
                {{ featured.cat }}
                {{ featured.read }}
              

{{ featured.title }}

{{ featured.excerpt }}

Read the note →

// before → after
{{ row.text }}

{{ listHeading }}

{{ resultCount }}

                {{ post.cat }}
                {{ post.date }}
              

{{ post.title }}

{{ post.excerpt }}

{{ post.read }}

Nothing matches that.

Try a different term, or clear the filters.

The architect's dispatch

One note a month. Nothing else.

A single deep write-up on a system I worked on: the trade-off, the numbers, what I'd do differently.

            {{ article.cat }}
            {{ article.date }}
            {{ article.read }}
          

{{ article.title }}

{{ article.excerpt }}

{{ part.text }}{{ part.text }}{{ part.text }}

{{ b.alt }} — {{ b.caption }}

{{ b.label }}

{{ h.text }}

{{ cell.text }}

{{ b.label }}

{{ link.label }} {{ link.note }} {{ link.host }}

{{ b.caption }}

{{ b.text }}

{{ b.text }}

{{ b.label }}

{{ line.text }}

{{ item.no }}

{{ part.text }}

{{ part.text }}

{{ part.text }}

Takeaways

▖ {{ t }}

Tags

{{ tag }}

← Newer

{{ prevPost.title }}

Older →

{{ nextPost.title }}

Related notes

{{ post.cat }}

{{ post.title }}

{{ post.read }}

Autonomous dev agents in production: what breaks after the demo

AI · Oct 2026 · 16 min read

Inline autocomplete was a convenience: you hit Tab and read two lines. Autonomous agents—Cursor Composer, Claude Code, Copilot Workspace, and terminal loops—are delegation: they read the repo, edit eight files, run the tests, and hand you a pull request. Once five engineers run them daily, the bottleneck doesn't vanish; it moves into code review, architecture divergence, and hallucinated dependencies. Here is what actually happens in production, the four traps that follow, and how the SDLC has to change.

Over the last eighteen months, developer tooling crossed an invisible line. We stopped arguing about whether an LLM can autocomplete a ternary operator or scaffold a boilerplate controller. That was the autocomplete era: the developer held the keyboard, the model whispered suggestions into the editor buffer, and the cognitive center of gravity stayed firmly in the human's head.

The current era is not autocomplete. It is delegation. Tools like Cursor Composer, Claude Code, GitHub Copilot Workspace, and bespoke terminal agents running on the Model Context Protocol do not wait for you to type. You give them an issue ticket or a failing test, step away for coffee, and return to find an agent that has ripgrepped your codebase, modified six files, executed your test runner, fixed its own syntax errors, and staged a git commit.

In isolation, on a greenfield feature or an individual laptop, the demo feels like magic. But when a team of twenty engineers begins running autonomous agentic loops against the same production codebase every morning, the nature of software engineering changes in ways that vendor keynotes rarely mention. The bottlenecks do not disappear. They move.

A diagram comparing the high-speed autonomous agent generation loop on the left with the human code review bottleneck on the right. On the left, an agent takes an issue, reads context, and cycles through edit, test, and auto-correct in 45 seconds until tests pass. It then emits a 600-line pull request. On the right, the pull request lands in the human review queue, where review time balloons to 45 minutes, review fatigue sets in, and silent regressions slip through. A caption notes that generation got cheap while verification remained human. — Generation accelerated by 10x; human verification did not. The queue formed in front of whoever has to approve the pull request.

Where autonomous agents genuinely deliver

It is worth being fair before diagnosing the pathology, because teams dismissive of agentic workflows are leaving immense leverage on the table. In three distinct areas, autonomous coding agents consistently outpace human typing speed by an order of magnitude:

Repetitive migrations and systematic refactoring: upgrading an ORM across fifty model definitions, renaming an API signature across eighty call sites, or converting legacy styled-components to Tailwind. When the transformation rules are unambiguous and the compiler provides strict feedback, an agent handles in fifteen minutes what used to eat an entire sprint.
High-density test harness bootstrapping: writing the first thirty unit tests for an untested calculation module. Human engineers cut corners on boundary checks and null branches out of fatigue. An agent given a clear interface contract will churn through edge cases, invalid inputs, and unicode traps without losing patience.
Incident reproduction from telemetry: handing an agent a Sentry stack trace, a production log excerpt, and asking it to write a failing reproduction test. By searching symbol definitions and tracing call graphs with ripgrep, agents regularly pinpoint offending lines and recreate the bug scenario faster than an on-call engineer clicking through tabs.

These wins are real. But notice what they share: they all operate within tightly bounded problem spaces with immediate, mechanical feedback loops. The trouble begins when agents are unleashed on open-ended feature work.

The four production traps

After watching multiple teams integrate agentic workflows into production services over the past two quarters, four failure modes consistently appear once the initial excitement settles.

1. The review debt crisis and review fatigue

I wrote previously about how the bottleneck moved to review. Autonomous agents turn that bottleneck into a full-blown crisis. Writing six hundred lines of syntactically valid, lint-passing code used to represent two days of focused thought. An agent emits it in forty-five seconds.

Reviewing that code—verifying security assumptions, checking for subtle race conditions, verifying that it aligns with domain boundaries—still takes a senior engineer thirty to forty minutes. When developers submit three agent-generated pull requests before lunch, the review queue drowns.

Generation cost collapsed to zero. Verification cost remained stubbornly human. The predictable result is rubber-stamping.

Reviewers subconsciously adapt to the volume. They glance at the green CI badge, verify that unit tests pass, skim the diff, and click Approve. Subtly flawed logic, leaky abstractions, and redundant code enter the main branch at five times the historical rate. The team feels faster because tickets move to 'In Review' instantly, but the median time a PR sits in review jumps by 400%.

2. Architecture erosion and helper sprawl

An autonomous agent has no long-term mental model of your architecture. It does not know that your team spent three months migrating away from an old caching layer, or that date calculations must flow through a centralized financial timezone helper. It sees only the tokens in its immediate context window.

When an agent needs to format a currency string, validate an email address, or parse an authorization header, it does not browse your shared internal libraries unless explicitly pointed to them. Instead, it hallucinates a clean, plausible private utility function right inside the file it is editing. Repeat this across thirty pull requests, and your codebase accumulates seven conflicting implementations of the exact same business logic.

Worse, agents treat existing code as canonical truth. If your repository contains five-year-old legacy code written before your team adopted current standards, the agent will faithfully imitate those outdated patterns in brand-new features, quietly undoing years of architectural hygiene.

3. The infinite local optimum trap

Because agents run in a self-healing loop—editing code, running tests, reading error logs, and editing again—they are relentlessly focused on one goal: achieving an exit code of 0. But passing tests does not mean correct design.

When a human engineer encounters a failing integration test, they pause. They consider whether the failure exposes a fundamental flaw in the design: *Is this boundary misplaced? Should this event be asynchronous instead?* An agent does not pause. It patches. If a test fails because a database record is missing, the agent will add a defensive if (!record) return defaultValue; fallback, or mock out a service, or monkey-patch a global state variable.

It converges on a mathematically local optimum: the test suite turns green, the compiler is happy, but the resulting design is an incoherent maze of defensive band-aids that no human architect would ever approve.

4. Supply chain blindspots and prompt injection

The moment you grant an agent terminal access to run npm test or install tools, security boundaries become acute. As shown in the s1ngularity malware analysis, an agent that reads untrusted text can be steered into executing destructive actions or reading local environment files.

In production agent loops, two specific vulnerabilities emerge:

Package hallucination and typosquatting: an agent attempting to solve an obscure cryptographic or encoding task will occasionally import a package name that sounds authentic but does not exist on npm or PyPI. Attackers actively monitor and register common model hallucinations, waiting for an automated agent to run npm install <hallucinated-package> during its build cycle.
Credential leakage via local shells: developers running terminal agents often leave their personal AWS credentials, database URLs, and GitHub personal access tokens loaded in ambient environment variables. When the agent is prompted to debug a network failure, it may dump process environment tables into prompt context or temporary logs.

This is precisely why runtimes like NVIDIA's OpenShell place the agent inside a kernel-enforced sandbox where credentials and network access are managed outside the agent's reach.

A four-gate defensive architecture for running autonomous coding agents safely in production. Gate 1 is Spec as Code: interface contracts, OpenAPI schemas, and strict file allowlists. Gate 2 is the Hermetic Sandbox: containerized execution, stripped environment secrets, and strict egress filtering. Gate 3 is Structural Guardrails: dependency freeze, domain boundary linting, and diff caps under 250 lines. Gate 4 is Intent Review: reviewing prompts and design choices rather than just syntax, enforcing developer ownership. Sequential animations highlight each gate in order. — When writing code costs nothing, safety cannot rely on developer willpower. Every gate must be mechanical and enforceable in CI.

How the SDLC must change: the four defensive gates

If you treat an autonomous agent like an experienced senior colleague who understands nuance, you will suffer. If you treat it like an extraordinarily fast, tireless junior contractor who has no institutional memory and must be surrounded by rigorous boundaries, it will transform your team's velocity.

To make autonomous dev agents viable in production, engineering organizations must implement four non-negotiable defensive gates:

Gate 1: Spec as Code (Input contracts)

Prompting an agent with casual conversational English like *'Add webhook retries to billing'* invites disaster. Production agent tasks must begin with an explicit specification artifact checked into the repository or passed via a structured configuration file:

# Task: Webhook Retry Pipeline
## Allowed Files
- src/billing/webhooks/dispatcher.ts
- src/billing/webhooks/retryQueue.ts
- tests/billing/webhooks/dispatcher.test.ts

## Invariants & Rules
1. MUST use existing ExponentialBackoff helper in @infra/resilience.
2. MUST NOT add new third-party dependencies to package.json.
3. Maximum retry count is 5; dead-letter after exhaustion.
4. All database queries must run through the existing unit of work.

Defining the interfaces, the allowed file paths, and the exact constraints before invoking the agent prevents 80% of context drift and architectural duplication.

Gate 2: Hermetic sandboxing

Never run autonomous coding agents with unrestricted access to your host machine's root filesystem or ambient environment variables. Run agent loops inside an isolated Docker container, a devcontainer, or an OpenShell sandbox. Strip all live cloud API keys from the session, and restrict outbound network calls strictly to approved internal package registries and test dependencies.

Gate 3: Structural linting and diff budgets

Because human reviewers cannot catch every subtle architectural divergence in large diffs, automate the boundaries:

Dependency lockfile verification: CI must fail automatically if package.json or go.mod was modified without an explicit approved dependency label.
Architectural boundary linting: tools like ESLint plugin boundaries, ArchUnit, or TypeScript project references must mechanically enforce that domain modules do not import forbidden internals (e.g., billing code cannot reach directly into reporting tables).
Strict diff budgets: enforce a hard team rule that no agent-generated pull request may exceed 250 lines of changed code. If a task requires 600 lines, decompose it into three sequential, reviewable stages.

Gate 4: Intent review and developer accountability

The team's code review culture must adjust to a single golden rule:

The engineer who submits the pull request owns 100% of the diff. 'The agent wrote that' is never an acceptable response in a post-mortem.

Require pull request descriptions to include the original prompt, the reasoning chain or agent plan, and an explanation of why the agent's architectural approach was accepted. Reviewers should review the *intent and trade-offs* first before reading the syntax.

Comparing the three eras of dev assistance

How developer assistance has evolved
Attribute	Inline Autocomplete (2022)	Unbounded Agent Loops (2024)	Defensive Agentic SDLC (2026)
Unit of work	Line or statement	Whole pull request	Scoped contract / module
Execution loop	Human accepts / edits	Agent loops on tests unattended	Agent loops within sandboxed container
Primary bottleneck	Human typing speed	Human PR review queue	Spec authoring & intent verification
Failure mode	Minor syntax typos	Helper sprawl & silent regressions	Over-constrained specs
Accountability	Clear human ownership	Diffused ('the AI did it')	Strict human submitter ownership

The practical playbook for teams

If your engineering organization is adopting tools like Cursor Composer or Claude Code today, enforce these four operational rules:

1. Write the tests first, by hand: write the acceptance criteria and the failing test before calling the agent. Give the agent a clear target rather than asking it to invent both the implementation and its own verification.
2. Trash the branch after fifteen minutes: if an agent loops for fifteen minutes and starts producing convoluted monkey-patches, do not try to untangle its work. Delete the branch, refine your spec prompt, and run it again.
3. Ban raw PR dumps: forbid developers from opening PRs with raw agent commit messages like 'Fix tests and update types'. The author must write a coherent summary explaining what the agent changed and why.
4. Optimize codebases for readability: agents thrive in repositories with explicit type systems, small files under 300 lines, hermetic fast-running test suites, and clean directory hierarchies. Codebases that are pleasant for humans are 10x more effective for agents.

The verdict

Autonomous coding agents are not going to replace software engineers. What they are doing is stripping away the comforting illusion that software engineering was primarily about writing code.

Writing code was simply the manual labor of our craft. The real work has always been system decomposition, choosing trade-offs, defending architectural boundaries, and taking personal accountability for production correctness. Teams that treat autonomous dev agents as magic shortcut generators will drown in review paralysis and unmaintainable technical debt within six months. Teams that treat them as high-speed executors inside a disciplined, defensive SDLC will move faster than ever before.

References and further reading

NVIDIA/OpenShell: Safe runtime for autonomous AI agents — The architecture behind running agents in isolated Linux namespaces with Landlock and seccomp.
NVIDIA's OpenShell takes the permissions out of the agent — My deep dive on boundary architecture and credential injection outside agent reach.
The bottleneck moved to review and nobody staffed for it — Why high generation throughput breaks downstream engineering review queues.
The malware didn't search your laptop. It asked your AI to. — How prompt injection and permission bypasses exploit local AI developer tools.
Vibe coding works. Here's the side-effects leaflet nobody read. — Telemetry and data on review time surges, regression rates, and maintainer fatigue.

Takeaways

Autonomous agents shift the paradigm from typing assistance to delegation, running self-healing loops until tests return exit code 0.
Passing tests does not mean correct design: agents often converge on local optimums, monkey-patching around flaws with defensive band-aids.
The primary bottleneck in agentic teams is review fatigue. Reviewing 600 lines of generated code takes just as long as reviewing human code.
Agents lack long-term architectural vision and will eagerly duplicate existing utilities or amplify outdated legacy patterns.
Adopt Spec-Driven Development (SDD): define TypeScript contracts, OpenAPI schemas, and target file allowlists before invoking the agent.
Run agents in hermetic sandboxes with ambient environment secrets stripped and outbound network access strictly controlled.
The human engineer who merges the pull request owns 100% of the diff. 'The agent wrote that' is never an acceptable post-mortem excuse.

All notes · Shehzad Aslam