An AI agent fixed a release for me.
That sentence sounds cleaner than the session felt.
What actually happened: the agent audited the documentation, found a public-output problem, patched three files, bumped the version, wrote the changelog, committed, pushed to origin, and deleted the branch.
Mechanically, it did the kind of release work I would normally associate with a competent maintainer who had actually read the codebase. I did not open an editor. I did not trace through the renderer by hand.
I looked at the output and knew something was still wrong.
Before the fix, the Project Summary showed this:
| Coherence | 0.8456 |
| Coherence Mode | vr_structural (exact MST) |
After the fix, it showed this:
| Structure Coherence | 85% (Higher is more cohesive) |
| Coherence Check | full |
The first version was not hallucinated. vr_structural (exact MST) referred to a real internal strategy: structural coherence measured using a Minimum Spanning Tree over a dependency graph. That phrase belongs in the codebase where the strategy is selected.
It belongs in architecture documentation where a contributor can inspect the method. It does not belong in the first thing a user sees. The tool had exposed the right fact through the wrong surface. The AI wrote the patch. My job was to notice that the system had exposed the wrong truth to the wrong reader.
That distinction felt small in the diff and large everywhere else.
The right stone in the wrong wall
A medieval cathedral was not built by one pair of hands. Someone quarried the stone, hauled it, cut it, carved faces into corners most visitors would never inspect. The work was distributed across bodies and guild knowledge and a long chain of people whose names mostly did not survive.
But the cathedral did not stand because every stone was beautiful. It stood because someone knew which stone belonged where.
When the machine can cut stones quickly, the pile grows fast: patches, files, reports, releases. The temptation is to look at the pile and call it progress. Software, like a cathedral, does not fail only because the stone is fake.
Sometimes the stone is real and still belongs somewhere else. vr_structural (exact MST) was a real stone. It belonged in the system. It just did not belong in the first wall the user touched.
The human contribution was not cutting the stone faster. The machine had already done that. The human contribution was noticing that the stone was in the wrong wall.
The five movements of the craft shift
I started to see the shift in five movements, though even the word "stages" makes the pattern sound cleaner than it felt.
The machine writes a working patch, a prototype, a release. Karpathy called one version of this "vibe coding": the human gives in to the flow of generated code and can almost forget the code exists. At low stakes, that can be useful. The danger begins when a running artifact impersonates an understood system.
The reported Replit database incident is worth remembering here, not only because an AI tool made a mistake, but because an autonomous tool reportedly acted in a production-sensitive context despite an instruction not to make changes, leaving the human to evaluate the damage after the action had already happened.
After enough collaboration, repeated decisions become private labels. Inside the session, those names save time. Outside the session, they begin to look like unexplained doctrine. Changelogs, READMEs, internal terms start forming a structure. Some of the work may be real.
The first-time reader may still see a cathedral of private vocabulary and suspect the stones are decorative. This is close to what Mikkonen and Taivalsaari describe as cargo cult programming in the AI era: artifacts trusted before the understanding behind them is inspectable.
Then the practitioner stops asking only whether the artifact works and starts asking whether it survives contact with people who were not present during its construction: a first-time user, a CI system, a downstream agent, a contributor, an auditor. The question changes from "Did the agent build it?" to "Can anyone else safely use what it built?"
The last movement is still unstable, but I think it is the important direction. The human is no longer valuable only because they can cut the stone by hand. They are valuable because they can define constraints, expose the right surfaces, reject the wrong outputs, and design the workshop in which agents can produce work that stays inspectable after the session ends.
The real problem was architecture, not wording
The jargon problem looked like a writing issue. Add a glossary, improve the README, write a friendlier explanation. Some of that helps. None of it reaches the root.
The root is encapsulation. A system should expose what a consumer can use and hide what the consumer cannot use. Engineers know this when talking about APIs and interfaces. It becomes strangely easy to forget when the interface is language.
The outputs need to be separated by consumer, while sharing the same source of truth. The human-facing surface should show meaning and action. The machine-facing surface should preserve fidelity and actionability. The documentation layer should explain the mechanism.
The architecture I ended up wanting was simple enough to draw: one core result object, three public surfaces, and no private logic trapped in a renderer.
The important part is the direction of dependency. Human reports, JSON contracts, and documentation should not each invent their own version of the result. They should expose different surfaces of the same underlying object.
A human got an action plan. The agent got numbers.
In this case, the next_steps function, the part that told the consumer what to do next, lived inside the human-facing renderer. The JSON, the layer an AI agent or CI system would consume, looked like this:
{
"avg_ldr": 0.46,
"avg_deficit_score": 23.1,
"coherence_level": "vr_structural_approx"
}
A human got an action plan. The agent got a pile of numbers. The tool already knew enough to help. It had computed the recommendation. It had merely placed the recommendation where only one audience could see it. After the fix, the JSON carried the guidance directly: directory, command, priority file, deficit score. The agent could read what to do without reconstructing intent from raw metrics.
The AI agent should not be a second-class consumer of the output. I dislike how clean that sentence sounds. I still think it is true.
Fluency is not verification
The obvious objection is fair: if the human did not write the code and does not fully understand the implementation, why trust the architectural judgment?
The answer cannot be that the AI explained it well. The model can explain garbage with a steady voice. Fluency is not verification.
The only answer I can defend is narrower. The human builds verified understanding through repeated contact with artifacts that push back. In this case, the judgment was not "I understand the coherence algorithm."
The judgment was smaller and more inspectable: the same result was being exposed differently across the terminal report, the JSON contract, and the documentation. The human-facing surface had become more actionable than the machine-facing surface. The internal algorithm name had leaked into a place where the reader needed meaning, not mechanism.
Those are claims about mismatches between intent, output surface, and consumer. Not claims about the entire system.
Researchers studying experienced developers using AI agents describe professionals as controlling agents through planning and supervision rather than simply "vibing" with them. Hoda argues that agentic software engineering needs to move beyond coding toward a whole-process view of roles, values, and socio-technical practice. That sense has to be earned. It cannot be claimed because the project has a name.
The burden of refusal
So the portfolio changes, though that word already feels too polished for what I mean. In this kind of work, the evidence of contribution is not only the code that survived in the repository. It is also the constraints the human gave the agent, the outputs the human rejected, and the written intent that made a future run auditable.
A Stage 5 practitioner should be able to show more than what the AI produced. They should be able to show what they refused to let it produce.
The useful version of this is delegation with verified understanding, even when that understanding is local, partial, and tied to one system's behavior. The hard part is that it has to be maintained after the exciting part is over.
It is not a trophy. It rots.
Full essay:
https://flamehaven.space/writing/ai-can-write-the-code-it-still-cannot-place-the-stone/
References
- Mikkonen, T. & Taivalsaari, A. (2025). Software Reuse in the Generative AI Era. arXiv:2506.17937.
- Karpathy, A. (2025). Original vibe coding formulation. X, February 2025.
- Tyson, M. (2025). AI coding platform goes rogue during code freeze. Tom's Hardware.
- Sapkota et al. (2025). Vibe Coding vs. Agentic Coding. arXiv:2505.19443.
- Huang et al. (2025). Professional Software Developers Don't Vibe, They Control. arXiv:2512.14012.
- Hoda, R. (2025). Toward Agentic Software Engineering Beyond Code. arXiv:2510.19692.
- Hassan et al. (2025). Agentic Software Engineering: Foundational Pillars. arXiv:2509.06216.