The Cognitive Cost of Modern Software Engineering

AI took the typing, and the cost of building software did not go away. It moved, from the hands to the head, and on the way it got heavier. The work is more productive than it has ever been and more tiring than it has ever been, and those two facts are the same fact. This is the part the pitch leaves out.

The story everyone tells about AI and software engineering is a story about speed. The code writes itself. A month of work becomes an afternoon. That story is true, and I have lived it, and it is the least honest version of what happened, because it implies the work got easier. It did not get easier. It got more concentrated, and concentration has a price that you pay with your mind, all day, without the breaks the old work used to give you for free.

I want to describe that price plainly, because I have not seen many people name it, and because naming it is the first step to managing it. The companion to this is Agent Mode Changes the Shape of Thought, which is about the opportunity. This one is about what the opportunity costs you, and it is not a small thing.

The bottleneck moved, and so did the cost

I have written software professionally for over fifteen years. I have said elsewhere, in how AI is changing software engineering, that the headline is short: AI did not replace engineers, it moved the bottleneck. The cost of writing code dropped to near zero, and the cost of deciding what to build, how to architect it, and when to ship became the whole job.

Follow that one step further than the productivity articles do. If the bottleneck moved, the cost moved with it. The work did not lose its weight. The weight relocated. It used to sit in your hands and your hours, in the sheer volume of typing and stitching and translating that a week of building required. Now it sits in your head, in the unbroken sequence of decisions that is all that remains when the typing is gone. And the head is a more expensive place to spend than the hands, because the hands can work while the mind rests, and the mind cannot rest while it is the only thing working.

That is the whole essay in one sentence, but the sentence does not land until you have felt the specific ways the cost shows up. So let me be concrete about them.

Typing was rest, and nobody says so

Here is the thing I did not understand until it was gone. The mechanical part of programming, the part that AI took, was never the hard part, and everyone knew that. What nobody said is that it was also a kind of rest.

For most of my career a real share of a working week was typing. Boilerplate. Translating a clear idea into a verbose language. Wiring API responses together. Writing the tests that exercise the mechanical paths through code I had just written. Updating the documentation after the refactor. None of that was where the engineering lived. But it was where the day had its valleys. After you made the hard decision, you got to spend an hour or two simply executing it, and the executing was a place the mind could idle. You were producing real work and recovering at the same time. The hands moved and the deeper part of you got to coast.

Take that away and the valleys disappear. The day becomes a ridgeline. Decision after decision, with no flat stretch in between, because the flat stretches were exactly the parts the agent now does in seconds. I describe what I want, and before I have finished my coffee the change is back and it needs a judgment from me. There is no longer an hour of mechanical typing to hide inside while my mind catches its breath. The breath-catching has to be scheduled now, deliberately, because the work will not hand it to you the way it used to.

This is not nostalgia for boilerplate. I do not miss the typing. I am pointing at a real ergonomic fact that the productivity framing erases: the old work had built-in recovery, and the new work does not, and if you do not replace that recovery on purpose you will run yourself down at a rate the old job could not have managed.

What is left is judgment, and judgment is expensive

When the typing goes, what remains is louder, and all of it is the costly kind of work.

I read more code now than I ever have, and most of it I did not write. Reading code was once maybe a tenth of the job. It is closer to two thirds of mine now: absorbing an unfamiliar stretch the agent just produced, deciding whether it is correct, whether the error handling is right, whether it interacts cleanly with the rest of the system, whether it quietly made an architectural choice while I was looking away. Reading is more tiring than writing, because writing your own code carries you forward on your own intent, and reading someone else's, even a machine's, means reconstructing an intent from the outside and checking it against what you actually wanted. You are doing that, at speed, all day.

Deciding what to build is now the front of the work instead of the preface to it. A model will build the wrong thing beautifully and fast, and the cost of a wrong decision used to be amortized across the weeks it took to implement. Now the wrong thing arrives in an afternoon, fully formed, and you either live with it or back it out. The pressure on the quality of your specification, on knowing what you actually want before the machine commits you to a polished version of a guess, is constant and it does not relent.

