AI Coding Agents Write More Code. They Don't Write More Software.
A post that spent time near the top of Hacker News in October 2026 made an observation most working engineers now recognise: coding agents got good enough that teams stopped manually writing code, and yet the amount of software actually shipped did not move proportionally. Output went up. Deliverables did not.
That gap is not a prompting problem. It is a systems problem, and it shows up in three specific places — verification, context and drift. Each has a different tooling answer, and the October launch wave on Hacker News's front page happened to build one for each.
The gap is verification, not generation
When an agent produces a diff, nobody has checked it yet. The cheap assumption is that the model is now accurate enough that review is a formality. In practice the failure mode moved rather than disappeared: agents produce code that looks right, passes a casual read, and breaks on an edge case the specification never mentioned.
The teams that close the gap treat agent output the way you would treat a pull request from a new contractor — useful, plausible, unverified until proven otherwise. That means a verification step with an actual oracle, not a second model saying "looks good."
Copperhead takes this literally in the hardware domain. It runs an AI agent over a KiCad repository, but every one of its eight stages is gated on KiCad's own ERC and DRC output rather than the model's claim that the change is clean. If the electrical rule check fails, the run stops. No artifact on disk, no commit. The model cannot talk its way past an oracle it does not control.
That pattern generalises. If your workflow has a real checker — a type system, a test suite, a linter, a physical constraint solver — the agent's job is to iterate against it until it passes, and the checker's job is to be the authority. The teams that wired this up properly report fewer surprises at integration time than teams that added a second LLM as a reviewer.
Context is invisible, so it degrades
The second failure mode is subtler. A coding agent's conversation looks like a record of decisions, but most of what shaped an answer never made it into the prompt. Which earlier discussion was included? Which branch was pruned? Why did the model believe a constraint that nobody stated?
ThoughtDAG attacks this directly by turning a conversation into an editable graph where every wire is a route into the next request. Before you send, you can preview exactly what the model will receive — source nodes, ordering and a token count. Delete one edge and the same prompt produces a different answer, because the removed branch genuinely left the context.
This matters more than it sounds. An old assumption that keeps resurfacing is usually a stale wire, not a model limitation. The published context-repair pilot behind that tool found that deleting only the source of a derailment repaired 152 of 162 cases, while removing the whole contaminated subgraph repaired all 162. The model was never wrong about the context it was given. It was given the wrong context.
Being able to see and edit what enters a request is the difference between debugging a system and re-rolling the dice.
Drift is the expensive failure
The third gap is drift, and it is the one that costs real money. A design decision spreads across a schematic, a bill of materials, a power budget and four documents. Nothing breaks when they fall out of sync — the inconsistency only surfaces at bring-up, when a respin costs five figures and six to eight weeks.
Copperhead was built specifically for this. Its thesis is that drift is a build failure, and its agent edits the KiCad s-expressions surgically so diffs stay small and reviewable while every referencing document is updated in the same pass. A tool that regenerates an entire schematic to move one net makes its own work impossible to review.
Drift is not unique to hardware. Any project where one decision lives in several files — an API contract and its client, a schema and its migrations, a config and its docs — has the same shape. The fix is always the same: make the agent's edit atomic across the places the decision appears, and make the review cheap enough that it actually happens.
Where the new generation of agents is going
Worth noting is what the August and September launches say about direction. Several of them are explicitly optimising for constraints that mature tools do not handle well.
Ante is a single roughly 15 MB Rust binary with Grep and git compiled in, running twenty parallel tasks with about 7x less peak memory than Claude Code in the author's own container test. It also runs fully offline against local GGUF files. The bet is that the hard part of an agent is not the model call — it is everything around it.
Whiteboard approaches the same problem from the design end: an open-source canvas where agents draw diagrams through MCP session tools, with a batch authoring mode so the same review pipeline runs headless in CI. Design review becomes something a pipeline can check rather than a meeting.
Huzzah questions the interface itself. Instead of longform chat instructions, you maintain a pseudocode file describing the shape of what you want; each save becomes a diff and the model regenerates the affected source. Prompting fatigue is real, and treating prompts as persistent documents rather than throwaway messages is a genuine response to it. The author is candid that it suits new codebases better than legacy ones and that cross-file dependencies remain a known gap.
And SolidCraft extends the pattern into CAD, exposing an MCP server with tools for execute, inspect_design, measure and set_parameter so an agent can drive a real parametric constraint solver. One published build holds 3,323 editable timeline steps that rebuild without errors. Verification here is not a test suite — it is geometry that either closes or does not.
What actually converts output into software
If you take one thing from the 2026 coding-agent wave, it is this: generation is no longer the bottleneck, and no amount of prompting fixes a bottleneck you have already passed.
The work that matters now is
- Give the agent a real oracle. A checker that is not the model, and a loop that iterates against it until it passes.
- Make context visible and editable. Know what entered the request, and be able to remove it.
- Treat drift as a build failure. Update every place a decision appears in one atomic edit.
- Keep reviews cheap. Surgical diffs that a human can actually read in a minute.
None of that is new engineering wisdom. What is new is that the tools now exist to enforce it without you remembering to. That is the actual shift, and it is why the answer to "why didn't shipping speed double" is not a better model. It is a better loop around the one you already have.
FAQ
Did coding agents fail to deliver?
No. They changed what the bottleneck is. Generation sped up enormously; verification, context management and drift control did not, and those are what gate shipping. The teams that rebuilt their loop around them saw the gain.
Is a second model a good reviewer?
Rarely on its own. A judge model cannot see data it is not shown, and classifiers are themselves prompt-injectable. A deterministic checker — a test suite, ERC/DRC, a type system, a geometry constraint — is a stronger authority because the agent cannot argue with it.
Should I switch to a lighter agent like Ante?
If you run many parallel sessions or need offline operation, the resource profile is compelling. If you need the deepest integrations and polished IDE experience, the incumbents still lead. Ante is explicit that it is a beta preview expecting breaking changes.
Where should I start if my team is stuck?
Instrument context first. Most "the model forgot" complaints are actually "the model was never told." Making what enters each request visible usually explains more failures than any prompt change.
