AI coding workflows: Choosing boredom over brilliance in the second year of AI coding
Choosing boredom over brilliance in the second year of AI coding is one of the year-two habits with AI coding workflows that quietly separates teams that learned from last year and teams that only used the tool. 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 two the novelty is gone. AI coding workflows is no longer a demo; it is infrastructure. The question is no longer whether to use it, but how to use it without quietly paying interest on a pile of shortcuts. This piece is about one of those interest payments you can stop making this week.
Why this move with AI coding workflows actually matters
Review habits that catch hallucination before it compounds is the feature people quote in the changelog. The practice that turns it into leverage is choosing boredom over brilliance in the second year of AI 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 AI coding workflows 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. Ceremony that silently replaces thinking 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, choosing boredom over brilliance in the second year of AI 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. Review habits that catch hallucination before it compounds 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 AI coding workflows 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 choosing boredom over brilliance in the second year of AI coding. The action is to reach for AI coding workflows 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. AI coding workflows is no longer the story; the story is the compound interest of a year of small, deliberate choices. Choose one angle this week, keep it, and let the next year of work inherit the habit.
More field notes on AI coding workflows
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 AI coding workflows specifically, browse the full set at /blog/tag/ai-workflow/. For the wider view across every tool in the stack, the AI coding tag collects the whole archive in one place.