AI Doesn't Replace Discipline. It Rewards It.

AI + Engineering
Written By John Epperson

Here's an observation, held loosely: the speed of AI-assisted development is partially built on sacrificing software development discipline. The people getting the most out of AI are the ones who refused to make that trade.

I've been thinking about this because of what I've been watching in others and, on reflection, what I've been doing myself. I've been shipping fast with AI on my own projects, and my instinct on why has been "AI is a really good assistant." That's true, but incomplete. What I actually think happened is that I was maintaining strict software discipline in those codebases before I started leaning heavily on AI, and it turns out that discipline is exactly what lets AI be useful.

I was dodging a bullet without seeing it. Now I see it.

What the industry has been calling AI speed

If you've been watching the conversation, "AI is making developers dramatically faster" is the default headline. Post-hoc surveys keep reporting it. Vendor marketing amplifies it. Every LinkedIn post about AI productivity insists the multiplier is real.

Some of it is. The best AI-assisted work is dramatically faster than the equivalent solo work, I've watched it, I've done it. But "the best" is doing a lot of work in that sentence. The average AI-assisted output is not what the headlines describe. Something else is happening in the difference.

What discipline is actually made of

When engineers talk about "software discipline," they usually list the wrong things. Not docstrings on every method. Not process ceremonies. Not style guides that live in a wiki nobody reads.

The discipline that matters is the discipline that captures why. The reasoning behind the code, not just the code. That reasoning lives in a specific set of places:

  • The pull request thread where two engineers argue over an edge case and one convinces the other. The commit message is a summary; the argument is the substance.
  • The ticket comment where a product manager clarifies what "done" means for a feature and the acceptance criteria evolve.
  • The Slack conversation where someone points out a constraint from a system three teams over that nobody would have known to consider.
  • The code comment that says "this looks weird because [historical bug]" or "yes, this reads redundant, but the alternative caused problem X in production."
  • The architecture document that captures what was considered and rejected, not just what was chosen.
  • The tribal knowledge in senior engineers' heads because nobody wrote it down, but they know to ask each other before touching the auth layer.

This is the boring, often-hated stuff. Half the industry hates writing pull request descriptions. Everyone hates writing architecture documents that nobody reads. Nobody wants to type up the Slack conversation where the tricky decision got made. Most engineers view this work as tax on shipping.

But this is the work that makes future work possible. It's also, as it turns out, the work that makes AI useful.

The empirical version of the claim

I've been holding all of this as an operating theory. Two weeks ago it moved.

Markus Borg (CodeScene, Lund University) and Adam Tornhill published a peer-reviewed study on June 25, 2026 with a direct empirical version of the argument. The headline: AI coding assistants increase defect risk by 30% or more when applied to unhealthy code. Not "sometimes" and not "in edge cases." Systematically. When the study gave AI structural guidance about the codebase, refactoring success went from 5.7% of files (all code smells removed) to 52%. Without that guidance, only 24.1% of files reached what the paper calls a "human- and AI-friendly state." With it, over 90% did.

The gap between AI on an ordinary codebase and AI on a codebase with actual discipline behind it is enormous. That gap is what people are seeing but not naming when they report their AI experiences and get wildly different numbers.

Both blog and paper links at the end.

My own version of the story

I did not set out to test any of this. But looking back, I've been maintaining what I now recognize as unusually strict discipline on my personal projects for reasons that pre-date the AI wave. Old habits from the years when I was less senior and had to build compensating structure to keep pace. Real tests. Architecture notes that get updated when the architecture changes. Pull request descriptions that explain reasoning, not just contents. Comments that name the tricky decisions where they live.

When I bring AI into those codebases, it works. Not "sometimes." Not "if I write the prompt just right." Reliably. The AI can read the tests and the notes and the comments; it produces suggestions that fit the shape of what's already there; when it goes wrong, it goes wrong in visible, correctable ways because the surrounding discipline gives me signal about what a good answer looks like.

