Atomic Habits for AI Agents
I thought interesting to put in perspective of the AI agents one idea from Atomic Habits by James Clear:
“You do not rise to the level of your goals. You fall to the level of your systems.”
James Clear was talking about people. I think it’s even more true for AI agents.
In fact, I’d argue it’s one of the best mental models for understanding why some engineering teams are getting incredible results from AI, while others are disappointed.
I am not even talking about advanced loop patterns, on when and how to apply them etc…
The difference usually isn’t the model. It’s the system. Of course, the model matters. A weaker model will need more guidance, stronger guardrails, and a more explicit environment. A more capable model can navigate more ambiguity.
But regardless of the model, the system defines the level of quality you can consistently achieve.
AI agents don’t have good habits
A senior engineer has judgement.
They know when a shortcut isn’t worth taking. They remember the production incident from three months ago. They recognise duplicated code because they’ve seen it before.
AI agents don’t.
They don’t care. They don’t remember. They don’t get tired. They don’t get embarrassed after creating the fifth copy of the same helper.
They simply observe the environment they’re given and optimise within it. Every single run. AI agents don’t really have habits. They inherit yours.
Your repository teaches more than your prompt
When people don’t get the results they expect from coding agents, the first instinct is usually to improve the prompt.
Add more instructions. Explain the architecture. Tell it to “think carefully.”
Sometimes that helps. Most of the time, I would say the repository has already won.
An AI agent learns far more from your existing codebase than from a carefully crafted prompt. If your project contains five different ways of making an HTTP request, it’ll probably create a sixth. If authentication is inconsistent, it’ll continue the inconsistency. If there are no tests, no ADRs, no documentation and no conventions, the agent isn’t going to invent them. It’s simply reflecting the engineering culture that’s already encoded in the repository.
Systems scale better than prompts
Over investing time on improving prompts is I think solving the wrong problem. A better prompt might help one implementation. A better system improves every implementation.
Every ADR. Every linter rule. Every contract. Every test. Every CI check. Every code generation step.
This is exactly what I was getting at in Engineering hygiene in the age of AI agents. CI/CD, linting, tests, ADRs, telemetry… they’re no longer just good engineering practices. They’re the environment your AI agents learn from.
The feedback loop matters even more
Humans can sometimes recognise they’ve made a mistake before anyone tells them. AI agents generally can’t. They need feedback.
Fast tests, clear compiler errors, meaningful linting, strong typing, good telemetry.
The faster the feedback loop, the faster the agent corrects itself. Without feedback, it’ll confidently continue in the wrong direction, because the system allows it.
Good engineering compounds
James Clear writes about habits compounding over time. The same thing happens with engineering systems, the difference is speed.
A convention that used to influence a handful of pull requests each week might now influence hundreds of AI-generated changes.
The opposite is also true.
A bad abstraction, an inconsistent API, missing tests, poor documentation and the list goes on.
Those now spread at AI speed. We can say that small engineering decisions suddenly have much larger consequences.
If you take this idea to its logical conclusion, you end up with systems where the correct implementation is also the easiest implementation. That’s exactly the goal behind my spec-first API pipeline: make the contract the source of truth so neither humans nor AI agents can accidentally drift away from it.
AI doesn’t replace engineering discipline
If anything, it rewards it.
I strongly believe based on my experience, that the companies which will have the biggest productivity gains from AI aren’t necessarily the ones using the smartest models.
Especially when token saving and using smaller model will become the new “frontier” (A SMB of 20 engineers is not a 200 engineers one in term of licence fees), the companies with the cleanest systems will adapt better.
The ones where the right thing is obvious and the wrong thing is difficult. The architecture is documented, the contracts are explicit.
That also changes the role of engineers.
As I wrote in AI is forcing junior engineers to think like seniors, the value is shifting away from simply producing code and toward making good engineering decisions. AI agents can inherit your habits, but they still can’t decide which habits are worth having.
I wanted to revisit and consolidate some of the ideas I’ve been writing about into another article, inspired by this book. I found the parallel with AI agents interesting enough to put it into words. In the end, they are all variations of the same idea. They’re all about improving the system.
Now the questions are: what to improve within the system, what to add into it? Borrowing Travis Kalanick’s expression, the most interesting part might be discovering the “valuable unknown truths” hidden within the systems.
AI agents fall to the level of the system.
If you have suggestions or thoughts, keep the conversation going on my Substack.