AI coding agents can now take on a real share of implementation work. That doesn’t mean engineering has been automated. That’s the argument in a widely discussed essay making the rounds on Hacker News, where it reached a score of 178. The author’s point is simple, and a lot of the industry keeps skipping over it: writing code is one part of software development, and automating it doesn’t settle the rest.
The essay asks a pointed question. When people say AI has “transformed software development,” which part do they mean? Producing an implementation? Exploring a design? Deciding whether a system solves the right problem? These are linked, but they aren’t the same job.
Why This Debate Matters Now
The timing is significant. Agentic coding tools have moved past autocomplete and into multi-step, multi-file work. Vendors pitch them as teammates, and the public conversation keeps sliding from “this tool automates tasks” to “this tool replaces developers.”
The author pushes back on that slide directly. Calling it “replacing the person who churns out code” reduces developers to typists, the essay argues, and it also understates what agents can actually help with. As the author puts it, “Claims about workforce replacement require evidence beyond an impressive demonstration.”
That’s a useful filter for anyone reading vendor announcements. A slick demo is not a labor-market study.
The Context Problem Nobody Talks About
What stands out here is the focus on where decisions live. A chat session is a handy place to explore options. It’s a fragile place to keep the only record of an architectural choice.
Model context is limited. Long sessions get summarized or compacted, and the essay notes that summaries tend to keep the conclusion and drop the reasoning behind it. “Use a local cache” is not the same instruction as “use a local cache because this screen must remain usable without connectivity.”
The author cites Anthropic’s engineering report on long-running agents, which describes continuity problems across context windows and admits compaction can leave instructions unclear. To the author’s credit, the essay calls that a vendor report about one specific setup, not a universal benchmark. It also points to Simon Willison’s June 2025 writing on “context engineering,” meaning the work of choosing what information the model sees at each step.
The proposed fix is low-tech on purpose: a small, reviewable PROJECT_GUIDE.md file that holds:
- The product’s purpose and scope, including what’s explicitly out of scope
- Key system boundaries and the reasons behind architectural choices
- Quality expectations and the commands used to check them
- Links to deeper decision records
The author is honest about the limits. The filename has no magic. Agents won’t necessarily load it, and “Markdown alone guarantees neither retrieval nor obedience.” Any claim that this saves tokens or money needs to be measured across the whole task.
Verification Is the Real Job
The sharpest part of the essay is about acceptance. Agent output is probabilistic, so accepting it should depend on evidence you can inspect and, where possible, reproduce.
The author walks through a hypothetical mobile search feature with explicit acceptance cases written before any code exists:
- A matching query shows the expected items
- A query with no matches shows an empty state
- Clearing the query restores the full collection
- If filtering runs asynchronously, older results can’t overwrite newer ones
The fourth case raises a design question: does this need concurrency at all? The answer should come from data size and responsiveness requirements, “rather than introducing concurrency because a template expects it.”
Then comes the warning that matters most. Passing tests don’t make scope creep acceptable. If the agent rewrote persistence when it was told not to, green checks don’t fix that. And a generated test “can faithfully encode the same misunderstanding” as the generated code. Formatters, compilers and tests each answer a narrow question. None of them tells you whether you built the right thing.
What Teams Should Do
For engineering leaders adopting agents, the practical takeaways are clear:
- Write decisions down outside the chat. Keep a short project guide with the reasoning, not just the rules.
- Ask the agent to paraphrase first. A short summary of the intended change and its constraints catches misunderstandings early.
- Define acceptance cases before generation. Don’t let the model write both the code and the test that judges it unchecked.
- Review the diff, not just the test results. Scope violations hide behind passing builds.
- Measure claimed savings end to end. Count rework and correction time, not just generation speed.
Looking Ahead
As agents take on bigger chunks of work, the bottleneck moves from typing to judgment. Teams that treat verification and decision records as core engineering work, not paperwork, will get more out of these tools than teams chasing raw output. My recommendation: invest in the guardrails now, while the agents are still small enough that mistakes stay cheap. The full essay and the community discussion are on Hacker News.