The Slot Machine That Codes For You

Quick heads up

My book is out.

"How to Think With AI" is now on Amazon and Apple iBooks. Paper version coming soon.

Not a tutorial (those go stale by the time they're printed). Not a hype book. 13 chapters on what actually separates the people getting extraordinary work out of AI from the people producing slop.

The subtitle is the whole pitch: Why the Same Tool Produces Genius for Some and Mediocrity for Others.

Get the book here. The French version is also available here.

---

My friend Sofia is a deep-stack developer I've worked with for years.

The best I know.

(The kind who used to spend Saturday mornings reading the Linux kernel for fun…. and who'd debug a flaky distributed system at 2 a.m. and come out the other side genuinely happier than when she went in.)

She messaged me recently:

"I just spent four hours watching Claude write a service I could have written in forty minutes. It compiled. Tests pass. I have no idea what's in it. Please tell me I'm not the only one."

I sat with that for a minute. Then I read it again.

I'm not going to tell you what I wrote back. Not yet. But here is what I thought, sitting in the dark looking at the message.

This is the most senior engineer I know, and she has just described, in her own words, the cleanest portrait of a profession going hollow.

If Sofia is feeling this, the floor is gone.

---

The thing nobody wants to say out loud about agentic coding is that the workflow is a slot machine.

You write the spec. You generate the plan. You pull the lever. You wait. The screen fills with code. You scan it, you don't really read it, you tell the agent what looks off, you pull the lever again. Sometimes you have two or three agents running, and the day becomes a kind of croupier dance, attention bouncing between tabs, each pull producing something plausible.

A developer named Lars Fay wrote an essay on this called Agentic Coding Is A Trap. It has been forwarded to me by enough senior engineers in the last two weeks that I want to walk through it carefully, because Fay names the thing the industry has been refusing to name.

Here is the paradox he draws out, and I think it's exact.

The only person who can safely run an agentic coding workflow is a senior engineer with strong architectural taste and the discipline to read every line of generated code with suspicion. And the workflow itself, run long enough, is the most efficient method ever invented for destroying exactly that taste and that discipline.

You need the muscle to use the tool. The tool atrophies the muscle. The longer you use it, the less qualified you are to use it.

This letter is about software engineering. I think this will happen to many professions in the next decade.

I have been writing this column for almost two years. I have circled this same shape from a dozen angles. Letter 73 on Bainbridge and the automation irony in cockpits. Letter 76 on verification as the only skill that still matters. Letter 78 on process first, agent second. Letter 85 on how we stopped making seniors. Letter 86 on the cognitive gym.

This one is the engineering version. And it is, I think, the most concrete instance of the whole arc. Because in coding, the artifact is unambiguous. Either the code works in production, or it doesn't. There is no consulting-deck plausibility to hide behind. Either you, the human, can read the diff, or you cannot.

What the slot machine does to a senior

Let's be careful here. I am not making the lazy argument that AI tools make engineers worse. The careful version is more specific and more uncomfortable.

A veteran developer I talked to last month, the kind who has shipped infrastructure used by tens of millions of people, gave me four points I haven't stopped thinking about.

One. The tools genuinely are faster, if you are highly skilled and have strict rules around them. He still uses them daily. He is not a Luddite. He is a craftsman who picked up a power tool and noticed it cuts straighter than he can.

Two. Context-switching is the silent killer. An agent works for ninety seconds, two minutes, sometimes more. Nobody can sit in front of a progress bar for two minutes without alt-tabbing. So you do. You check Slack. You glance at the second agent in the other window. You skim a doc. By the time the agent comes back, your mental model of what you were even asking for has degraded. Multiply that by forty cycles a day and you have a brain marinating in fragmentation.

Three. He said this verbatim and it stopped me cold. "I absolutely feel the effects of skill atrophy. This used to be my source for deep work. It no longer is."

Read that again. Coding, for him, was the gym. It was the place where the deep-thinking muscle got its daily reps. He has now converted it into a supervisory loop punctuated by waiting. The reps are gone. He noticed. Most people do not notice.

Four, and this is the one that should keep every engineering leader up at night. Management is starting to measure engineer productivity in token counts (which is honestly silly). The number of tokens an engineer consumes per week, charted on a dashboard. Lines of code was a famously broken KPI in the 1990s and we all laughed at the managers who used it. Token count is the same KPI with a fresh paint job and worse incentives. It rewards the slot machine, punishes the engineer who pauses to think, and produces precisely the kind of plausible BS that takes down a system in production six months later.

Plausible and correct are not the same thing. The dashboard cannot tell the difference. The dashboard rewards plausible.

What it does to the juniors

The senior story is bad. The junior story is worse, because the juniors never had the muscle to begin with.

A team lead at a fintech wrote on Reddit last month, and I'll paraphrase because the line is brutal in its plainness: the juniors on my team ship fast and cannot debug anything they did not actually write.

That is the entire crisis in one sentence. The output looks the same. The capacity behind the output does not exist. The moment a system breaks in a way the agent did not foresee, and systems always eventually break in ways the agent did not foresee, there is nobody in the room who can hold the whole picture in their head and reason about what went wrong.

There is a term computer science professors have been using for two years now. The junior year wall. Students who AI-cheated their way through the introductory classes, where you are supposed to suffer through pointers and recursion and memory layout and segfaults, hit a wall in their third year. The work suddenly requires composition, abstraction, debugging, the ability to read a stranger's codebase and reason about it. None of those skills were ever built. The cheating worked. The wall is still there.

Industry just imported the junior year wall, at scale, into production codebases. We have hired a generation of engineers whose first reflex when they see an error is to paste it into a chat window. They have never sat with an error for forty minutes. They have never built the internal map of how systems fail. They never will, because the map was supposed to be drawn during exactly the years (or the hours of suffering) they are now skipping or outsourcing.

Sofia is the senior who feels the muscle going. The juniors are the cohort that never built it. Both problems compound. Both are invisible until the day the system fails and the room goes quiet.

That day arrives. It always arrives. The model is right just often enough that you stop checking. The day you stop checking is the day you stop learning. The day you stop learning is the day you become unable to catch the model on the morning it is confidently, beautifully, catastrophically wrong.

And the bench is empty, because you spent the last two years quietly choosing not to train.

The honest fix

Fay's answer in his essay is, I think, exactly right, and it is the answer almost nobody in the industry wants to print on a slide.

Demote the agent.

He uses LLMs for specs and planning. He writes most of the code himself, between twenty percent and one hundred percent depending on how important the task is. When he does ask the model to write, he hands it pseudo-code, so the architectural decisions stay in his head. And he has a hard rule: he never asks an LLM to implement something he has never done before, or could not do on his own.

Read that last line slowly. It is the inversion of the entire industry pitch.

(I know that most engineers will jump out of their chair now, because writing 100% of code is becoming “impossible” for some and “silly” for others. But if you think that, think about the full physical workouts you do in the gym… while you sit all day… Isn’t that silly?)

The pitch says: agents will let you build things you could never build alone. The honest practitioner says: I will never delegate to an agent a thing I could not do myself, because if I do, I lose the ability to verify the work, and unverifiable work in production is just gorgeous garbage waiting to detonate.

This is process first, agent second, applied to the most concrete craft we have. The prompt is never the bottleneck. The bottleneck is the engineer's capacity to hold a system in their head and know, with quiet certainty, whether the thing on the screen will survive contact with reality.

Your expertise is GPS coordinates. The model is the car. If you do not know where you are going, the fastest car in the world drives you off a cliff.

What to do Monday morning

Pick one. Not five. The whole point is sustainability, and a team that tries to install five new disciplines in a week will install zero.

One. Write the next non-trivial function by hand. No autocomplete past a single line, no agent, no chat window. Whatever it is. A parser, a controller, a small utility. Notice what your brain feels like at minute fifteen. If it feels uncomfortable, that is the muscle waking up. That discomfort is the entire signal. Do this once a week, every week, for the rest of your career.

Two. Institute a read-the-diff rule. No PR merges into your main branch until a human has read every line of every file in the diff and can defend each change in code review. If the diff is too large to read carefully, the diff is too large to merge. Break it up. This single rule, enforced for ninety days, will reset your team's relationship with generated code more than any internal training program.

Three. Kill the token-count dashboard. If your engineering org has one, delete it this quarter. If your VP is asking for one, push back in writing, with a paragraph on why measuring tokens is the 2026 version of measuring lines of code. Replace it, if you must replace it with something, with incidents per quarter and time-to-diagnose. Those metrics reward the engineer who actually understands the system.

Four. Run a no-agent day. Pick one day a week. Tuesday works well for most teams. On that day, no coding agents. People can still use a chat window to ask a conceptual question, but the IDE is theirs. The first three weeks will be slower. By week six, your seniors will notice their deep-work capacity coming back. By week twelve, your juniors will have built things they will actually be able to debug.

Five. Adopt Fay's rule, in writing. Make it a team principle: we do not ask an agent to implement anything a member of this team could not implement themselves. Print it. Pin it in the channel. The rule will feel limiting at first, because it is. That limit is what protects the team from shipping things it cannot maintain. The limit is the moat.

If you are an engineering leader, do not roll out all five at once. Pick the one your team is most likely to actually sustain. Run it for ninety days. Measure how the team feels at the end. Then pick the next one. The companies that get this right in 2026 will look slow compared to the ones pulling the slot-machine lever forty times an hour. In 2028, the slow ones will still have systems they can defend, and engineers who can defend them, and the fast ones will be paying consultants to forensically reconstruct codebases nobody on the original team understood.

Back to Sofia

I wrote Sofia back at midnight. The message was one line.

"Close the laptop. Tomorrow, write the next service by hand. Tell me how you feel at lunchtime."

She wrote me again on Thursday. She had written most of the service herself. It took her three hours, not forty minutes.

(She felt like she was doing something silly at the beginning, but like a good workout, she felt exceptionally good after the effort.)

It worked the first time it deployed. And she said something that I'm going to put in front of every engineering leader I talk to for the rest of the year.

"It was the first day in eight months I felt like a software engineer instead of a manager of slot machines."

That is the bill. We are paying it now, in the form of seniors going quietly hollow and juniors who hit a wall they did not know was coming. We have maybe a five-year window to start paying it down before it compounds into the kind of crisis that ends with a famous outage and a long article about how nobody on the original team could read the code.

I know this might not resonate with non-engineers. It may feel like this letter is only about using AI for coding. It is not. Right now we see the problem most clearly in coding because coding is where existing AI systems are most capable. This problem will become self-evident everywhere, across professions, verticals, and jobs.

AI is an amplifier, not an equalizer. It amplifies the person who already has taste and judgment. It hollows out the person who does not. The line between those two outcomes is whether the human is still doing the reps.

AI is only as good as the human operating it.

Have a great weekend.

Stay sharp.

— Charafeddine (CM)