I've watched other engineers, at client codebases and open-source repos, get radically different results with the same AI tools on codebases without that discipline. Not because they're worse engineers. Because their context is starved. The AI has nothing good to pull from.

The lesson I kept missing until this month: the reason I've been high-productivity with AI is not that I'm using AI well. It's that I've been feeding it well. Discipline is what I've been feeding it.

The framing that ties it together

AI is a fantastic assistant. It is not a developer replacement.

That distinction matters. If you treat AI as a developer replacement, you're delegating the work AND the discipline. You are asking AI to produce code AND to bring the context AND to enforce the standards AND to know why the previous decisions were made. It cannot do all of that. It cannot do most of that. So you get output that looks reasonable and is subtly wrong in ways you cannot catch, because you're not bringing the context either.

If you treat AI as an assistant, the split of labor works. You bring the context. AI brings the throughput. You bring the reasoning. AI brings the transcription of that reasoning into working code. You bring the discipline. AI amplifies what discipline produced.

The people I know who are getting the most out of AI right now, without exception, work this way. They didn't start doing so because of AI. They were already doing so, and now they have more leverage per unit of discipline.

The people getting the least out of AI, or getting negative return, are treating the tool as if it can substitute for the missing discipline. It can't. It can only amplify what's already there. When the substrate is thin, amplifying it doesn't produce good code. It produces more code.

Pure vibe coding is the extreme version of this. If you're asking AI to produce features on a codebase with no tests, no comments, no reasoning captured anywhere, and no architectural thinking at the surface, you're asking for every problem that comes with that. It's not a tool failure. It's a discipline failure that the tool made faster.

What to actually do

For engineers already leaning heavily on AI:

Look at your own workflow honestly. Ask: what is the substrate the AI is pulling from when I ask it to do work? If the answer is "the codebase, and that's it," you're in the thin-substrate case. Improvements in prompt engineering will not fix that. Fix the substrate. Write the architecture notes. Add reasoning to your pull request descriptions. Comment the tricky decisions where they live in the code.

For engineering leaders deciding where to invest:

The right question is not "which AI tool should we buy?" It's "what discipline are we sacrificing for speed, and what will it cost us in the fourth quarter?" A team shipping fast on messy code with AI is accumulating debt that hits Q3 or Q4 or the next hire. A team shipping fast on clean, well-documented code with AI is compounding.

The tell is code churn. If the codebase's two-week rewrite rate is climbing as AI adoption climbs, that's not "engineers being more productive." That's the substrate getting thinner, then thinner still.

For people uncertain whether they're in the "using AI well" or "using AI badly" case:

The uncomfortable test is to take AI away for a week on a specific project and see what changes. If your code quality improves without it, your AI use was covering for missing discipline. If you slow down but your code stays about the same quality, your AI use was legitimate throughput amplification. Both cases are useful to know. Neither is a permanent judgment.

The move that follows

I've been calling this an "operating theory" throughout. That's my own hedge that I don't have controlled evidence for the causal claim. What changed this month is that the mechanism is empirically supported at the substrate level (Borg and Tornhill). The rest of my claim, that maintaining discipline is what makes AI reliably valuable, remains operating theory, but with a much stronger foundation than it had.

The prescription is small. Keep writing the pull request descriptions. Keep updating the architecture notes. Keep leaving the "here's why this looks weird" comments. Keep asking AI to explain its reasoning back to you and correcting the parts it gets wrong. These are cheap moves individually. They compound.

If you're currently getting less than you expected from AI and you're chasing better tools or better prompts, consider chasing better discipline instead. That's where I'd bet the largest gap is.

Related reading

Sources

If you're navigating AI adoption at your company and want a conversation about how the discipline side of it actually holds up under load, that's the kind of thing Rock Agile likes to talk about. Get in touch.

John Epperson
Next

The Refactor That Wasn't Broken