# Working with AI Means Thinking More, Not Less > Source: > Published: 2026-06-20 09:33:09+00:00 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. 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: 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. 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: 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. 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: 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. 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: 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. 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: And once that happens, AI starts rebuilding all of this from hints. Sometimes successfully. Sometimes not. But almost always with a risk of drift. 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: 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: These boring things turn out to be some of the most expensive engineering work there is. 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. 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. 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. 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? 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. You do not have to manually write everything yourself. But you do have to read everything important: diffs, new decisions, key tests, controversial spots. 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. 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. This is bigger than code. The more AI can generate, the more valuable the ability becomes not to be a typing machine, but to: 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. 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: 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. 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.