The ticket was one line: “Blog posts older than two years should disappear from the overview.” The agent had read it, found the spot in the code where the overview page assembles its list of posts, and added a filter on the publish date. Tests green, preview showing exactly what was asked for - old posts, gone from the list. The pull request was technically flawless.
It was still wrong. The filter sat in the shared query that fed both the overview page and the sitemap. A post that dropped out of the list dropped out of the sitemap with it - and a few weeks later, out of whatever search engines still knew about the site. Nobody had wanted that, and nobody had written it down. Whoever wrote the ticket was picturing a tidy overview for visitors. That old posts should still be reachable and findable under their own URL was nowhere in the ticket - it was so obvious that nobody thought to mention it.
That is exactly where you can see what automation actually does. It does not write less human work. It moves the work to a different point in the process.
What actually disappears
The part that gets replaced is real, and it is worth not talking it down. Finding the spot in the code where a change has to go. The exact way a filter gets written. Adding the test that pins the new rule down. All of that was tedious manual labor three years ago and today gets done in minutes, often better documented and more consistently named than it would have been by hand under deadline pressure.
That is not a small gain, and nobody is served by underselling it just to preserve the story of indispensable human labor. A large part of what made software development tedious for decades was exactly this mechanical translation of an intention into a particular syntax. A machine can now handle that translation reliably.
What moves to the front
What does not shrink is the work of stating the task so that the translation actually lands on what was meant. “Disappear from the overview” is a sentence a human reader fills in with a whole context they never say out loud: that the posts keep existing, that their URLs keep working, that the sitemap is untouched because that is a different question from the overview. A model does not fill that context in. It reads the sentence, finds the most direct implementation that satisfies it, and is, formally, right.
This is not a complaint about the model’s quality. It describes what language in a ticket is actually for. A good ticket does not just say what should happen. It marks off what is not included - and that marking-off is now the task sitting at the start of the process, where thinking about the implementation used to sit. The effort has not disappeared. It has moved from “how do I write this filter” to “what exactly do I mean by disappear”, and that second question cannot be outsourced, because it requires thinking your own request all the way through before you write it down.
The second spot: judging, not just reading
The second shift happens afterward, at the result. A pull request that looks plausible is a different thing from one that does what was meant, and the difference rarely sits in the diff itself. The filter in the example above reads cleanly in review - one line excluding posts by date, right where the overview assembles its list. Anyone reading the diff sees code doing exactly what the ticket asked for. Seeing that it does too much requires knowing that this same query also feeds the sitemap - knowledge that lives in neither the diff nor the ticket, only in the head of someone who knows the site’s architecture.
That is the judgment that has to sit at the end, and it is a different thing from code review in the traditional sense. Code review asks whether a change is cleanly written. This judgment asks whether it does what was actually wanted, including the parts nobody thought needed writing down. Only someone who holds the context the ticket does not contain can answer that question - and that someone is, at least for now, a human being.
What gets better and what gets worse
Honestly, not everything about this gets easier. Writing a ticket that is genuinely precise is hard work, and it used to be optional, because a human doing the implementation quietly filled gaps in the brief with their own judgment. That silent correction is gone now. A vague ticket no longer produces a reasonable result by default, because nobody sits between the request and the implementation closing the gap from experience anymore. Teams that miss this get worse outcomes than before, not better ones - and then blame the model for it.
What gets better is how honest teams are forced to become about their own requirements. A ticket a model is supposed to reliably get right forces you to settle what you actually want beforehand, instead of discovering it partway through the build. That is uncomfortable and mostly a gain, because the clarifying was always going to happen - it just used to happen later, spread across several follow-up questions and a second attempt.
And what gets worse is how easily a clean-looking result gets waved through. A diff that contains exactly what the ticket asked for looks finished. Whether it is gets decided somewhere else - in whether someone looked at the running system, not just the text of the change. That check cannot be automated away without immediately facing the same problem one level up: who judges whether the judgment was correct?
Why the end
The human does not belong at the start of the process, because things can now move much faster there without losing anything in the result. They do not belong in the middle either, watching a model do what the ticket says. They belong at the end, at the point where someone asks whether what actually happened matches what was meant - a question that needs the whole context of an undertaking, not just the text that got written down about it.
That is not a stopgap job that disappears once the models get a little better. It is the job that remains once everything else is solved.