And there is a decision that barely existed before and is now one of the most important and most draining: knowing when to stop the agent. Agents do not get tired and they do not stop. They will refactor what did not need refactoring, scaffold for problems you do not have, keep going confidently past the point where they should have asked. The discipline to interrupt, redirect, and reject is the new craft, and restraint is the most expensive new failure mode, because the temptation to do more, faster, simply because you can, is always right there, and saying no to it dozens of times a day is its own kind of fatigue.

None of these are the parts of engineering that let your mind coast. They are the parts that demand all of it. The job did not get smaller. It got distilled down to nothing but its hardest fraction, and then you do that fraction continuously.

The new failure mode is overload, not slowness

For my whole career the limiting factor was throughput. You could only produce so much in a day, and the failure mode was being too slow: the project that took too long, the backlog that grew faster than you could burn it down.

That failure mode is mostly gone, and a stranger one took its place. When a two-week project ships in two days, the obvious move is to run ten of them at once across the same calendar, because you can. I have done exactly this. And it does not give you more leisure. It gives you ten times the judgment to supply, ten streams to keep coherent, ten contexts to hold and switch between, ten places where a confident mistake can slip through because your attention was on stream seven when stream three went wrong.

The bottleneck is no longer how fast you can produce. It is how much you can hold without losing the thread. That is a cognitive limit, not a physical one, and it is a real ceiling. Past a certain number of live streams the coherence starts to fray, you stop catching the thing heading the wrong direction, and the very capability that let you take on ten projects becomes the reason all ten degrade at once. The new way to fail is not to be too slow. It is to take on more than one mind can keep clear, at the exact speed that makes that easy to do without noticing.

The intensity is real, and it has a body

I do not want to keep this abstract, because the cost is not abstract. I lived its sharpest version in a stretch I wrote about as six weeks living at machine speed.

In those weeks time stopped behaving normally. I wrote in my journal that a single month felt like a year. The line between my own thinking and the machine's processing mostly stopped existing. I was meeting more frameworks and systems in a week than I used to read about in a year, all of it at once, none of it letting up. My computer ran hot from the load, and that heat was a fair picture of what was happening inside my head. I wrote, plainly, that working with a partner all day, whether human or not, is tiring. The tiredness came with a charge to it, and both things were true. We were building about as fast as I could think, and thinking that fast for that long has a cost your body will eventually present to you.

The part I want to flag is what happened to rest. When you can make an idea real about as fast as you have it, sleep starts to feel like an interruption. I have the timestamps to prove it: Thursday 2am commits, Friday 4am pushes, weekend marathons, not because anything forced me but because I could not put it down. That is the seductive shape of this work. It does not exhaust you against your will. It exhausts you with your full enthusiastic cooperation, because the loop between idea and result got so tight and so rewarding that stepping out of it feels like loss. The old job protected you a little by being slow. This one removes the protection and replaces it with a thrill, and a thrill is not a substitute for sleep no matter how convincing it is at 3am.

The scarce resource is now you

Put all of it together and the conclusion is uncomfortable and clarifying at once. The scarce resource in modern software engineering is no longer compute, or time, or the supply of people who can type the code. It is your own attention, your clarity, the amount of context you can hold at once without it going blurry.

Picture it as a loom. The parallel threads of work you run at once are exactly that, threads, and a thread on its own is just a loose strand. Attention is the frame that holds the threads in tension and turns them into a fabric instead of a tangle. The weave is only ever as good as the loom, and a loom has a width. Run more threads than it can hold and they slacken and cross, and the pattern you were making comes apart in your hands. The machine can spin thread faster than anyone ever has. What it cannot do is widen your loom. That part is fixed, it is yours, and everything you make is woven on it.

The machine took over the part that scaled with hours, and handed back the part that scales with the quality and the freshness of your mind. Which means your mind is now the constraint on everything, and a constraint is something you have to manage deliberately or it manages you.

