Yes, this text is long. Yes, it repeats itself in places. I did not clean that up. A text that sounded too smooth while arguing that AI forces you to think more, not less, would be at least slightly dishonest. This is not fast food for quick consumption. And yes, don’t worry: you won’t hear anything especially new here. That is part of the problem too.
There is a popular and very seductive story about AI in software development. Now that the machine can write code, the human gets to think less. You just point it in the right direction, and the model will quickly and cheaply do a significant part of the work on its own. In that picture, AI is primarily an accelerator for code production, and human thinking gradually shifts from necessity to optional extra.
I keep feeling more and more strongly that this description is dangerously wrong.
A more accurate formula for my own experience right now is this: I’m the tech lead, the AI is the entire team in one body. And if you take that metaphor seriously, the conclusion is the exact opposite of the mainstream narrative. Working with AI is not a way to think less. It is a mode in which you need to think more, not less.
Not because the AI is bad. But because it is too good at one very treacherous thing: it confidently and smoothly fills in what was left unsaid.
I’m the tech lead, the AI is the team
At first this metaphor felt like a neat formulation. Now it feels like a literal description of what is going on.
If you treat AI as a very fast and very capable executor, a lot of things become clearer immediately. It really can wipe out months of routine work. It can spin up prototypes quickly, take over test scaffolding, try out alternatives, make local edits, help break a task into parts, and sometimes even suggest a decent direction.
On the surface, this really does look like a silver bullet. Especially if the human knows the stack and can read code. The pace becomes so extreme that old assumptions about development speed can be thrown into the garbage bin of history.
But that is also exactly where the most dangerous substitution begins.
Once you have an executor this strong, the temptation is to reduce your role to something like this: state the overall goal, wave your hand vaguely in the direction of the task, and then mostly stay out of the way. The system is smart, surely it will figure it out. And this is where the tech lead metaphor becomes genuinely useful: a good tech lead does not stop thinking just because the team is strong. On the contrary, the stronger the team, the more expensive mistakes in framing, boundaries, and verification become.
A strong tech lead does not lose their work. The work is still there. It’s just not where people think it is. They do not have to personally write every line, but they do have to hold onto:
- the larger goal for the near future;
- the boundaries of the change;
- the signs that a task is actually complete;
- an understanding of what must not be broken on the way there;
- and a way to verify that the team did not produce something externally polished but systemically dangerous.
If you map this onto working with AI, it turns out that the core human responsibilities have not gone anywhere. If anything, they have become stricter.
The main risk is not bad code, but loss of ownership of intent
When people talk about problems with AI in programming, they usually discuss fairly simple things: hallucinations, nonexistent functions, weird syntax, weak tests, generic code, unsafe fragments. All of that happens. But that is not the most unpleasant part.
The real trouble starts when the code looks fine.
It is clean. It is tidy. It passes tests. It has sensible variable names. It does exactly what was requested. If you look at it as a local artifact, it may look more than convincing.
That is exactly why the danger here runs deeper than just bad code.
The problem is that when working with AI, it becomes very easy to lose ownership of intent. That means losing the actual link between:
- what we are actually trying to achieve;
- why the system is designed this way rather than another;
- what constraints and invariants exist here;
- and how we distinguish a real solution that works in real life from a plausible imitation of a solution.
Once that ownership is lost, a very unpleasant state appears: “it works, but I don’t know why.” And right behind it comes another one: “and I don’t know what will break it.”
This is especially treacherous because the failure does not happen at the moment of generation. At the moment of generation, everything may look excellent. The problem surfaces later — during the next change, at an edge case, on a repeated call, in a partial failure, when several locally reasonable decisions collide and together create systemic fragility.
So the main trap here is not that the AI wrote nonsense. The main trap is that the human stopped being the owner of their own system.
Why AI forces you to think more
This sounds paradoxical only at first glance. In reality it is fairly simple.
The stronger the executor, the more dangerous an unclear framing becomes. The faster the work gets done, the faster mistakes in intent materialize. The better the system gets at filling gaps, the more dangerous every unstated assumption becomes.
If earlier a good developer could ask a follow-up question or at least avoid rushing into implementation, now the model — in some sense carrying the experience of the whole world — fills in the blanks on its own. The further this goes, the better it gets, the more plausible it becomes, but not necessarily in a way that fits this specific context. And it does all of that silently.
So AI does not lower the demands on thinking. It makes thinking more mandatory and more disciplined.
Working with AI leaves you with no real choice but to:
- write the goal down instead of holding it as a vague feeling;
- separate the larger goal from the local request;
- know in advance what counts as done;
- define a contract for each step: inputs, outputs, errors, edge cases;
- not accept the proposed decomposition automatically;
- not accept code based on external impression alone;
- not stop at the happy path;
- read diffs and run checks;
- and keep in mind what stands above the code: its behavior in the real world.
So with AI, it is not only the speed of code production that changes. The very point where human intelligence gets applied changes. It used to be enough to be the person who writes well by hand. Now you increasingly have to take pride in not losing the foundations of the task when the speed gets too high.
Why “it seems to work” is a trap
One of the nastiest effects of working with AI is that it very easily produces solutions that look complete from the outside.
The feature exists. The behavior exists. The types are in place. There are some tests too. So of course it starts to feel done.
But that feeling can be false in the most dangerous sense. Because external functionality and engineering reliability are not the same thing.
You can get code that executes the stated scenario and still:
- violate existing project conventions;
- create unnecessary complexity;
- bypass an existing component instead of reusing it;
- introduce a fragile assumption;
- miss an important failure mode;
- fail to preserve a domain invariant;
- and in doing so buy future maintenance at the cost of today’s speed.
This is especially unpleasant because without review and without a full run of the checks, you suddenly end up almost in the role of a client for whom someone quickly assembled a “sort of working” product. From the outside, it’s alive. Inside, you don’t trust it.
Then three scenarios remain, and all of them are bad. Either you live with anxiety. Or you postpone the analysis until the first incident. Or you start digging immediately, but only after speed has already produced the illusion of completion.
That is why AI, for me, has turned from permission to think less into a demand to think more.
A local prompt does not carry the whole meaning of the project
There is another reason why AI-assisted development forces more thinking. A local request almost never carries all the context that is actually needed for a good solution.
What usually enters the system is not a full model of the project and not a careful list of invariants. What arrives is a local request: add a field, allow an action, change a state, insert a button, fix a flow, support a new behavior. Everything else has to be reconstructed.
Before, a human would at least notice that something essential was missing. They would slow down, clarify, remember past decisions, ask colleagues, dig into documentation, go read code. AI, by contrast, is very good at taking a narrow slice of framing and quickly turning it into a locally convincing solution.
That is the risk. Not that the model cannot do anything, but that it can continue too smoothly in places where the human should have stopped and asked: “Wait, on what basis do we think this is correct at all?”
That leads to an important point: a ticket, a prompt, or a feature request is usually not a specification. It is only a trigger. Pretending it contains the project is exactly how drift begins.
Which means that if the human gives the model nothing beyond the local request except maybe hope, then the model has to reconstruct everything else from indirect clues:
- boundaries;
- domain agreements;
- sources of truth;
- prohibitions;
- the rationale behind previous decisions.
And once that happens, AI starts rebuilding all of this from hints. Sometimes successfully. Sometimes not. But almost always with a risk of drift.
The tech lead holds not only the goal, but anti-drift discipline
If we go back to the tech lead metaphor, it becomes clear that the role in AI-assisted development is even broader than just assigning tasks.
The tech lead is needed not only to say “this is what we are doing.” They are also needed so that the project does not quietly start rewriting its own foundations piece by piece.
AI is very good at helping with local execution. But precisely because of that, someone must hold onto the things that cannot be delegated wholesale:
- which rules count as normal in this project;
- which constraints must not be bypassed silently;
- which decisions have already been made and why;
- where the system’s real invariants live;
- which compromises are acceptable and which are not.
So the human in the tech lead role becomes not just a source of tasks, but a carrier of anti-drift discipline.
This is the discipline that stops speed from turning the project into drift.
It requires very boring things:
- writing and rereading the goal;
- keeping steps manageable;
- recording important decisions in artifacts rather than leaving them in chat;
- reviewing not only the result but the line of reasoning;
- checking not only new tests but old invariants;
- asking not only “does it work?” but also “what must not happen here at all?” and “could something else quietly happen here too?”
These boring things turn out to be some of the most expensive engineering work there is.
What the tech lead actually does when working with AI
If you try to reduce all of this to a very practical loop, the human in this model is left with at least the following responsibilities.
1. Hold the larger goal
Not just the local prompt, but a longer line: what exactly are we trying to improve, what counts as success, and what matters most right now.
Without that, AI easily starts optimizing local form instead of global meaning.
2. Break the work into isolated parts
Not so large that you lose verifiability, and not so small that you drown in micromanagement.
Good decomposition here is not bureaucracy. It is a way not to overload either yourself or the model.
3. Set boundaries
What are we doing in this change, and what are we consciously not doing? Which parts of the system are in scope, and which are not? Where is a temporary solution acceptable, and where is it not?
4. Define the signs of done
Not in the sense of “well, it kind of works,” but in the sense of a verifiable contract: which inputs we support, which outputs we expect, which errors are acceptable, which edge cases must be preserved.
5. Read everything important
You do not have to manually write everything yourself. But you do have to read everything important: diffs, new decisions, key tests, controversial spots.
6. Run the existing checks
Do not stop at “the generated code passes its own tests.” All the checks that already exist matter, because those are what catch regressions against the old world.
7. Turn decisions into artifacts
If an important decision lived only in your head or in a conversation, that is a bad decision from the perspective of long-term work with AI. Tomorrow’s agent, or tomorrow’s version of you, will start reconstructing it from scratch — and will most likely get it wrong.
Why this matters beyond code
This is bigger than code.
The more AI can generate, the more valuable the ability becomes not to be a typing machine, but to:
- hold the task before the code exists;
- understand which context is mandatory;
- see long-tail consequences;
- distinguish what is locally correct from what is systemically dangerous;
- leave behind an artifact that helps the next human or the next agent avoid reinventing the foundations.
That is why the claim that “you need to think more, not less” is not some old craftsman whining about new tools. It is a literal description of the new work.
AI removes part of the mechanics from the human. But everything tied to intent, boundaries, consequence-checking, and preserving meaning becomes more expensive, not less.
What changes in the feeling of the work itself
The biggest shift here is not even procedural. It’s in your head.
Before AI, you could maintain for a long time the image of a programmer as a person who mostly writes code and sort of thinks around that process. Now it increasingly feels like writing code is no longer the central part of the role. The central part of the role is holding the system of thinking around the code.
So my work is less and less described as “I write the feature” and more and more as:
- I hold the intent;
- I define the boundaries;
- I check whether understanding has been replaced by external plausibility;
- I make sure the project does not drift;
- I turn decisions into forms that will survive both tomorrow’s me and the next agent.
In that sense, the tech lead metaphor is useful not only as a description of process. It is useful because it protects you from lying to yourself. It reminds you that once you have an extremely strong executor, the temptation to relax grows faster than the right to relax.
Thinking, you lead. Stop thinking, you get led.
If I reduce all of this to a short version, my current conclusion is this.
Working with AI is not a mode in which you finally get to stop thinking. It is a mode in which you need to think more, not less.
More — because speed increases the price of ambiguity.
More — because local framing rarely carries all the necessary context.
More — because plausible code is more dangerous than obviously bad code.
More — because someone still has to hold the goal, the boundaries, the invariants, and the method of verification.
That is why the formula “I’m the tech lead, the AI is the whole team” still feels like the most accurate one to me.
It does not romanticize AI, and it does not let the human off the hook. It returns responsibility to where it belongs: the human who must not only start the work, but also understand what exactly is being started, why, and by what evidence the result will be shown to deserve trust rather than merely looking functional.
The cruel irony is that the AI almost certainly already knows all these subtleties better than we do. If you ask it properly, it will tell you about project management, and code review, and contracts, and regressions, and all those old, good ways of not breaking a system through sheer stupidity. It will even suggest the right precautions.
But we still have to ask.
We still have to frame the question.
We still have to notice that this is a place where a question is needed at all.
And we still have to do the thinking.
