“I’m not sure, the AI suggested it.”
As a tech lead, this is probably the worst sentence I’ve heard this year.
Let’s be clear: when you commit code, whether you typed it yourself or it was suggested by an agent, it’s your code. You own it and you’re accountable for it. Period.
We’re living in an exceptional time. Tools are more powerful than ever, and our profession, which until recently seemed safe from automation, is being radically transformed by generative AI and agents.
I don’t think we can fully grasp the extent of this shift, but one thing is certain: responsibility for the code still lies in our hands.
The Principle of Responsibility Link to heading
We are responsible for the code we produce. That’s not a revolutionary idea. In fact, it’s a fundamental principle of engineering and software development. It has always been that way, and there’s no reason for it to change with the arrival of agents.
The same principle applies in every field where safety, reliability, and quality are crucial. For example, a civil engineer is responsible for the safety of a bridge, even if they use software to run the calculations. A doctor is responsible for a diagnosis, even if they use AI tools for decision support.
Have you read Extreme Ownership by Jocko Willink? You may agree or disagree with some of his views, but the core idea is absolutely relevant: you are responsible for everything under your command. Even if it comes from a subordinate, even if it was done without your knowledge. In our case, the agent is that subordinate.
The mindset is simple: no excuses. It’s not “the AI did it.” The agent is like an assistant, or a junior colleague, for whom you are responsible.
Alright, that’s quite simple in principle, but I see three major traps that make things more complicated.
Trap #1: Understanding and Learning Link to heading
Programming is learned by writing code. There are no shortcuts. That’s just the way it is. More broadly, humans learn far better by doing than by simply watching. That too is a fact.
When you write code yourself, you’re forced to think through each line, each decision. You make mistakes, you fix them, you learn. It’s an active process.
With an agent, you risk becoming passive. You ask for something, you get a suggestion, you apply it without really understanding. The ownership you gain by writing code yourself is no longer automatic. That’s the first trap.
Trap #2: Code Volume Inflation Link to heading
Agents write fast. Very fast. Used well, they can generate in minutes a large amount of quality code. Moreover, the produced code is often better than what a human could produce in ten times as long. That’s great, but also dangerous.
More code written means more code to understand, maintain, and test. At some point, you end up with a huge codebase that’s hard to fully master. That’s not a new problem, but with agents, the pace accelerates. In other words, we risk hitting the same wall, only much faster than before. In that context, it’s easy to lower our guard, defer to the agent, and give up ownership. That’s the second trap.
Trap #3: The Pressure to Deliver Link to heading
It’s clear that agents save us time when writing code. But in doing so, they set a precedent where everything is expected to move faster and faster. There’s pressure from decision makers to deliver quickly.
“If it takes 10 times less time to write, why don’t we ship 10 times more features?”
The problem is, those decision makers are rarely the best individuals to decide what’s “good enough.” That’s our job, as professionals. But watch out: this doesn’t mean slamming the brakes and slowing development to a crawl. The goal is to find the right balance between speed and quality. External pressure can push us to let the agent do the work unsupervised and relinquish control. That’s the third trap.
Staying in Control Link to heading
If we want to stay in control, discipline is non-negotiable. Reviewing generated code isn’t enough. You need to understand it. Even better: you should be able to explain every single choice made by the agent. Until you can do that, your work isn’t done.
Here are my practical strategies for staying in control:
- Use the agent as a learning tool. For example, ask it: “explain why you chose this approach.” That helps you understand the reasoning behind the code.
- Reject code you don’t understand. If the agent produces confusing or obscure code, ask it to rewrite it in a clearer way.
- Always ask yourself: “Am I ready to defend this in a code review?” Because guess what? You’ll have to.
- Write the documentation yourself. Nobody loves it, and it’s tempting to let the agent do it. But writing it forces you to rephrase, to explain, and therefore to understand. It’s extra work, but it’s an investment that ensures you really master your code.
These strategies aren’t just useful tips. They’re conditions for staying in control and fully owning your role as a responsible developer.
Conclusion Link to heading
At the end of the day, the message is simple: from now on, zero tolerance for lack of ownership.
The agent transition is already underway. It’s inevitable.
But that’s not a bad thing. Quite the opposite.
In the past, writing code was costly in both time and energy. We didn’t have the luxury to go beyond “good enough.”
Today, asking for another version or testing a different approach costs almost nothing, so why not use that to:
- Be uncompromising about readability and clarity.
- Refuse to compromise on quality.
- Explore multiple alternatives before picking the best one.
- Write better tests and genuinely useful documentation.
That’s the real paradigm shift: agents are not an excuse to lower our standards. Quite the opposite! They’re an opportunity to raise them.
So from now on: no excuses, only ownership.