This reframes what it means to be good at this job. It is no longer mainly about how much you can produce, because production is cheap. It is about how well you can protect and direct the one input that is now scarce. The most productive thing I can do on a given day is often not to open another stream. It is to keep my head clear enough that the streams I already have get real judgment instead of a tired approximation of it. That is a sentence I would have found ridiculous a few years ago, when the obvious path to more output was more hours. The path to more output now runs through a rested, clear, undivided mind, and that mind is finite in a way that the old bottleneck never made you confront.

How you pay it down

So the discipline that this era actually demands is not a new framework or a faster tool. It is the management of your own cognition as the scarce resource it has become, and most of it is unglamorous.

The first move is legibility. The thing that overwhelms you is not the size of the system, it is the system being illegible, too tangled to hold in your head, so that every decision costs more than it should because you have to reconstruct the whole shape before you can reason about a part of it. The defense is to keep the system understandable on purpose, to spend real effort making the complex thing simple enough to reason about, which is the larger idea underneath everything I build, the practice of making a complex system legible enough to live inside. A legible system is cheap to think about. An illegible one taxes you on every single move, and the tax compounds.

The second move is restraint, which I have already named as the new craft and will name again because it is that important. Not every project that can be run should be run. Not every refactor the agent offers should be taken. The capacity to do more is not a reason to do more, and the engineers who burn out fastest in this era will not be the ones who could not keep up. They will be the ones who could, and did not know where to stop. Saying no to your own capability is now a core professional skill.

The third move is to treat rest as part of the work rather than a failure of it. The old job built recovery into the day and you could afford to be careless about it. This one does not, so you have to put it back deliberately, and you have to defend it against the thrill that tells you the loop is too good to leave. Sleep is not an interruption of the work. It is the maintenance of the only instrument the work now depends on. I came to this the hard way, and it is the same antifragile instinct I try to apply everywhere, that a little structure and a little protection on the downside is what lets a system, or a person, gain from intensity instead of being broken by it.

The last move is to know your own limit, honestly, the number of live streams past which your coherence frays, and to stop short of it on purpose. That number is real, it is personal, and it is lower than your ambition wants it to be. Finding it and respecting it is the difference between using this capability for a long time and using it brilliantly for a while and then crashing.

There is a practical version of all of this that I had to learn by hand: protect blocks of single-threaded attention on purpose, where you run one stream and let the loom hold a single clean pattern instead of a dozen fraying ones. The instinct of the era is to parallelize everything, because you can, and some of the most valuable work I do now is the deliberate refusal to, the hour given over to one hard problem with my whole undivided head. The machine made breadth cheap. Depth stayed expensive, and depth is still where the hard decisions get made well.

The work got more human, not less

There is a fear that AI hollows out engineering, turns it into prompting, removes the craft. My experience is close to the opposite, and the cost is the proof. The machine took the parts that were mechanical, the typing and the translation, the parts that were never really you. What it left behind is the parts that are nothing but you: the taste to know what is worth building, the judgment to know when something that looks right is wrong, the clarity to hold a complex thing in your head, the restraint to stop. Those parts are expensive precisely because they are human, and they cannot be delegated, and there is now nowhere to hide from them inside an afternoon of comfortable typing.

That is why the work is more tiring even as it is more productive. You are spending the whole day in the part of yourself that costs the most to spend. The bargain is real and it is good, but it is a bargain, and pretending it is free is how people get hurt by it. Name the cost, manage the resource, protect the mind, and you can do this for a long time and love it. Ignore the cost because the productivity numbers are intoxicating, and the resource that the whole thing depends on, which is now you, will run out, quietly, at the exact moment you are most convinced you are invincible.

If you want the method I run inside all of this, it is the book-length version in AgentSpek, free here, and the rest of how I build this way lives at AI-Assisted Development. But the most important tool is not in any of them. It is the discipline of guarding the one resource that does not scale, and that, unlike the typing, no machine is going to take off your hands.