Don't Put Your Brain Down

The worst way to use AI is to treat it like a place to put your brain down.

This is also, unfortunately, the most tempting way to use it.

You open the editor, you describe the thing badly, the model produces something plausible, the tests maybe pass, the page maybe loads, and for a minute it feels like the future has arrived in exactly the way the demos promised. Less thinking. Less friction. Less of that awful grey middle where you don’t know what the right shape is yet and the code is just sitting there, waiting for you to become competent.

But that feeling is a trap.

Not because AI is bad. It isn’t. It’s useful in a way that still feels slightly absurd. The trap is thinking the usefulness comes from reducing your cognitive load. It doesn’t, or at least it shouldn’t. Good AI use doesn’t make the thinking go away. It moves the thinking up.

And up is heavier.

---

For most of software’s history, a huge amount of engineering cognition was spent close to the metal of the work. Syntax. APIs. Framework mechanics. Remembering whether this library wants the callback first or last. Knowing the ORM incantation. Holding seven files in your head while you thread one small change through the route, the service, the component, the tests, the types, the migration, the place where someone named a thing badly in 2019 and now we all live with it.

That was real cognitive load. Annoying load, often. Mechanical load. But real.

AI eats a lot of that. It can remember the API shape. It can draft the migration. It can produce the first pass of the component. It can wire the boring parts, rename the thing, update the tests, explain the unfamiliar library, translate the pattern from one part of the codebase to another. This is genuinely good. We should not pretend otherwise for the sake of sounding wise.

But when that load disappears, it doesn’t create a holiday. It creates a vacancy.

The question is what fills it.

The bad answer is nothing. You let the model fill the space, and you become an approver of plausible text. You scan instead of read. You accept instead of decide. You ask for “a clean implementation” and then mistake cleanliness for correctness. The code has the right shape, the comments sound professional, the tests assert something, and the whole thing has that weird AI sheen where every individual part seems reasonable and the total thing is somehow wrong.

This is the smell. Not AI-written code. Not speed. Not even a big diff.

The smell is the moment you realise you understand the output less than you would have understood your own worse, slower version.

That is surrendering cognitive load. And it is an anti-pattern.

A really dangerous one, because it feels like productivity.

The old version of engineering punished you for not understanding the mechanics. You couldn’t get very far if you didn’t know the language, the framework, the runtime, the system. The work itself forced a certain intimacy. You typed the code, you got stuck, you read the docs, you cursed, you backed out, you tried again. Painful, but instructional. The mechanics made you pay attention.

AI removes some of that pain. Good. Pain is not virtue. But the pain was doing a second job. It was keeping you in contact with the work.

Now you have to choose contact deliberately.

That is the shift.

The higher load¶

The engineer using AI well is not thinking less. They are thinking harder about different things.

What is the boundary of this change? Where should this concept live? Is this feature actually a feature, or is it a symptom of a missing model? What happens when this customer has ten thousand assets instead of ten? What invariant are we protecting? What does this make easier next month? What does it make harder? Are we teaching the system the right idea, or just getting the ticket across the line?

This is not lighter work. It is just less syntactic.

And frankly, it is the better work.

Because syntax was never the point. Mechanics were never the point. They mattered because they were the path to the point. The point was always judgement. Taste. Direction. Architecture. The ability to look at a messy request from a customer and see the system underneath it. The ability to say no to the convenient implementation because it bends the product in a direction you don’t want to go. The ability to notice that the model has solved exactly the problem you described, and that you described the wrong problem.

AI makes that failure mode cheaper. That’s the scary part.

You can now be wrong at extraordinary speed.

Before, bad direction had friction. You could still build the wrong thing, obviously, we did it constantly, but it took time. The slowness gave the world a chance to interrupt. Someone would ask a question. You’d hit a technical snag. The implementation would feel ugly and force you back to the design. There were opportunities for reality to object.

Now the wrong path can be beautifully paved in an afternoon.

So the cognitive load has to intensify at the level where direction is set. You have to spend more effort on the prompt behind the prompt. Not “make me a settings page”, but why does this setting exist, who owns it, what happens when it conflicts with policy, should it be configurable at all. Not “add caching”, but what truth are we allowed to serve stale, to whom, and for how long. Not “refactor this service”, but what boundary is trying to emerge here, and do we actually want it.

This is tiring.

Good. It should be.

There is a version of AI-assisted engineering that feels relaxing because the model is doing all the visible work. I don’t trust that feeling. The visible work used to be where a lot of engineering lived, so when it disappears, we confuse the disappearance for relief. But the responsible version is more like air traffic control. Less handcraft, more consequence. Less typing, more deciding. You are not laying every brick anymore, but you are now responsible for whether the building should have that wall in the first place.

That is a higher load, not a lower one.

The brilliant junior¶

The best engineers will probably look more thoughtful, not less. More annoying too. They will stop the AI mid-flight. They will throw away working code because the shape is wrong. They will ask for three approaches and pick none of them. They will use the model to explore the design space, then take responsibility for the path. They will read the diff like it was written by a brilliant junior engineer who had no context and no fear.

Which is basically what it is.

The temptation is to anthropomorphise AI as a teammate and then quietly demote yourself to manager. “It built the thing, I reviewed it.” But review is not enough if you never owned the idea. You can’t outsource the centre of gravity and then claim authorship at the end. Standing behind the work means you understood the tradeoffs before the code existed, while it was being made, and after it came out.

The load didn’t disappear. It became authorship.

So maybe the rule is simple: if AI makes you feel less responsible, you’re using it wrong.

It should make you feel more responsible. More aware of the paths not taken. More alert to the cheapness of production. More suspicious of plausible output. More focused on the customer, the system, the architecture, the direction. The machine can generate options forever. That doesn’t make any of them right.

The job is still to know what right looks like.

AI can help with almost everything around that. It can widen the search, accelerate the boring parts, expose alternatives, challenge assumptions, draft the scaffolding, clean up the mess. Wonderful. Use it aggressively.

But don’t put your brain down.

Pick it up and move it higher.