Since 2022, I no longer really wonder whether AI can code. The answer is yes. It can even produce a lot of code, very fast, in different directions, with a code quality that I see improving with every model generation.
I watched this rise up close. First as curiosity, then as a working tool, then as an environment in which part of my craft is shifting. I prefer to look at it on the scale of a workday: the lines I no longer write, the diffs I read, the decisions I keep.
The real subject starts after that: what do I do with this speed? Do I let it do the thinking for me, or do I use it to explore beyond my human limits? I am still bounded by my body, my attention, my fatigue, and the time I can actually give to this craft.
Exploring faster than my human time
I can dig for a long time, but I cannot explore every path by hand. Writing 500 useful lines of code by hand in a day is already a lot, because those final lines often hide two or three times as many trials, refactors, deletions, and reversals.
This relationship to time changes. AI can produce a first track, a variant, a second approach, then a counter-example, much faster than I can. It does not make those tracks good by magic. It gives me a volume of exploration I could not have afforded on my own.
That is the sense in which I see it as a tool for time-based exploration. It does not replace experience; it lets me cross more possible paths before choosing. My job is not to accept the first output. It is to read, compare, sense what holds, then bring the system back toward the direction that makes the most sense.
Thinking one notch above the code
I almost no longer write code by hand. If coding means typing the lines, then yes, I code much less than before. But if coding means turning an intention into a system that works, I still code: I write the intention, the constraints, the end criteria, then I review the translation produced by the machine.
Seen this way, LLMs do not step outside the history of code. They add one more layer of abstraction: after compilers, languages, IDEs, and autocompletion, natural language becomes part of the programming interface.
There is an obvious danger: asking AI to think in my place. In that case, I might save time on one task, but I lose the exercise that makes me capable of judging the next one. I do not want that.
I learned it by hitting a wall. At the very start of Claude Code, during the beta, when I was first putting my hands into the agents and the tool, I saw diffs come out that held up. I started reviewing less. Then almost not at all. I accepted the plans, I let the agents chain, and I assumed the result would be good because the previous outputs had looked good. It ended the way it had to end: too much complexity, regressions, inconsistencies, and a system I had to take back by hand while I no longer really understood it myself.
The point is not to read every for loop or every if in detail. The point is to understand the system: the boundaries between modules, the contracts, the interfaces, the tests that tell me when it breaks. When those boundaries are blurry, the agent can push a responsibility to the wrong place, wire two blocks together too quickly, or produce a solution that works locally but damages the architecture. I lived through it. As long as I understand how the blocks talk to each other, as long as the tests tell a readable intention, I keep doing my job. I just work at a higher level.
That is where the phrase “thinking amplifier” makes sense to me. AI does not amplify a thought that is not there. It mostly helps me when I already know where to look, what to refuse, and which check to run behind it. My expertise stays put, and AI gives me material to build around it: a prototype, an interface, a script, a piece of documentation, an architecture lead. It does not replace my technique. It gives me more grip.
Conducting without letting go of the wheel
The image of the conductor still speaks to me, as long as it stays attached to the actual work. In my daily practice, that means: I give the intention, I bound the task, I sometimes pick an agent or a sub-agent, I review what comes back, I cut when the frame gets too heavy.
Driving agents does not mean watching the work from a distance. On the contrary, the faster they move, the more I have to know where to look. A vague instruction quickly produces a lot of vague code. A poorly framed handoff loses a nuance. An over-ambitious workflow turns into an over-engineered system. My work, here, is to keep the signal readable.
This shift forced me to look at my own methods. At first, I was thinking mostly in prompts. Then in context. Then in orchestration. Then in guardrails. It was not a plan laid out in advance. It was a learning phase, like my first years as a developer: I try, I get it wrong, I correct, I understand better where the real limits are. The difference, this time, is that I am learning at the start of the agent era, while the uses, the techniques, and the tools are still being built.
What stays useful
After all those trials, I do not keep the most impressive tools. I keep what actually reduces the fog: visible boundaries, context loaded at the right moment, short rules, and automatic checks that refuse what falls outside the frame.
I keep useful context. Maximum context quickly ends up costing more than it’s worth. An agent does not need to know everything at startup. It needs to understand the frame so it can act without inventing one, then be able to load the rest when the task calls for it.
I keep short rules, close to the code, with their reason attached. A bare rule is easy to bypass. A rule that explains why a boundary exists holds better, especially when the agent has to choose between two plausible solutions.
I keep executable checks: not just writing a rule, but making sure the system can enforce it. When a constraint can become a test, a lint, an architecture check, or a CI validation, I prefer to pull it out of the prompt and have it answer automatically.
I cut the slow exhaustive scans, the context files maintained by hand, the orchestration workflows that cost more than they save. I also cut the idea that a better prompt can compensate for a fuzzy architecture. Past a certain point, more words do not give you more control. They only give you more noise.
I do not cut to aim smaller. I cut so I can keep understanding what I am building.
What I wish I had read sooner
I learned this at a time when the practices were still unstable. There was no clean highway, no obvious best practice, no simple answer to copy.
Some mistakes are worth more when they do not stay private. If a part of this journal can spare someone from losing time in the same dead ends, it will already have served a purpose.
Update (April 28, 2026)
It is almost a year now since I discovered Claude Code and started using it, among others. Over that year, I have spent more than 2,000 hours coding with AI agents. I do not know where all of this is heading, but I know that the time spent with them has changed the way I see things: I see faster where they help, where they drift, and where the developer has to stay present.
If you want to talk about it, you can write to me here: augustin.bengolea@gmail.com.
I am not coming out of this with a doctrine. I am coming out with a reflex: as long as I still understand the system, I can delegate. The day I no longer understand it, the speed gain turns into debt.