16 Failure modes that look productive
Agentic development can fail while producing impressive activity. The repository fills with branches, tests, review comments, plans, and release notes. The surface looks rigorous. The product grows harder to trust. Each pattern below earns suspicion because it imitates a discipline without doing its work.
16.1 Prompt theater
You write a long prompt that tells the agent to be careful, test thoroughly, and think step by step. The repository still lacks executable invariants, a complete command-line path, and an integration gate.
The prompt may improve behavior. It does not create proof. Move standing rules into scripts, tests, documents, and branch policy until the prompt can get shorter.
16.2 Design theater
Every change gets a document, but the document never exposes a decision that could invalidate the work. It restates the ticket, predicts file names, and declares familiar principles.
A useful design names the canonical state, the failure policy, the compatibility boundary, and the proof. A tiny change may need only a paragraph. More pages do not compensate for an implicit semantic fork.
16.3 Review volume as quality
A fleet of review agents generates dozens of findings, and every finding becomes an issue. No one checks whether the code already handles them or whether the reviewer misunderstood the domain.
This burns trust. Review output is candidate evidence. It needs reproduction, triage, and reasoned rejection.
16.4 Self-consistent proof
The implementation and the test share a helper, an algorithm, or a mistaken assumption, so they agree perfectly. A test recomputes the expected midpoint with the production formula. A screenshot tool captures through the same broken rendering shortcut. A parser oracle duplicates the optimized state machine.
Use a different representation when you can. At minimum, break the implementation and prove the test notices.
16.5 Green-branch optimism
Every feature branch passes. No one tests the merged tree after each integration. A release is cut on the assumption that local green composes.
Interactions appear only in the shared tree. Green must name the revision and the environment. The same optimism has a release-time form: a green publish workflow treated as repository health while a required check sits red in another lane. Verify the conclusion of the whole required graph.
16.6 Provenance worn as verification
Consider a typesetting engine whose wordmark the engine itself once
rendered, committed alongside the script that generated it. Nothing in
the current build regenerates or validates the file. Generated by the
engine
states provenance; readers hear verification. The two
properties diverge silently as the engine changes underneath the
committed asset. Say which property each artifact has, and promote
provenance to verification wherever the claim carries weight.
16.7 Parallelism without an integrator
Agents work in isolated branches, then merge each other’s changes opportunistically. No one owns the final sequence or reruns the full suite after every merge.
Parallel production requires a serial trust boundary. The integrator does not need to write the code. The integrator must vouch for the tree.
16.8 Snapshot dependence
Visual quality is reduced to screenshot approval. The capture path may be wrong, lazy work may not have run, and small geometry defects hide in noise.
Use screenshots for user-visible evidence, exact geometry for localization, and a tested pixel detector for backend behavior. None suffices alone.
16.9 Guardrail worship
A complexity limit or lint rule blocks your work, so you bypass it or restructure code only to satisfy the number. No one asks whether the rule still tracks the risk.
A guardrail should be enforced and debuggable. Record the debt it catches and the accidental friction it causes. Improve the mechanism instead of worshiping or evading it.
16.10 Documentation after the fact
The code lands first. The site, the examples, the embedded agent instructions, and the migrations go to a later cleanup ticket.
This opens a window where every consumer sees a different language or product. Update the contract surface while the implementation context is still active.
16.11 Forced continuation
The agent cannot prove the root cause but produces a patch anyway, because returning empty-handed feels like failure.
A good workflow accepts missing artifact
or no safe
change
as completed investigative results. Keep uncertainty visible
instead of converting it into code.
16.12 Tidy stopping
The agent completes a bounded unit, files a tidy report, and waits. Every increment looks disciplined. The queue never advances without a human nudge.
This is the mirror image of forced continuation and easier to miss, because each pause resembles care. Agents stop at locally satisfying units unless a completion harness defines completion and makes premature stopping difficult. When the repository can already verify the next step, pausing to ask is not caution. It is missing machinery.
16.13 Human bottleneck disguised as quality
You review every line, rerun every command, and answer routine questions the repository could settle. The work is correct only while you are awake and attentive.
Move repeatable judgment into invariants and scripts. Reserve yourself for taste, product choices, external facts, and novel failure classes.
16.14 Synthetic certainty
The final report is polished, complete, and free of doubt. It does not state the revision, the old failing case, the rejected review findings, or the remaining uncertainty.
Confidence is fine. Confidence you cannot inspect is not.