Agentic coding: Honest post-mortem of three years of agentic coding
The honest post-mortem of three years of agentic coding is one of the year-three habits with Agentic coding that looks, from the outside, like nothing at all and, from the inside, like the reason the team still ships every week. It rarely shows up in launch posts or benchmark threads. It shows up instead in the hour you did not lose on Friday afternoon, in the pull request that did not need a second round of review, in the commit message that honestly described what changed.
By year three, Agentic coding is boring in the best possible way. Nobody in the team asks “should we use this” any more. They ask “did we remember to turn the knob we agreed on last quarter”. The interesting work has moved from the tool itself to the habits and contracts around it. This piece is about one of those contracts, and why it still repays attention.
Why this move with Agentic coding actually matters
The promise of long-running background work is the feature people quote in the changelog. The practice that turns it into leverage is the honest post-mortem of three years of agentic coding. Those two are not the same thing. A feature is a capability; a practice is a decision you make about when and how to reach for it.
When you approach Agentic coding through this angle, you stop asking “what can it do” and start asking “what should I let it do today”. That framing is deliberately boring. It is also the difference between a workflow that you respect in six months and one you quietly abandon after two sprints.
The honest friction
None of this is free. Silent context loss that surfaces as confidently wrong diffs is the kind of friction that does not appear in the first week, when the tool is fresh and every completion feels earned. It appears later, in the tenth agent run of a tired Thursday, when you accept a diff you would have rejected at nine in the morning.
The mitigation is not another layer of tooling. It is a slower one: a short checklist that runs before you hand control away. Has the acceptance criterion been written down? Does the test suite still make sense? Is there a rollback path that does not involve apologising in standup? When those questions are cheap to answer, the honest post-mortem of three years of agentic coding stops being a risk and starts being a routine.
Measuring what actually improved
It is easy to tell yourself the workflow is better. It is harder to prove it. The promise of long-running background work is one edge of the loop you are trying to improve. Your review habits are the other. The practice is to measure both, not just the half that flatters the tool.
A good week with Agentic coding is not the count of accepted suggestions. It is the count of changes that stayed shipped, the reduction in review round-trips, the calm with which you pushed to main on Friday. Those three numbers can be tracked in a spreadsheet and they will tell you more than any dashboard the vendor ships. Everything else is vanity.
Making it stick
Habits with AI tools stick the way all habits do: a small cue, a clear action, a visible reward. The cue is a task that fits the shape of the honest post-mortem of three years of agentic coding. The action is to reach for Agentic coding with an explicit intent rather than an idle one. The reward is a diff you would have been proud to write by hand, only faster and with fewer rough edges.
If you take only one thing from this, let it be that. Agentic coding is entirely the background; the story is the contract the team still honours around it. Keep the contract simple, keep it visible, and let the third year of practice pay off the fourth.
More field notes on Agentic coding
This piece is one entry in a running series on how AI coding tools change day-to-day engineering work. For more practical notes on Agentic coding specifically, browse the full set at /blog/tag/agentic-coding/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.

