Three humans. Five note takers.

We are outnumbered by our own memories.

Nobody comments on it anymore. The bots slid into our meetings the way phones slid onto our dinner tables, and we all made the same silent agreement to pretend it’s normal. Every sentence spoken on this call will be transcribed three times, summarized five ways, and filed into vaults, wikis, and CRMs before we say our goodbyes. We are all frantically collecting. Building the so-called second brain, one meeting at a time.

Three weeks later, Sarah opens our next session with, “So I did what we agreed on last time.”

And I have nothing. I’m smiling and nodding while my mind sprints down empty hallways. I have three transcripts of that call. I have a summary with the action items in bold. What I don’t have is the memory. I attended that meeting.

My tools attended it harder.

The vault I told you to build

The second brain promise traces back, more or less, to David Allen, who built Getting Things Done on the idea that your mind is a lousy office and a worse filing cabinet, so you should get everything out of it and into a trusted system. Fair enough, for tasks. Then the note-taking world picked it up and turned it into the founding promise of a movement. Build a second brain. A place outside your head where all your knowledge lives, captured and organized and searchable. Free your first brain for the good stuff. The having of ideas. The thinking.

I believed it. Two years ago I wrote a piece called The CTO’s Hidden Notebook and told you to believe it too. I described my conversion at 35,000 feet, the folder structure, the linking, the beautiful painting of my brain.

I still stand behind half of that article. The half about elaboration, about writing your way to understanding, holds up. The capture half is the part I need to come clean about. Because after the Priya call, I did what any good engineer does when a system underperforms. I blamed my implementation. More plugins. Better tagging. More note takers in more meetings, on the theory that the vault wasn’t working because it wasn’t complete. The vault grew. My recall of what was in it did not. I was maintaining a reference library that referenced nothing, and feeling guilty about it the way you feel guilty about a gym membership.

The guilt was misplaced. I wasn’t failing at the system. The system is built on a picture of the brain that is wrong.

Pipes, clocks, wires, drives

The picture is your brain as a hard drive. Memories are files. Files take up space. Space is limited and unreliable, which you know, because you forget things. So the smart move is to migrate the files off the aging, leaky drive and onto external storage that’s bigger, permanent, and searchable.

It’s such a natural picture that it doesn’t feel like a metaphor. It feels like a description.

It’s a metaphor. And it’s the latest in a long, humbling line of them. Every era reaches for its most impressive technology to explain the brain, and every era turns out to be wrong.

1. The ancients described thought as fluid moving through the body.

2. Descartes looked at the water-driven automata in the royal gardens and described nerves as pipes and the brain as a pump.

3. When Europe filled with clocks, the brain became clockwork.

4. The telegraph arrived and the nervous system became wires.

5. Then the switchboard.

6. Then, in our lifetime, the computer, with its input, processing, storage, and retrieval.

Each metaphor felt obvious to the people using it. Each one was the shape of the newest machine, pressed onto the oldest mystery. Each one was eventually set down.

We’re living inside the computer one, which is why it’s so hard to see as a choice. But the science we actually have says memory does not work like storage and retrieval, and it hasn’t for a long time.

Memory is not a recording. It’s an act. When you remember something, you are not opening a file. You are rebuilding the thing, in the moment, out of fragments and patterns and the state you’re in right now.

Now follow the consequence, because it’s the whole point. If a memory is not a file, if it’s a pattern in your tissue that gets rebuilt each time you use it, then there is nothing to move to external storage. There is no file to drag off the drive. You can write a note about the memory. You can leave yourself a cue that helps you rebuild it later. But the note is not the memory, any more than a photograph of a friend is the friend.

Knowledge isn’t a thing you hold. It’s a thing you do.

The receipt is not the meal

The honest objection arrives on schedule. Isn’t the brain genuinely bad at storage? Yes. Obviously. But that’s beside the point. Storage was never the job. The job of memory is to let you recognize, generalize, predict, and act. Calling the brain bad at storage is like calling a river bad at being a lake.

The research here is not subtle, and it did not start with AI.

In 1992, UCLA memory scientists Robert and Elizabeth Bjork drew a distinction that should be required reading for every knowledge worker. A memory has storage strength, how well-learned it is, and retrieval strength, how easily you can summon it right now. The two are not the same, and their relationship contains a trap. The Bjorks found that the easier something is to retrieve in the moment, the less durable learning you gain from encountering it again. Effortless access produces almost no learning.

The struggle to recall is not a bug in the process. The struggle is the process.

In 2011, Betsy Sparrow, Jenny Liu, and Daniel Wegner published a study in Science on what they called Google effects on memory. When people expected information to remain accessible later, they recalled the information itself worse and remembered where to find it better. The brain, sensing a reliable external partner, quietly reassigns the job. It stops storing the what and starts storing the where.

In 2014, Linda Henkel led students through an art museum and found that the ones who photographed the objects remembered fewer of them, and fewer details about them, than the ones who simply looked. She called it the photo-taking impairment effect. The camera captured everything. The photographers retained less. And the detail I can’t stop thinking about is this: when participants zoomed in on a specific feature of an object, the impairment disappeared. Attention repaired what outsourcing had broken.

Swap the camera for a meeting bot and tell me the experiment isn’t running in your calendar right now.

The newest data point is rougher but hard to ignore. In 2025, researchers at the MIT Media Lab monitored people writing essays with ChatGPT, with a search engine, or with nothing but their own heads. The ChatGPT group showed the weakest neural connectivity of the three, and 83% of them could not accurately quote from essays they had written minutes earlier. Their own essays. Minutes earlier. It’s a preprint with 54 participants and it has taken methodological criticism, so hold it loosely. But notice how neatly it rhymes with everything from Bartlett forward. The pattern across seven decades of research points one direction. When the tool does the remembering, you don’t.

Every time you tell yourself the note is the memory, you skip the part that would have made it one.

The five uncomfortable seconds of putting the idea in your own words. The effort of connecting it to something you already know. Capture lets you skip that work and feel like you didn’t.

You get the receipt and skip the meal, and then you wonder why you’re still hungry.

The closed-book exam

Why does this matter to you more this year than it did two years ago? Because capture just became free. The note takers outnumber the humans now, and every meeting ends with the warm feeling that it’s all handled.

Meanwhile, consider when your knowledge actually earns its keep. A board member interrupts your slide to ask why infrastructure spend is up 40%. Your CEO turns to you mid-negotiation and asks what the migration really costs. An engineer challenges an architecture decision in front of the team.

Your vault is not in the room. Your transcripts are not in the room. What’s in the room is your retrieval strength, the one thing none of your tools have been building, the thing Sparrow’s research says the capture habit has been quietly reassigning away.

We are the first generation of technology leaders who can outsource remembering entirely, at the precise moment our jobs still depend on the one thing that can’t be outsourced.

Try the blank page first

I’m not going to tell you to delete your vault or kick the bots out of your meetings. Mine are still there, and the elaboration practice I described in The Hidden Notebook is still how I write. What changed is what I ask the vault to be. It’s a cue library now, not a warehouse. In practice, that looks like this.

After my next important meeting, before I open the AI summary, I take a blank page and write down what I remember. The decisions, the tensions, the thing someone almost said. Then I open the transcript and compare. The gap between the two pages is not a failure. It’s a map of what I actually know versus what I merely attended. This is Henkel’s zoom lens, applied to a Tuesday.

Once a day, I take one thing a bot captured and rewrite it in my own words, connected to something I already believe or something I recently got wrong. One note. Five minutes. The meal, not the receipt.

And when I need to recall something, I try before I search. Thirty seconds of reaching for it. The Bjorks’ research suggests the reaching is precisely what builds the strength. Then I search, and the note confirms or corrects me.

I’ll be honest about what to expect. This feels slower. It feels worse. The capture habit feels like progress because it’s frictionless, and this feels like friction because it is. But you already know, from every system you’ve ever scaled, that the work you defer doesn’t disappear. It compounds. The remembering you’ve been deferring to your tools has been compounding too, and the interest comes due in the rooms where your judgment is the product.

Your brain is for having ideas. It turns out it was holding them all along. Nothing else ever was.

So, with the laptop closed, what do you actually know?

Sources: Bjork, R. A. & Bjork, E. L. (1992), “A New Theory of Disuse and an Old Theory of Stimulus Fluctuation”; Sparrow, B., Liu, J. & Wegner, D. M. (2011), “Google Effects on Memory: Cognitive Consequences of Having Information at Our Fingertips,” Science 333; Henkel, L. A. (2014), “Point-and-Shoot Memories,” Psychological Science 25; Kosmyna, N. et al. (2025), “Your Brain on ChatGPT: Accumulation of Cognitive Debt When Using an AI Assistant for Essay Writing Task,” MIT Media Lab preprint, arXiv:2506.08872; Bartlett, F. C. (1932), Remembering: A Study in Experimental and Social Psychology.

Then I notice the green line on the dashboard has gone flat.

Not climbing. Not dipping. Flat. The way a heart monitor goes flat.

A third-party model provider we depend on has changed something upstream, and our inference pipeline is timing out. New customers can’t onboard. Existing ones are staring at spinners. The Slack channel I muted last night has 200 unread messages, and the top one is from Dana: “Are we down?? Customers are emailing me directly. Jumping on a call in 10. Bring the engineers.”

I should have known better than to bring the engineers.

By the time I join, Dana has already pulled Sofia, my strongest backend engineer and the one person who can actually trace the broken dependency, into a live call to explain, in real time, to a non-technical founder, why the system she didn’t break is broken. Sofia is screen-sharing logs. Dana is asking why we didn’t catch this. My other two engineers are typing answers into chat instead of into the codebase.

I watch this for ninety seconds. I have coached hundreds of CTOs on staying calm in exactly this moment. And I open my mouth and I lose it.

“This call is the problem,” I say. Too sharp. “Every minute Sofia spends explaining the outage is a minute she’s not fixing it.”

Dana’s face does something I’ll think about for weeks. She doesn’t get angry. She slips sideways. Her eyes go somewhere else. She’s three weeks in, customers are in her inbox, her CTO just snapped at her in front of the team, and she has no idea whether this company is on fire or whether her CTO is.

One vowel-shaped gap

Later that day I try to repair it. I tell Dana that the two of us need to put real effort into our own relationship before anything else. That when she has a question about engineering, she should bring it to me and not go around me to the team. That a crisis will test us, and we should invest now, while we still can. She nods. The call ends.

An hour later she messages a board advisor that her new CTO thinks there’s going to be “necessary friction” between them.

Effort. Friction. One vowel-shaped gap between what I said and what she carried away.

I told myself we’d cleared it up. We hadn’t.

The text she didn’t send to me

The next morning, one of my newest developers pings me. He’s been with us one week. He forwards a text he just got from Dana, asking how things were going and whether the infrastructure was stable yet. A question that belonged to me, sent around me, to a new guy who’d been on the team for days if not hours.

The part I still can’t get over is this. He came to me before he answered her.

He didn’t have to. He barely knew me. He could have replied to the CEO and moved on. Instead he paused and told me what was happening. Whatever I’d done to bring him into the team, I had at least earned that.

It did not stop me from being livid.

That morning was the closest I came to walking away from the whole thing. The broken dependency. The oversold customers. The founder going around me the day after I asked her not to. I could feel the exit in my chest.

But I knew what walking out would cost me. Relief, and then nothing learned. The same lesson waiting for me at the next company, wearing a different face.

So I did the unglamorous thing. I coached the developers on how to respond, warmly and briefly, and to route the real questions back to me. Then I invited Dana to call me so we could walk through the day’s updates together.

When the conversation reached her text, I asked her plainly why she’d reached out to him. She told me. Her reasons were human and they were fair. She was scared, she wanted ground truth, and I hadn’t been giving her enough of it to feel the floor under her feet.

And then we had the best conversation we’d had since she joined. She asked me for a plan. She asked for visibility. She asked for a real read on customer health. We went deep into the platform struggles, the dependencies we don’t own, the part-time resources stretched too thin, the product sprinting to catch up with what sales had already sold. No translation games. No keeping score.

The outage was never the emergency

That call taught me what the snapped-at engineer and the effort-and-friction slip had been trying to teach me all week.

I was filtering. Out of some instinct to protect Dana, and probably to protect myself, I had been rationing what I sent her. A clean headline here, a reassuring line there. I thought I was sparing her the noise. What I was actually doing was leaving a vacuum, and a frightened founder will always fill a vacuum. If the information doesn’t come from you, it comes from your team, your board, or her own worst imagination.

She wasn’t going behind my back to betray me. She was starving, and I was the one holding the food.

Sofia fixed the dependency in four hours once we left her alone. The outage was the easy part. The emergency was that a determined new CEO and a veteran CTO were standing two feet apart and could not hear each other, in the exact week we most needed to.

I wrote about this in The CTO’s Silent Struggle. Being technically correct is cheap. I was technically correct on that first call. And being right bought me nothing, because I delivered it in a way that made the most anxious person in the company more anxious.

A crisis is a bandwidth problem. Your engineers have too little and your CEO has too much. Your job is not to fix the system. Your job is to manage the flow between those two, and to be the most generous source your CEO has, so she never needs to go find another one.

Why the flat line is coming for all of us

The AI products we are all rushing to ship sit on top of dependencies we do not control. Model providers, vector stores, orchestration layers, rate limits that change without warning. The surface area for a 6 a.m. flat line has never been larger. I argued in The CTO’s Incoming Storms that the storms are coming for how we communicate under pressure, not only for our architecture. This is that storm, arrived in my kitchen.

When the flat line shows up, three things happen at once, and they compound. A key dependency breaks. The people who can fix it get pulled into explaining it. And a CEO with no technical vocabulary fills the silence with the worst story she can imagine. Daniel Kahneman called it WYSIATI, what you see is all there is. Dana could see angry customers and a frozen dashboard. That was her entire universe. She wasn’t being irrational. She was being human with incomplete information, which is the only kind of human there is during an outage.

The instinct in that moment is to throw bodies at the fire. Pull in the contractor, get everyone on the call, loop in the world. Fred Brooks warned us about this back in 1975. Adding people to a late project makes it later, because every new person has to be brought up to speed, and that speed is paid for out of the time of the people who already have it. A crisis call with eight people on it is not a war room. It is eight people watching one person work, and that one person is now performing instead of fixing.

Who fixes, who talks

The teams that handle this well learned it from people whose outages can cost lives or millions. When Google wrote down how it runs incidents in its Site Reliability Engineering book, the first move was to split the work into roles. One person commands the incident. One person fixes it. And one person does nothing but communicate outward, so the fixer never has to. That communications role exists precisely so that no engineer is ever forced to choose between resolving the system and calming the executive.

I had collapsed all three roles into one chaotic call, and then gotten angry that it wasn’t working.

So let me give you the cadence I wish I’d had ready.

Decide who fixes, and protect them like the asset they are.

The moment you identify the person who can resolve the issue, they leave the call. They do not narrate. They do not reassure. They fix. You stand between them and everyone who wants an update, and you absorb every interruption so they never feel one.

Give your CEO a rhythm, not a lecture.

Dana did not need to understand inference timeouts. She needed to know a competent adult had her back and would tell her something true at a predictable interval. “I’ll send you one line every thirty minutes until this is resolved, even when the line is ‘still working, no change.’” The predictability is the medicine. A scheduled “no change” lowers anxiety more than an unscheduled explanation ever will. Remember the fifteen-minute blocks from The CTO’s Perfect Week? Same muscle. A small, reliable beat a frightened person can set their nervous system to.

Over-communicate, and open the door before she looks for a side one.

Under stress, message fidelity falls apart. People hear the scary version of whatever you say, so write the important things down and confirm them back. And invite your CEO in, all the way in, because the alternative is the back channel I earned the hard way. A crisis update needs three things to work. Detail. Frequency. Invitation.

Apologize fast and apologize specifically when you show up badly.

I had to go back to Dana and say the real thing. Not “sorry if that came across wrong.” That I was scared too, that I let it leak out as anger, and that she deserved a CTO who was steady on a morning she couldn’t be. The apology wasn’t weakness. It was the first deposit in the relationship I’d been too proud to invest in before I needed it.

Three names and one sentence

So what do you do with this today, before your dashboard goes flat?

You don’t need a giant incident-response process. You need three names and one sentence.

Write down who your fixer is for your most fragile system. Write down who communicates outward when it fails. They should not be the same person. If your team is small enough that they have to be, the rule gets simpler, not harder: the fixer fixes, you communicate, and you do not interrupt them for status more often than your own cadence allows.

Then write the one sentence your CEO can forward to a customer without you in the room. “We’ve identified an issue affecting onboarding, our team is on it, and we’ll update you by [time].” If your CEO holds that sentence, she stops texting your developers and starts protecting you.

What happens next surprised me. The fire does not go out any faster. Sofia’s four hours were going to be four hours no matter what I did. But the panic goes out almost immediately. And panic, not the outage, is what burns the trust between a CTO and a new CEO to the ground. Buy your fixers four quiet hours and you become the steadiest person in the company. Fill those four hours with a frantic all-hands and you become the problem.

You will also feel less alone, which is the part nobody warns you about. A crisis handled with a cadence stops being a thing happening to you and becomes a thing you are running. That move, from passenger to conductor, is most of the relief.

You are one person. You cannot make your model provider stable, or your CEO calm, or your dependencies bulletproof. What you can do is be the one steady beat in the room when everyone else’s tempo falls apart. Do it once and the team remembers. Do it twice and they keep the cadence without you. A new developer starts forwarding you the text he could have answered himself. That is how a single CTO turns a culture of panic into a culture that holds.

Your dashboard is going to go flat one of these mornings. The only question that matters is whether the people around you will hear a steady voice or a scared one.

Which one have you been practicing?

Etienne

p.s. reach out to me at my coaching company (EXE) if you want to set up some coaching around this subject.

That paper invented what we now call Markov chains. It was also the first time anyone had built a probabilistic model of human language and proved it by hand.

A large language model, 113 years later, is the same idea at industrial scale. Given everything that has come before, what is the probability of each possible next token? Markov did it with pencil, paper, and two categories. A modern model does it with billions of parameters and a vocabulary of tens of thousands. The shape of the question hasn’t changed. The shape of the answer hasn’t either.

I find that lineage clarifying because it cuts the mysticism. We talk about these models as if they arrived from nowhere. They didn’t. They are the industrial-scale descendant of a 113-year-old technique for predicting what comes next. The interesting question is not whether the prediction is magic. It’s how the prediction is actually made, and that turns out to be something a CTO can hold in their head if it’s shrunk down far enough.

So I shrank it. Five words, five numbers per word, every table small enough to fit on one page. I want to walk you through it the way I built it, because I think any CTO making vendor and roadmap bets on this technology benefits from being able to reconstruct the mechanism from memory. Not the math of a production model. The shape of it.

The core idea: an LLM turns words into numbers, lets every word mix in a little of every other word according to how related they are, repeats that dozens of times, and uses the result to predict the next token. Everything else is scale.

Why the fog costs us

We aren’t training models from scratch. We don’t need to derive backpropagation. So why does a working CTO benefit from the internals?

Because we are committing budget, architecture, and hiring to a technology our leadership teams find mystifying, and mystification is a tax. It shows up when product asks for something the model structurally cannot do and we can’t articulate why. It shows up when a CEO reads one breathless essay and wants the roadmap rebuilt around it. It shows up when a senior engineer offers fine-tuning as the answer to every question and the room has nothing sharper than instinct to push back with.

When we can explain the machine plainly, the wrong things stop impressing us. Our questions about cost and latency get sharper, because we understand where they come from. And we become the person in the C-Suite who can translate, which the past few years have made clear is most of the job.

Here’s the page.

Read more

It stung because it was true.

My team wasn’t slow. My processes weren’t broken. I was the throughput limit. Every decision waited on my calendar, and I had spent years mistaking that bottleneck for importance.

The hard part to admit is that I liked it. A production outage doesn’t need a strategy deck. The fix is obvious, the praise is immediate, and for a moment nobody questions your value. Crisis is the cheapest dopamine a technologist can buy. Meanwhile the work that would actually make my company stronger, the systems and the leaders that don’t need me, kept getting pushed to next week.

I have watched this pattern in nearly every CTO I coach through 7CTOs. We climb by being the person who can fix anything, and then the same instinct that got us here quietly turns us into the reason everything moves slowly. You feel needed. The company feels fragile. Both are true at once.

In code, when a system gets tangled and hard to maintain, we don’t quit and rewrite from zero. We refactor. We reorganize the internals so the thing runs cleaner, without changing what it does on the outside. The function stays the same. The structure gets healthier.

Your role as CTO is no different.

The job itself doesn’t change. You still align technology with the business, steward the budget, and build the machine that builds the product. What can change is how you engage with that function. What you hold onto. What you hand off. What you protect with your whole body, and what you finally let go of.

That is what Refactor is about. Not a productivity hack. Not a color-coded calendar. A way to redesign the role from the inside so it stops eating your evenings, your focus, and the part of you that fell in love with this work in the first place.

The book walks through three shifts I had to make myself, usually the hard way. Designing your role instead of inheriting it. Building leverage through people and systems instead of pouring more of your own hours into the fire. And reclaiming your time and attention as the scarce, finite assets they actually are.

I wrote it because too many brilliant technical leaders are privately unraveling while their dashboards stay green. I was one of them. The cost shows up in your health, your marriage, and the quiet question that keeps surfacing: is this really how I want to spend the next years of my life?

It doesn’t have to be.

If any of this feels familiar, the book is yours: get.ctorefactor.com

What part of your role did you design on purpose, and what part did you inherit by accident?

Priya is asking the questions a senior engineer asks when she’s inheriting a system she didn’t build. Not technical questions — those she’ll find in the code. The questions she needs the founders to answer.

What part of the system has been most fragile in the last six months. Which customers are you most worried about losing if we touch the wrong thing. If we’ve got two weeks before the new onboarding flow has to ship, what should we leave completely alone. Of these product specs, which are current and which were aspirational.

These are the questions only the founders can answer. No transcript says this is what matters. That judgment was supposed to live in their heads. It doesn’t. For two years it lived in their star developer’s head. Now he’s gone.

The founders cannot answer. So they reach for the only move available to them. They paste.

A Fathom transcript from a meeting with the old dev, six months ago. A product spec document, eleven pages. A thread of customer feedback. Another Fathom recording, this time of a sales call where architecture came up tangentially. Each one prefaced with some version of “this might help” or “summary from the call attached.”

I watch Priya read each one. I watch the gaps between her messages get longer. Her questions get more specific, then more careful, then quieter.

Then one of the founders pastes what he calls a summary. It’s a Fathom AI recap of a 90-minute conversation. It is two pages long. I unmute the part of myself that’s been observing this for three days and I type: you call that a summary?

The founder is genuinely confused by my pushback. He isn’t trying to hide anything. He isn’t pretending to understand the system. He’s doing the opposite. He’s openly admitting he doesn’t, and hoping that by sending the material through AI first, the smart people downstream will be able to figure it out.

That’s the move I want to name. It’s not deception. It’s a kind of naive hope: if I compress this with a model and forward it to someone smarter than me, comprehension will happen somewhere in the chain.

It won’t. And the founders, exhausted and frightened, are about to learn this the expensive way.

A cousin of technical debt

Technical debt is the shortcut you ship knowing someone will pay interest on it later. The interest comes due in maintenance, rework, on-call pages, the engineer who spends a day decoding a hack before they can change a line.

Comprehension debt works the same way. You forward an artifact you didn’t actually comprehend. A summary. A transcript. A translated spec. A meeting recap. A Linear ticket generated from a Loom.

The artifact looks complete. It’s grammatically clean. It moves through the system like a finished thing. But it isn’t finished. It’s deferred. The work of comprehending it has been pushed downstream onto whoever opens it next, on the hope that they’ll do what you couldn’t.

The founders weren’t being lazy. They were being generous, in a strange way. They were sending Priya everything they had and trusting her to be smart enough to extract signal from it. They didn’t realize that comprehension isn’t a property of the document. It’s a property of a human who has held the document long enough to integrate it. No amount of forwarding produces that.

Why we do this

The human brain is about 2% of your body weight and burns roughly 20% of your daily calories. Thinking is metabolically expensive. The brain is wired to take any cheaper path it can find. This isn’t a flaw. It’s the same logic that makes you sit down when you don’t have to.

AI is the cheapest cognitive shortcut a knowledge worker has ever been handed. Of course we take it. Especially when we’re scared. The founder forwarding the Fathom summary isn’t lazy. He’s a non-technical founder. His company has six months of runway. His entire technical knowledge just walked out the door. And someone handed him a tool that lets him appear to still have access to that knowledge by passing the residue of it through a model.

That’s the part most coverage of AI productivity misses. The dangerous use of AI summarization isn’t by careless people. It’s by frightened people, hoping the model will hold something they couldn’t.

I notice this in myself too. The urge to paste a long thread into Claude and ask “what’s the gist” instead of reading it. The urge to skim, nod, and forward. I’m not trying to deceive anyone. I’m trying to keep moving in a job that has more inbound information than the brain I’m running on can handle. The hope that compression equals comprehension is intoxicating, and it works just long enough to bury the cost.

What comprehension actually is

Comprehension isn’t recall. It isn’t the ability to paraphrase. A high schooler can paraphrase a paragraph they don’t understand. So can Claude.

Comprehension is the act of holding an idea long enough to test it against what you already know, until you could defend it, challenge it, or apply it without the source in front of you. Three things make it real.

Attention

Slowing down enough for the words to actually land. Most “I read it” is “my eyes passed over it.” Real attention is rare and you can feel the difference when someone has it.

Integration

Connecting the new idea to what you already believe, and noticing where it doesn’t fit. This is where the work is. This is the part that costs calories. Until an idea has been integrated, you don’t own it. You’re just storing it.

Stance

Forming a position you’d sign your name to. Agreement, disagreement, doubt, a position. “I think the auth layer is going to break under load by Q3.” Not “the auth layer has scaling considerations.” One is a stance. The other is a sentence that survived a summarization pass.

When the founder pasted the two-page Fathom recap, none of these were present. The information had moved through him without leaving a fingerprint.

The literal transfer

The founder spends two minutes. Skim the Fathom recap, paste it, send. He feels productive. He’s resolving inbound requests.

Priya spends an hour. She reads the two-page summary trying to find the answer to “what should we leave alone.” It isn’t there. The summary is a Fathom AI’s best guess at what mattered in a meeting it didn’t understand the stakes of. She asks a sharper follow-up. Gets another pasted artifact. Finally messages her own engineer to start poking at the code and infer priorities from where the most defensive comments and tests have been written. The judgment she needed from the founders, she’s now reverse-engineering from the codebase. Badly.

Two minutes saved on one side. An hour spent on the other. Plus the wrong priorities she’s about to set, which will surface as a missed deadline in three weeks because the team rebuilt something that didn’t need rebuilding while the actual fragile thing sat there waiting.

Multiply this across a team. Every Linear ticket whose description was AI-summarized from a customer call the PM didn’t watch. Every code review comment that was Claude’s rewording of a thought the reviewer didn’t actually have. Every executive update where someone pasted the engineering dashboard, asked for “key takeaways,” and forwarded those upward with “fyi.”

Most of what’s currently being called AI productivity is comprehension debt. The leader who shipped it has no idea the bill is accruing. The interest is being paid two steps downstream, by people who don’t yet have the vocabulary to push back.

Where AI summarization actually works

AI summarization is genuinely useful for data. Log analysis. Regression triage. Pulling the relevant section out of a 200-page compliance doc. Surfacing the three lines in a Slack thread that contain a decision. If the next step is “trigger an alert” or “look up a record,” summarize away.

It is dangerous for judgment and collaboration. Assigning work. Giving feedback. Aligning a team. Handing off a system. Telling someone what matters. Anything where another human has to act on what you sent, and where your point of view is the value being transmitted, not the information.

The distinction isn’t AI versus no AI. It’s whether the next reader needs the artifact or needs you. Priya didn’t need a summary of the system. She needed someone, anyone, to tell her what mattered and why. When she didn’t get that, she didn’t get nothing. She got something worse than nothing. Confident-sounding paragraphs that pointed in roughly the right direction and obscured the fact that no one upstream knew what they actually wanted.

The other direction

Now look the other way.

You aren’t only the sender of comprehension debt. You’re also the receiver. You sit downstream of the CEO’s Loom that got AI-summarized into a Linear epic. You sit downstream of product’s PRD that was generated from three customer interviews the PM didn’t watch in full. You sit downstream of the board deck whose engineering priorities slide was pasted in from ChatGPT at 11pm the night before the meeting.

The CEO isn’t trying to fool you. The PM isn’t trying to fool you. They’re doing what the founders in my story were doing. Hoping that if they compress the material with a model and pass it to the smart technical person downstream, comprehension will happen somewhere in the chain.

Then you and your team are expected to build against it. You’re the rung where the debt finally has to be paid, because code doesn’t run on summaries. It runs on someone, somewhere, having held the thing long enough for it to integrate.

The harder question isn’t “what am I forwarding that I don’t understand.” It’s what am I building from that nobody upstream understood, and am I going to keep paying that interest in silence?

Three questions before you hit send. And one before you hit accept.

Before forwarding anything you generated or summarized with AI, ask:

1. Can I say this without the doc in front of me?

2. What do I actually think about it? One line of stance. Agreement, disagreement, doubt. Something you’d sign your name to.

3. Who is paying the interest on this?

If the answer to one is no, you don’t send it yet, you read the thing. If the answer to two is “I don’t know,” you don’t send it yet, you form a position. If the answer to three is “someone downstream, and they don’t know it yet,” you stop.

And one for everything that lands in your inbox:

4. Did anyone upstream actually comprehend this, or am I about to be the rung where the debt comes due?

If the answer is the second one, you don’t build from it. You send it back up. Ask the CEO what they actually think. Ask the PM what the customer actually said. Refuse to be the place where uncomprehended work gets quietly converted into committed code.

The chain

The dev shop is still working with that startup. The founders are slowly learning. Priya is slowly figuring out the priorities the founders couldn’t articulate. The bill is being paid, mostly by her. The founders are starting to see that the bill exists.

I sat with that Slack thread for three days watching two smart, frightened founders forward material they had never comprehended to a team that needed them to actually know what they were handing over. They thought they were being helpful. They were hoping. The hope was generous. It was also a fantasy.

There are three rungs in the comprehension debt economy. The originators who never understood. The forwarders who didn’t read what they passed on. The receivers who build from what they were given. Most CTOs are at least two of those three on any given week.

Audit the last three things you forwarded today. Then audit the last three things you accepted without questioning.

The bill is being paid somewhere. The question is which rung you’re on.

I get to the line where I have to type the title.

I pause.

Then I write something else. Chief AI Officer. Head of AI. VP, AI Platform. I cycle through three or four. None of them are the obvious one.

The obvious one is CTO. And I cannot bring myself to type it.

I sit with that for longer than I’d like to admit. I founded 7CTOs. I’ve spent fifteen years of my career arguing that the CTO role is the one that decides whether a technology company lives or dies. And here I am, building a job spec for exactly that role, and the title I built my life around feels archaic. It feels tone-deaf. It feels like writing “Director of Telegraphy” on a 1950s org chart.

This isn’t because I think CTOs can’t do AI work. Most of the best CTOs I know are deep in it. Something else has happened. Something faster than I expected. Almost overnight, the title started carrying a weight it didn’t carry a year ago. A weight of yesterday.

I closed the laptop and didn’t write the email that day. I needed to understand what had shifted.

This piece is what I came back with.

The asymmetry that built the role

For a long time, the CTO was the only person in the C-Suite who could see into the substrate. Not because we had a crystal ball. Because we understood how things actually worked. We knew why latency mattered. We knew why the architecture decision in March would either save the company in November or sink it.

That asymmetric understanding made us valuable. The CEO needed us to translate possibility into plan. The CFO needed us to translate plan into cost. The board needed us to translate cost into risk.

The LLM has taken that conduit and given it to everyone in the room.

Your CEO can now ask Claude what an event-driven architecture is. Your head of sales can ask GPT-5 to explain vector databases. Your CFO can prompt her way to a competent-sounding question about model evaluation. None of them will be experts. They no longer need you to do the basic translation.

This should not be a crisis. It is a crisis only because too many CTOs have responded to it by becoming consumers of the same tool that flattened their advantage.

The parallel that actually fits

I keep thinking about a split that ran through our own field in the seventies and eighties. The split between programmers who understood the machine and programmers who only understood the language.

Both groups wrote code. Both groups shipped product. Both groups used the high-level languages, the compilers, the abstractions everyone else used. None of them refused the new tools. But the ones who knew how memory worked, what the registers were doing, why a cache miss cost what it did, why the kernel scheduled the way it scheduled, those engineers had an asymmetric advantage that compounded for the rest of their careers. They could see why systems failed. They could see where the abstraction would leak. They could design things the application-layer programmers couldn’t even describe.

The same split is forming right now around AI. Most CTOs are choosing the application layer. Some of us are going to choose the substrate. The people who go deeper will run things. The people who only consume the abstraction will be managed by them.

I want us to be the second group.

The data on which way most of us are walking

A 2025 study by Microsoft Research and Carnegie Mellon, presented at the CHI conference, surveyed 319 knowledge workers across 936 real AI-assisted tasks.

The people who trusted the AI thought less. The people who trusted themselves thought more. The researchers were direct about why: knowledge workers refrain from critical thinking when they lack the skills to inspect, improve, and guide AI-generated responses.

The people who don’t understand the tool can’t think alongside it. They can only consume it.

Two ways we’re going extinct

I see two patterns in our profession and both lead to the same place. I’ve watched both happen to colleagues I respect. I’ve caught myself drifting toward the first one more times than I’d like to admit.

1. Token Monkey

The first is the Token Monkey. The CTO who has reduced the job to procurement. The week is spent negotiating with Anthropic and OpenAI. We live inside spend dashboards. We run pilots that produce slides. We’ve become AI buyers with a fancy title. When the CEO asks what’s next, we answer with vendor names.

2. Vibe Coding

The second is more dangerous because it looks like work. The CTO who is vibe coding their way through the week, throwing prompts at Cursor, watching agents produce repos, confusing the appearance of building with actual building. We’re shipping artifacts we couldn’t defend in a code review. We’re accumulating output we don’t fully understand. We feel productive. We’re not.

Neither version is going to be replaced by AI. We’re going to be replaced by the next person who walks into the room and demonstrates that they can still think.

The advice we all swallowed

For two decades the industry has told CTOs the same story. Get out of the code. Step away from the implementation. Your job is to build the team, set the vision, optimize the workflow, manage the stakeholders. The technical work is what your engineers are for. The strategic work is what you are for.

I’ve preached versions of this myself. The CTO’s Perfect Week is partly built on it. “Your contribution to the company no longer lies in the code you’re producing” was the whole framing of that piece. I still think it was true for the world I wrote it in.

It is not enough for the world we are in now.

The orthodoxy worked when the technical landscape underneath you was relatively stable. You could afford to ascend, because the substrate didn’t shift faster than you could oversee it. You could trust your engineers to keep up with the substrate while you kept up with the business. The split between technical depth and executive altitude was a clean trade.

That trade is broken. The substrate is now moving faster than any team you build can follow on your behalf. Your principal engineers are using tools that are six months ahead of where they were when you hired them. Your platform team is making model choices that change unit economics. Your product team is shipping AI features whose failure modes nobody on your staff can fully explain to you, because you trained yourself out of being the person who could ask the hard questions.

The CTO who has spent the last five years optimizing the org chart and running quarterly OKRs is not at the top of their game right now. They are exposed. The role they were trained into is the role most at risk.

What I’m asking for is not regression. I’m not asking you to write JIRA tickets again.

I’m asking you to become a technical intellectual at a depth you may not have allowed yourself in fifteen years.

• To read the papers your engineers are reading and read them more carefully.

• To understand the math behind the model choice.

• To argue the architecture at a level your CEO cannot follow you to and isn’t supposed to.

That’s not a step backward. That’s a different kind of seniority. It’s the kind we let go of, and it’s the kind that’s coming back into demand whether or not the industry has admitted it yet.

The CTOs who survive this aren’t the best team-builders. They’re the best technical thinkers who can also build teams. The order of those two things has reversed.

What the ones leveling up are actually doing

I get to watch a lot of CTOs up close. Some of them are pulling ahead right now.

Six habits show up in almost every one of them.

1. They are reading complete white papers, not just the summaries.

2. They can name the architectural choices behind the models they use, and defend them.

3. They are studying the cognitive science underneath, not just the technology.

4. They write to think, not to publish.

5. They are in regular, hard conversation with other CTOs about all of it.

6. When they don’t know something, they sit in the not-knowing instead of reaching for the model.

None of these six are technically hard. All of them have been trained out of us. The rest of this piece is what I’ve learned about each one.

Confidence comes from the taxonomy, not the demo

When you actually understand the taxonomy of AI, something shifts in how you walk into a meeting. You stop using the words wrong. You stop saying “the AI” like it’s a single thing. You know the difference between a foundation model, a fine-tune, a retrieval system, an agent, and an orchestration layer. You know what a context window is, what an embedding is, what a token actually represents. You know what evaluation means in this domain and why eval design is harder than the model design.

That knowledge changes your executive presence in a way nothing else can right now. Your CEO walks out of the meeting saying “my CTO actually knows what they’re talking about.” Your CFO stops asking the AI for second opinions on your recommendations. The board starts inviting you into conversations you weren’t in before.

The confidence is real because it’s earned. It’s not the hollow confidence the Microsoft study warned about, where leaning on the AI made people think less and feel more sure. It’s the opposite. It’s the confidence that comes from sitting with the hard thing until you understand it.

What I want you to learn (and one example of why)

Read the papers. Not the summaries. The papers themselves. When Anthropic publishes circuit-tracing work, when DeepMind drops a technical report, when a Stanford team publishes inference economics, those are maps of the terrain. The CTO who reads the actual map will be looking at a different country than the one reading the AI-generated travel brochure.

Then learn how the brain works. Is it now more important than ever for a CTO to understand how the brain actually works? Yes. Every paper you read on transformer attention is also, properly digested, a paper about human attention. Every paper on memory retrieval will tell you something about your own. Every paper on reinforcement learning will tell you something about how habits form in your team.

When you understand attention heads in transformers, that mechanism where the model learns to weight which tokens to attend to in a context, you suddenly have a framework for what’s happening when one of your engineers is overwhelmed in a sprint. They’re context-saturated. They have no attention budget. The technical concept and the human concept aren’t analogies. They’re the same problem at different levels of abstraction. The CTO who carries that frame leads differently. They redesign the sprint. They change the meeting cadence. They protect attention as a resource because they now understand attention as a resource.

That is what foundational knowledge does. It grows flowers in domains you didn’t expect.

The two other skills

There are two more things I want us to invest in.

Writing

The first is writing. Not LinkedIn posts. Real writing. The kind where you sit down with a question you don’t know the answer to and write your way toward an answer that’s actually yours. I’ve written about this before in The CTO’s Hidden Notebook. Writing is the only practice I’ve found that exposes whether you actually understand something or you’re just pattern-matching on words you’ve heard. AI cannot do this for you. The moment you let AI write your thinking, you stop having thinking to write.

Discussing

The second is talking to other CTOs about hard things. This is why we run the 7CTOs peer groups every month. We pick a paper or a deep idea, and a small group of CTOs sit around it and argue about it for ninety minutes. No slides. No vendor pitches. Brains in real time, working something out together. White papers don’t fully come alive on the page. They come alive in discussion, when somebody else’s interpretation collides with yours and forces you to defend or refine what you actually believe.

If you don’t have a peer group like this, build one. If you want into ours, message me. The hardest thinking I do every month happens in those rooms.

The frontier is the work

The CTOs who come through this well will not be the ones who managed AI spend the best. They will not be the ones who deployed agents fastest. They will be the ones who, when everyone else in the room had outsourced their thinking, were still doing the work.

That’s a small group right now. Smaller than it should be. I’d rather it be a much bigger one, and I’d rather we get there together.

So read the papers. Learn the taxonomy until you can defend the architectural choices yourself. Learn how the brain actually works. Write your way to your own positions. Talk to other CTOs who refuse to be consumers. Stop asking the model what you think.

I still haven’t sent that recruiter email. When I do, I think I’m going to write CTO in the title field. Not because the role is the same as it was last year. Because I want the title to mean something again.

That’s on us.

“They want to cut us to one engineer per product team,” he says. “One. The CEO read something on LinkedIn about AI agents and now he’s convinced we can ship the same roadmap with a third of the team.”

I ask him what he said in the meeting.

“I told him the math doesn’t work. I walked him through the velocity numbers, the on-call rotation, the knowledge concentration risk.” He finally takes a sip, grimaces. The coffee is cold. “He nodded. Then he asked me to put together a transition plan by end of quarter.”

This CTO is brilliant. He has fifteen years of scar tissue, a calm demeanor, and a genuine love for his team. And he is about to lose this fight. Not because he’s wrong. He’s right. He’s going to lose because he showed up to a strategy conversation with a defense brief.

I’ve had four conversations like this in the last three weeks. Different cities, different stages, different product categories. Same shape. The CTO knows something is coming at them, the conversation has already started, and they don’t have a stance ready. They have facts. They have logic. They have decades of experience. What they don’t have is a position they can hold under pressure when the room turns.

So let’s fix that.

The conversations already on your calendar

Here’s something true about the storms heading toward technology leaders right now: they don’t announce themselves. They show up disguised as casual questions in 1:1s, throwaway comments in board meetings, Slack messages from a CFO who “just had a quick thought.”

By the time the conversation feels like a confrontation, it’s already three weeks deep. The CEO has talked to two board members. The CFO has run the model. The COO has chatted with a peer at another company who “did the same thing and it worked great.”

You walk in thinking you’re having a discussion. They walk in having already made the decision and looking for your buy-in.

You need to know what’s actually being asked, and you need a position before you walk into the room. Let me name the six conversations I’m watching land on CTOs right now, and the stance I’d want you holding in each one.

1. “Why can’t we cut headcount now that we have AI?”

This is the conversation. Every CEO on the planet is having some version of it, even the ones who haven’t said anything to you yet. Revenue per employee is climbing across software companies, boards are pattern-matching hard, and the productivity stories about AI coding tools are everywhere.

The trap is to argue against the cut. You’ll lose. The numbers your CEO is reading are real, the productivity gains in narrow contexts are real, and your defensive posture will read as self-interested protection of your empire.

The stance to hold: AI doesn’t reduce the need for engineers, it changes what engineers are for. Your team used to produce code. Now they produce judgment about code. The bottleneck has moved from typing speed to the ability to evaluate, integrate, take responsibility for, and operate systems built faster than any human can fully review.

If you cut the team, you don’t get the same roadmap with fewer people. You get a codebase that nobody understands at depth, security posture that decays in months because nobody has time to think about it, and a production environment where every incident takes three times longer to resolve because the people who would have built the system never built it.

Don’t say “we can’t cut.” Say “here’s what we’re optimizing for now, and here’s what that team looks like to deliver it.” Bring the new shape, not the defense of the old one. If the answer involves a smaller, more senior team with different skill profiles, say that. If it involves the same headcount with a radically different mix, say that. What you can’t do is fight the premise. The premise has already won.

2. “Can we just have one developer on each product team?”

This is the same conversation in a different costume. It’s the org-design version of the headcount conversation, and it’s seductive because it sounds like alignment. One engineer, one PM, one designer, ship faster, fewer dependencies, clear ownership. It reads beautifully on a slide.

What it actually creates is the bus factor problem at industrial scale. Every product surface depends on a single person who cannot get sick, take vacation, or quit without breaking something. Every architectural decision gets made in isolation. Every cross-cutting concern — auth, observability, data contracts, security review, deployment infrastructure — becomes nobody’s job.

Six months in you have twelve product surfaces, twelve different ways of doing the same thing, twelve people who’ve each painted themselves into a corner, and a platform team that doesn’t exist because you couldn’t justify the headcount when you were “moving fast.”

Your stance: pods of one are not teams, they are single points of failure dressed up in a process diagram. Engineering work is collaborative because the work itself is collaborative. The code one person writes today will be read by four people next quarter and modified by twelve people next year. The decisions one person makes about how to structure data will constrain every team that touches that data for years.

Counter-propose. If they want surface area and ownership, give them small persistent teams of three to five with clear product alignment and shared platform infrastructure underneath. That’s the structure that scales. That’s the structure that survives someone quitting. That’s the structure that lets you actually move fast in year two, not just year one.

3. “The board wants to know our AI strategy”

Translation: someone on the board read an article, talked to a portfolio company CEO, and now you have a homework assignment due Friday.

The wrong move is to produce a deck full of tools you’re “evaluating.” Every CTO is evaluating Cursor, Claude Code, Aider, a handful of MCP servers, and whatever launched on Product Hunt last Tuesday. That’s not strategy, that’s shopping. Boards smell shopping immediately.

The stance: your AI strategy is your engineering strategy. They’re not separate documents anymore. It’s how your team writes code, reviews code, handles incidents, makes architectural decisions, and develops junior engineers in a world where the easy work is done by machines. It includes what you’re building with AI for customers, but the harder and more important half is how AI changes the way your team operates internally — and what that means for hiring, leveling, performance, and risk.

Bring three things to the board.

1. Where AI is creating leverage in your engineering org today, with numbers you trust. Not vendor numbers. Your numbers.

2. Where you’re investing for the next two quarters and what you expect to learn.

3. What you’re explicitly not doing and why. The “not doing” list is what separates strategy from a wish list. Boards have seen enough wish lists. They want to see judgment.

If you can’t fill in that third bucket, you don’t have a strategy yet. You have a backlog.

4. “We need to move faster”

You will hear this every quarter for the rest of your career. It’s the background radiation of being a CTO. But right now it has a new edge to it, because everyone in the building believes AI should have already made you faster. The question is no longer “can we go faster” — it’s “why aren’t we faster yet.”

The bad response is to promise more velocity. The worse response is to explain why velocity is hard. Both lose you credibility.

Your stance: speed is a function of what you’re willing to stop doing. The team’s capacity hasn’t suddenly tripled because an LLM can write a function. The team’s capacity to ship features is gated by code review, testing, deployment safety, on-call burden, security review, customer support escalations, and the cognitive load of maintaining everything you’ve already shipped. AI helps with one slice of that pipeline. The rest is unchanged or, in some cases, worse — because faster code generation means more code to review, integrate, and operate.

If you want speed, we make trade-offs. Here are three things we could stop investing in to free up capacity for the new priority. Here’s what we’d accept in terms of risk or quality. Here’s what would break.

Make the trade-off visible. Make the CEO choose. The conversation shifts from “the CTO is slow” to “the executive team made a prioritization decision together.” That’s where it should have been all along. That’s also where you stop being the person who says no and start being the person who frames the choice.

5. “Are we sure all this AI-generated code is safe?”

This one usually comes from the CFO or General Counsel, and it usually arrives about a quarter after your team has gone all-in on AI coding tools. Sometimes it arrives the morning after a security incident at a peer company makes the news.

The honest answer is: probably not entirely, and neither is anyone else’s. Recent research on AI-generated code has found meaningful rates of vulnerable patterns, license contamination, and subtle logic errors that pass code review because they look right. The code is plausible. Plausible is the enemy of secure.

The stance: AI-generated code needs the same scrutiny as code from a brand new engineer on day one — which means it needs more scrutiny, not less, even though it arrives faster. Our review practices, our test coverage requirements, our security scanning, our dependency analysis — none of that gets relaxed because the author is a model. If anything, it gets tightened, because the volume of code is going up.

Then bring the actual plan. What scanning tools you’re running. What review standards you’ve updated. What you’re tracking. What you’re going to know in 90 days that you don’t know today. The CFO doesn’t need you to promise zero risk. They need to see that someone is actually thinking about this with rigor, not just enthusiasm.

If you don’t have that plan, build it this month. This conversation is coming whether you’re ready or not, and “we trust our engineers” is not an answer that survives a board-level question about AI risk.

6. “I don’t think anyone is listening to me”

This isn’t a conversation with the C-suite. This is the conversation you’re having with yourself at 11pm on a Tuesday, and it’s the most dangerous one on this list.

I wrote a while back about how being technically correct isn’t enough. That hasn’t changed. What’s changed is the stakes. When the rest of the C-suite is making decisions about AI, headcount, and organizational structure based on incomplete mental models, your inability to make them feel what you see isn’t a communication problem anymore. It’s a survival problem. For you and for the company.

There’s a particular flavor of isolation that hits CTOs right now. Your CEO is reading the same five Substacks as every other CEO. Your CFO is running models built on industry benchmarks that are six months out of date by the time they’re published. Your peers in the C-suite are pattern-matching against what they’re hearing at their own peer dinners. And you, the only person in the room who actually understands what the technology can and can’t do, are increasingly being treated as the resistant one. The cautious one. The one who doesn’t get it.

You start to wonder if you don’t get it.

The stance to hold with yourself: if they’re not hearing you, that’s data about how you’re showing up, not data about their intelligence. The work is to translate. Not dumb it down — translate. Find the version of your concern that lives in their language. Revenue, risk, retention, runway, customer trust, regulatory exposure. Pick the frame they already think in and put your concern inside it.

And get out of the building. Talk to other CTOs. Not to vent — to calibrate. The version of reality you’re living in inside your company is one data point. You need others. You need to know whether your CEO’s expectations are reasonable, aggressive, or unhinged compared to what’s actually happening at companies of your size and stage. Without that calibration, you’ll either capitulate when you should hold, or hold when you should adapt. Both are fatal.

The CTOs I see weathering this period well all have the same thing in common: they have somewhere to take the hard questions before they have to answer them in front of their CEO. A coach, a peer group, a mentor, a community. Somewhere they can be uncertain out loud and come back with a stance.

If you don’t have that, build it this month. It’s not a luxury anymore.

What to do this week

Pull out your calendar. Find the next executive meeting on it. Before you walk in, write down two things on a notecard.

The first is the strongest argument against your current position. Not a strawman — the real one, the one your smartest skeptic would make. If you can’t articulate it cleanly, you’re not ready to defend your position. You’re ready to be surprised by it.

The second is the trade-off you’re asking the team to make. Not a recommendation, a trade-off. “If we do A, we don’t get B. Here’s why I think A is right anyway.” This forces you out of advocacy mode and into the executive frame, where everything is a choice between imperfect options and the job is to make the choice cleanly.

Then in your next 1:1 with your CEO, ask one question: “What’s the conversation about engineering you’re having that I’m not part of?” Sit with the silence. Let them answer. The answers will tell you which storm is closest, and how much warning you actually have.

You’re not going to stop the storms. They’re coming. Boards are going to ask hard questions about AI. CFOs are going to push on headcount and security. CEOs are going to want more velocity with fewer people. Product is going to want autonomous pods. That’s the job now.

What you can control is whether you walk into those rooms with a stance or with a defense. The CTOs I see thriving right now aren’t the ones with the best technology opinions or the deepest technical chops. They’re the ones who’ve already done the work to know where they stand before the conversation starts. They’ve stress-tested their position with peers. They’ve translated it into the language of the room. They’ve identified the trade-offs they’re willing to make and the ones they aren’t.

Get your stance ready. The meeting is already on your calendar.

Hey my new book CTO Refactor is coming out in May 2026 - head over to ctorefactor.com to get advance copies and some bonus treats. - Etienne

I pull up the codebase. There are three utility functions doing nearly the same date formatting. The error handling pattern doesn’t match anything else in the repo. A new data access layer has been introduced that duplicates logic we already have in our services directory. And Marcus has no idea, because he didn’t write this code. He directed it.

I ask him why the date formatter doesn’t use our existing utility. He scrolls through the file tree. “We have one?” He genuinely doesn’t know. This is an engineer who has been with us for two years.

I close my laptop and walk back to my desk. The dashboard works. It passed review. It will ship. And it will quietly make our system a little harder to understand, a little more fragile, a little less coherent. Not today. Not next week. But the weight is accumulating. I can feel it in the pull requests, in the onboarding conversations, in the growing silence when I ask why something was built this way.

That silence is entropy. And fighting it just became the most important part of my job.

The Universe Wants Your Codebase to Fall Apart

In 1850, Rudolf Clausius articulated what would become the second law of thermodynamics: in any natural process, the total entropy of an isolated system can only increase. Things move from order to disorder unless you put energy into keeping them organized.

Meir Lehman applied this thinking to software in 1974. His second law of software evolution states that the complexity of a software system increases unless work is done to maintain or reduce it. For fifty years, this has been the quiet backdrop to every engineering organization. Codebases rot. Standards drift. Architecture erodes. Entropy wins unless you fight it.

We have always fought it. Code reviews. Refactoring sprints. Architectural standards. Style guides. These are the maintenance rituals that keep disorder at bay. The energy we pour into keeping our systems coherent.

AI just changed the equation. Dramatically.

A recent large-scale study of over 300,000 AI-authored commits across 6,275 GitHub repositories found that AI-introduced technical debt is growing rapidly, climbing from a few hundred surviving issues in early 2025 to over 110,000 by February 2026. About 24% of those issues still persist in current codebases. GitClear’s analysis of over 211 million lines of changed code found copy-pasted code up 48% and refactored code declining 60%. Code churn, the percentage of lines rewritten within two weeks, has doubled in teams heavily using AI tools.

The disorder isn’t slowing down. It’s accelerating. And if you’re a CTO leading 40 to 120 engineers right now, entropy is your fight. Not AI strategy decks. Not model selection. Not prompt engineering workshops. Entropy.

Why AI is the Greatest Complexity Generator We’ve Ever Built

When code was slow and expensive to produce, friction was your friend. Every function a developer wrote required them to understand the system they were modifying. They had to read existing code. They had to navigate the architecture. They had to make choices that fit. The very slowness of writing code was a form of quality control.

AI removed the friction. A junior engineer with Cursor can now produce 500 lines of code that passes lint, follows naming conventions, and looks clean on review. But verifying whether that code fits the system, whether it respects architectural boundaries, whether it introduces hidden coupling, requires the senior reviewer to mentally reconstruct the entire logic flow. And they don’t. It takes too much energy. When the code looks right, the brain skims. The PR gets approved. The debt gets merged.

Stack Overflow’s 2026 developer survey found that 76% of developers using AI tools reported generating code they didn’t fully understand at least some of the time. Think about that. Three out of four engineers are shipping code into your production systems that they cannot fully explain.

Forrester predicts 75% of technology decision-makers will face moderate to severe technical debt by the end of this year. DORA’s research confirms the pattern: AI adoption links to higher throughput but lower delivery stability. More changes ship faster. Each change is slightly more likely to break something.

Ox Security published a report calling AI-generated code “highly functional but systematically lacking in architectural judgment.” That phrase is worth pausing on. The code works. It passes tests. But it doesn’t know your system. It doesn’t carry the context of why your team chose to handle errors that way, or why the data access layer was separated from the business logic, or why you migrated off that specific library three months ago.

AI treats every prompt as a greenfield project. Your codebase is anything but.

Your Engineers Aren’t Getting Worse. The Problem Is Getting Bigger.

I wrote about this in my recent article on The CTO’s New Engineering Ladder. Output used to be a reasonable proxy for engineering talent. It no longer is. When everyone can ship, what separates your Architects from your Apprentices is judgment. The ability to see downstream consequences. The instinct for what will break. The capacity to reason about a system under pressure.

But judgment depends on understanding the system you’re working within. And the system is getting harder to understand every day that AI-generated code ships without deep review.

This is the entropy spiral. AI produces code faster than your team can comprehend it. Comprehension gaps lead to architectural drift. Drift makes the codebase harder to reason about. And a harder-to-reason-about codebase makes AI-generated code even more dangerous, because the AI doesn’t know what it doesn’t know, and neither does the engineer directing it.

CircleCI’s 2026 State of Software Delivery report, drawn from over 28 million workflows, found that AI-assisted development drove a 59% increase in throughput. But most engineering organizations are leaving the majority of those gains on the table, not because AI isn’t working, but because their validation, review, and delivery systems haven’t caught up.

More code. Fewer releases. That’s the entropy signature.

The CTO as Entropy Fighter

The narrative circulating in boardrooms right now is that CTOs are becoming obsolete. Jack Dorsey announced Block would cut nearly half its workforce, telling shareholders that “100 people + AI = 1,000 people.” The stock jumped 24%. Atlassian split its CTO role in two, explicitly scoped to the AI era. Gartner predicts 40% of enterprise applications will feature task-specific AI agents by end of 2026.

If you listen to this noise, you might think the CTO’s job is shrinking. I think the opposite is true.

When code was expensive, the CTO’s primary job was to make sure enough code got written. When code becomes cheap, the CTO’s primary job is to make sure the system stays coherent. That’s a harder job. The universe is literally working against you.

The old CTO managed output. The entropy-fighting CTO manages order. Order across a codebase that’s being written by humans, AI agents, and hybrid workflows simultaneously. Order across teams that are shipping faster than the architecture can absorb. Order across an organization where product managers, data analysts, and operations leads are all generating code that ends up in production systems.

This is not an abstraction. I coach CTOs who are living this right now. The ones who are thriving have stopped thinking of themselves as accelerators and started thinking of themselves as governors. Not in the bureaucratic sense. In the mechanical sense. The device that prevents an engine from tearing itself apart at high speed.

Three Forces That Create Entropy in AI-Driven Development

Comprehension debt

Addy Osmani coined this term in early 2026, and it captures something that traditional technical debt doesn’t. Comprehension debt accumulates when your team ships code they didn’t write and don’t deeply understand. Every AI-generated feature that gets merged without someone building a genuine mental model of how it works adds to this debt. And unlike traditional debt, you don’t know you’re taking it on.

Architectural amnesia

AI doesn’t remember your design decisions. It doesn’t know why you chose event-driven architecture for that service, or why the auth layer is isolated, or why you deliberately avoided that ORM. Every prompt is a fresh start. Over time, the architectural intent that held your system together gets diluted by thousands of small, individually reasonable decisions that don’t add up to a coherent whole.

Review collapse

When a junior dev submitted 50 lines of code in 2023, a senior could review it meaningfully in ten minutes. When an AI-augmented engineer submits 500 lines that all look syntactically correct, the cognitive cost of genuine review goes through the roof. The natural human response is to skim. Approve. Merge the debt. One API security company found a 10x increase in security findings per month across Fortune 50 companies between December 2024 and June 2025.

These three forces compound each other. Comprehension debt weakens review quality. Weak reviews accelerate architectural drift. Drift makes comprehension harder. The spiral tightens.

Building the Anti-Entropy Machine

If you run an engineering organization of 40 engineers or more, you need what I call an entropy budget. A deliberate, protected allocation of engineering time dedicated not to building new things but to keeping existing things coherent.

1. Make AI your refactoring engine, not just your feature engine

The same tools that generate code at speed can find dead code, consolidate duplicates, generate documentation, and identify architectural drift. Most teams use AI exclusively for production. Flip the ratio. For every four AI-assisted features your team ships, dedicate one cycle to AI-assisted cleanup. Use AI to reduce entropy, not just increase it.

2. Treat AI output like a first draft from a talented stranger

Because that’s what it is. A stranger who doesn’t know your system, your team’s conventions, or your architectural intent. The code might be excellent in isolation. Your job is to make sure it fits the whole.

3. Rebuild your code review around judgment, not syntax

If your reviews are catching formatting issues and variable names, you’re wasting your most expensive engineers on work the linter should handle. Reviews should answer one question: does this change make the system easier or harder to reason about in six months?

4. Instrument your entropy

Track code churn (lines rewritten within two weeks of being written), module coupling over time, and the ratio of new code to refactored code. If new code is climbing and refactored code is declining, your entropy is accelerating. You can see this in GitClear’s data at the industry level. You need to see it at the team level.

5. Protect the learning pipeline.

AWS CEO Matt Garman said it plainly when he heard proposals to replace junior engineers with AI: “That’s like, one of the dumbest things I’ve ever heard.” A Stanford Digital Economy study found employment for software developers aged 22 to 25 has declined nearly 20% from its 2022 peak. If you stop hiring people who are learning to think about systems, you won’t have people who know how to think about systems in five years. Entropy will have won by default.

Your Agentic Future Depends On This

The next chapter of AI development is agentic. Multi-agent systems that plan, execute, and iterate without waiting for a human prompt. Gartner reported a 1,445% surge in multi-agent system inquiries from Q1 2024 to Q2 2025. GitHub’s Agent HQ, announced in February 2026, lets developers run multiple AI agents simultaneously on the same task.

An agentic future running on a high-entropy codebase is a disaster. Agents that can autonomously modify code, run tests, and ship changes will amplify whatever state your system is in. Strong foundations get amplified into faster, more reliable delivery. Weak foundations get amplified into faster, more creative destruction.

The CTO who has spent the last year fighting entropy, keeping architectural boundaries clean, maintaining comprehensible systems, building review processes that catch drift, will have a codebase that agents can navigate and improve. The CTO who chased velocity above all else will have a codebase that agents can barely understand, let alone safely modify.

Your readiness for agentic AI is directly proportional to how well you’ve managed entropy today.

Three Things to Do This Week

Write down the architectural decisions that live only in your head or in the heads of your senior engineers. If your AI tools don’t know why the system is built this way, they can’t maintain it. If your new engineers don’t know, they can’t review the AI’s work. Architectural intent must be documented, not folklored.

Pull your team’s code churn numbers for the last quarter. How much of what was written last month was rewritten this month? If the number is climbing, your entropy is accelerating and no amount of velocity will outrun it.

Pick one senior engineer and give them an explicit mandate: spend 20% of their time next sprint making the codebase more coherent. Not shipping features. Not closing tickets. Reducing entropy. See what happens when someone’s job is to fight disorder instead of produce output.

The CTO isn’t dead. The CTO’s job just got a lot more physical. You’re fighting thermodynamics now. And the engineers who will build your team’s future are watching to see if you care more about speed or coherence.

I know which one keeps companies alive.

Etienne

Etienne de Bruin is the founder of 7CTOs and coaches technology leaders through the complexity of scaling engineering organizations.

Research backing: The article draws on the March 2026 arXiv study of 304K AI-authored commits, GitClear’s 211M lines analysis, CircleCI’s 2026 report (28M workflows), Stack Overflow’s 2026 survey, DORA findings, Ox Security’s “Army of Juniors” report, the Stanford Digital Economy study on junior dev employment, and Gartner’s multi-agent inquiry data. I also wove in Lehman’s Laws (1974) and Clausius for the entropy framing.

She looks at me for a long moment. Then: “I honestly don’t know anymore.”

Half her team is using Claude Code and GitHub Copilot to generate entire features in an afternoon. A junior who joined six months ago shipped three production-ready services last week. Another who’s been around for years is still barely functional without hand-holding. She can’t tell who’s performing and who isn’t because the outputs (features shipping and the pull requests closing) look about the same now. Maybe better for the newer people.

“So what do I measure?” she asks me.

That question has been sitting in my chest ever since.

When the Whole Company Writes Code

It’s not just Priya’s engineers using AI to generate code. It’s her product manager, who scaffolded a working prototype last week to win an argument with the CEO. The data analyst who built an internal tool without filing a single ticket. The operations lead who automated her own reporting pipeline in an afternoon.

Before the seasoned engineers in my audience roll their eyes. I know. A product manager’s prototype is not production software. The gap between a scaffolded feature and a maintainable, secure, observable system is exactly where engineering expertise still lives. The vibe-coded landing page doesn’t survive its first security audit.

But that’s the point. The things that make an engineer irreplaceable are not the things most performance ladders measure. They measure the stuff AI is getting good at. The irreplaceable stuff: judgment about what to build, instinct for what will break, the ability to reason about a system under pressure at 2am. This gets no column in the spreadsheet. No framework for rewarding it, retaining it, or developing it.

When your marketing team can ship a prototype and your engineering team can’t articulate what they do that the prototype can’t, you have a positioning problem inside your own organization. That’s the problem worth solving.

The World According to Dorsey

Jack Dorsey announced recently that Block would cut 4,000 employees, nearly half its workforce, in a move explicitly tied to AI reshaping labor productivity. In a letter to shareholders, Dorsey wrote that “intelligence tools have changed what it means to build and run a company” and that a significantly smaller team using AI can do more and do it better.

Block’s stock surged 24%.

Wharton professor Ethan Mollick pushed back, noting it’s “hard to imagine a firm-wide sudden 50%+ efficiency gain” given how new these tools are. He’s right to be skeptical. Dorsey admitted the company over-hired during COVID and built two separate organizational structures that had to be unwound. Block’s story is complicated.

The board reaction is not. A 24% stock pop gets read across every C-Suite in the industry. Your CEO saw it. Your board saw it. They are now wondering whether your team size can be justified by a formula that is no longer theoretical.

You need to be the one who reframes that conversation with a better framework than Dorsey’s, one that captures what your engineers actually do that AI cannot.

What We’ve Actually Been Rewarding

We have been rewarding output. We need to start rewarding judgment.

When code was slow and expensive, output was a reasonable proxy for judgment. The friction of development naturally filtered for people who understood what they were building. AI has removed most of that friction. Velocity, story points, deployment frequency. Those were the right measures when humans were the bottleneck. They are not the right measures now.

The fair objection: judgment can’t be measured either. Replace one unmeasurable thing with another and you haven’t built a better system. You’ve built a more opaque one where your manager’s subjective read of your “instincts” determines your promotion. The five rungs below are my attempt to solve that by making judgment observable. Not measured directly, but identified through specific, concrete behaviors that consistently produce it and specific, concrete behaviors that consistently undermine it. The goal is a set of signals a manager can actually point to in a conversation.

A 2025 LeadDev survey found that 54% of engineering leaders plan to hire fewer junior engineers because AI copilots are enabling seniors to handle more. On the surface this looks like efficiency. Underneath, it is the slow destruction of the talent pipeline that has produced every senior engineer alive today. A Stanford Digital Economy Study found that by July 2025, employment for software developers aged 22 to 25 had declined nearly 20% from its peak in late 2022. AWS CEO Matt Garman said it best when he heard proposals to replace junior engineers with AI: “That’s like, one of the dumbest things I’ve ever heard. How’s that going to work when ten years in the future you have no one that has learned anything?”

Your engineering ladder is your answer to all of this. If it still measures velocity, story points, and sprint completion (metrics that made sense when humans were the bottleneck) it’s optimizing for a world that no longer exists.

A Ladder Worth Climbing

What follows is the engineering ladder I would build for a team operating in 2026. It doesn’t discard the traditional levels. It reframes what earns each one. The axis shifts from what you produce to what you protect.

Five rungs. Three signals per rung: what excellence looks like, what struggle looks like, and when someone is ready to move up.

One note before we start. These rungs do not quietly push great engineers toward management. The Architect, Multiplier, and Strategist are all individual contributor paths. You do not need to manage people or attend CFO meetings to advance. What you need is to demonstrate that your presence raises the quality of work around you. Through code reviews, documentation, standards you set, systems you build. The path is wide. The requirement is impact that compounds beyond your own output.

Salary ranges reflect 2026 US market data from Glassdoor and the Bureau of Labor Statistics, blending base salary with total compensation. Each range carries a $30K–$40K spread because that spread is real. It’s the difference between someone who just crossed the threshold into a rung and someone who has owned it for three years. Where someone lands within a band should track how long they’ve been operating at that level and how consistently they show the signals below. Use these as calibration points, not contracts. FAANG bands run significantly higher at every level.

Rung One: The Apprentice (formerly Junior Engineer — $85K–$120K)

Their question: why might this output be wrong?

Not “can you ship it?”. AI can ship it. The Apprentice earns their place by interrogating output rather than accepting it.

Excels when

1. They flag inconsistencies before merging,

2. ask for context before shipping, and

3. escalate uncertainty rather than guess through it. Their pull requests include questions, not just solutions.

They build original features and write real code — the difference from the old junior role is that interrogating AI-assisted output, their own and others’, is now what signals genuine understanding. Prompting fluently and understanding deeply are not the same thing. The gap between them matters enormously by Rung Three.

Struggling when

1. they treat velocity as the goal

2. they ship generated code they cannot explain

3. they hide blockers because they don’t want to look like they don’t know something, which at this level is exactly what they should be saying out loud.

Ready to move up when

1. they can explain why a specific piece of AI-generated code will fail in a specific production scenario, not just that it might

2. they have shipped something end-to-end with minimal guidance and their postmortem was more insightful than their manager expected.

Rung Two: The Builder (formerly Mid-Level Engineer — $120K–$155K)

Their question: what is this feature protecting the company from?

The Builder owns a feature end-to-end. Not just shipping it, but the definition of done, the edge cases, the production monitoring, the customer impact. In a world where AI can scaffold a service in two hours, their value is in knowing which service is the right one to build and when to throw the generated output away and start again. They write specs before they prompt.

Excels when

1. they see around the feature they’re building — upstream dependencies, downstream consequences, what happens when it breaks

2. they know what matters to the business, not just the ticket

Struggling when

1. they are technically proficient but scoped too narrow

2. they deliver features in isolation

3. they need an explicit ticket to know what to work on next.

Ready to move up when

1. they have proactively identified and resolved a problem nobody assigned them

2. they have mentored an Apprentice visibly and successfully

3. their technical decisions reference company goals without being prompted.

Rung Three: The Architect (formerly Senior Engineer — $155K–$210K)

Their question: what does this decision cost us in six months?

This is where most performance ladders stop being interesting, which is a shame. It’s where the real leverage begins. The Architect sees downstream consequences before anyone else does. They translate technical debt into business cost without being asked. Not in a presentation. As a reflex.

Excels when

1. they walk into cross-functional conversations with answers before people have finished asking the question

2. the C-Suite understands them

3. their technical instincts show up as financial clarity

Struggling when

1. they are technically brilliant but organizationally invisible

2. they are right in the code review, wrong in the room

Being correct is not enough at this level. The AI era makes the gap between correct and heard more consequential than ever.

Ready to move up when

1. they have demonstrably improved the output quality of a team they don’t manage

2. they have translated a technical risk into a business risk and been understood by a non-technical executive

3. they have driven a consequential build-vs-buy decision and can show the math.

Rung Four: The Multiplier (formerly Staff Engineer — $210K–$300K)

Their question: how does the team make better decisions because of you?

Their output is not features. It is the quality of everyone else’s judgment. If a Multiplier leaves, the team doesn’t slow down by one; it slows down by the compounded capability they were adding to everyone around them. They define how AI-generated output gets evaluated, trusted, and deployed. They don’t just use the tools. They determine how the organization relates to them.

Excels when

1. engineers leave their code reviews smarter than when they arrived

2. their standards get adopted without being mandated

3. their departure would be felt across teams, not just their own.

Struggling when

1. they are still primarily an individual contributor

2. they produce excellent work that doesn’t compound

3. they hoard knowledge because it makes them feel essential rather than building systems that transfer it.

Ready for expanded scope when

1. they have changed how the engineering organization evaluates an entire category of work. Not just one team but the organization.

The bar is voluntary adoption. People following a standard because they were told to is compliance. People following it because it made their work better is influence.

Rung Five: The Strategist (formerly Principal Engineer — $280K–$450K+)

Their question: where do we need to be in two years and what does it cost to get there?

The Strategist’s domain is the future state of the business, not the current state of the codebase. They have opinions on build-vs-buy decisions that factor in organizational capacity, not just technical preference. They understand the Engineering Efficiency Ratio and know how their decisions move it. They are not waiting to be asked about the business. They are thinking about it before the business knows it has a question.

Excels when

1. they are in the room for business decisions before the technical implications surface

2. the CEO treats their input as commercial, not just technical

3. they can quantify the cost of standing still.

Struggling when

1. they have expert architecture instincts but no strategic patience

2. they want to solve the problem in front of them rather than the problem three years out

3. they can describe the vision but not the price tag.

Ready for more scope when

1. they can point to two decisions they made that the company is still benefiting from two years later.

Not decisions they recommended. Decisions they drove.

When You Let Someone Go

You let an engineer go when their judgment is not improving and their presence is actively degrading the judgment of others. Not when they write slow code. Not when they miss a sprint. Not when a feature ships with bugs. Those are correctable.

What is not correctable is an engineer who ships AI-generated code they cannot explain, who creates production surfaces that no one can reason about, and who trains the Apprentices around them to do the same. In the old world, that engineer was slower. In this world, they are a liability.

The inverse is more commonly overlooked. The engineer who makes your team smarter (who raises the quality of judgment around them even if they write less code than anyone else) is the person you build around. The Multiplier you can’t easily measure is often the one holding everything together.

If you’re not sure which kind you have, check what happens the week after they go on vacation.

What You Build This Week

If you run a team of twenty or more engineers without a written performance ladder that addresses AI-augmented work, you are measuring your team against a standard that exists nowhere but in your head. Promotions are political. Feedback is vague. Your best engineers are leaving because they can’t see a path forward.

Three things.

1. Put your current engineers against the five rungs

   Not to demote anyone — to understand where the gaps in judgment actually are. You will find Builders being paid like Architects. You will find Multipliers treated like Builders. That is information worth having before someone else delivers it to you with a resignation letter.

2. Ask every manager what Priya asked me: what does senior mean on your team right now?

   If they can answer it without mentioning years of experience or sprint velocity, great. If they can’t, that is where your work starts.

3. And before you cut Apprentices to protect headcount, read Garman’s line again.

   The engineers who will run your team in 2030 are learning how to think about code right now. Stop creating the conditions for that learning and you will not have a senior team in five years. You will have AI tools and no one who knows what they are doing.

Dorsey may be right that 100 people with AI can do what 1,000 once did. But someone still has to be smart enough to point the AI in the right direction, and wise enough to know when not to.

Build the ladder that finds those people. Reward them for their judgment. Keep them longer than two summers.

The rest will follow.

Etienne de Bruin is the founder of 7CTOs and coaches technology leaders through the complexity of scaling engineering organizations.

It is a Thursday evening and I am sitting at my kitchen table with a cup of coffee going cold next to my laptop. I have been hearing whispers about OpenClaw for a few days now. An open-source agent that lives inside your WhatsApp or Telegram. Created by Austrian developer Peter Steinberger, released quietly in November 2025, and now — in early 2026 — amassing over 182,000 GitHub stars and 30,000 forks. I decide to spend an hour with it.

I get it running. And then I spend the rest of the evening testing it.

I type: “Check my calendar for tomorrow and tell me if I have back-to-back meetings.”

And it does it.

I type: “Draft a quick summary of the last three emails from my CEO.”

And it does that too.

I type: “Find the GitHub issue where we discussed the authentication refactor and pull the key decision.”

Done.

I sit back. The coffee is cold. And I realize something. For the last two hours, I have been getting work done. Real work. Calendar checks, email triage, repository searches, task creation. And I have not opened a single application. Not my calendar app. Not my email client. Not GitHub. Not my task manager.

I have just been texting. An assistant that lives on my own machine, connects to the services I already use, and executes whatever I describe in plain language.

My brain does not feel disrupted. It feels embarrassed. Because I realize I have spent 30 years building products with buttons, forms, menus, and onboarding flows — and the most powerful thing I have used in months has none of that.

Why people are losing their minds over the claw

The world’s AI Tik Tokkers are marveling at OpenClaw’s impact. And yes, it is a simple architecture. A local gateway running a WebSocket control plane, connecting an LLM of your choice to the messaging apps you already have on your phone. No new surface to learn. No subscription to a separate product. The model is agnostic — Claude, GPT, DeepSeek, or something running entirely local on a Mac Mini in your office.

But that’s not the interesting part.

The interesting part is why people are losing their minds over it. Not just developers. People. Non-technical users are saying things like “this is my iPhone moment” and “I got up and running and I’ve been blown away.” One user described having their agent submit health reimbursements, find doctor appointments, and surface relevant documents. Another had their instance autonomously write code, run tests, and open pull requests — all without human prompting.

That enthusiasm has a shadow. In February 2026, Cisco’s security team found a third-party OpenClaw skill performing data exfiltration and prompt injection without user awareness. Researchers disclosed CVE-2026-25253 — 42,000 exposed control panels across 82 countries, 386 malicious skills in the community marketplace. One OpenClaw maintainer warned that the project is “far too dangerous for casual users.” An agent that can do anything is only as safe as the boundaries you define for it — which is precisely the argument for building MCP servers with deliberate, scoped permissions rather than handing agents a raw API key and hoping for the best.

Now, if you are a CTO of a 60-person engineering team in a regulated industry, you may be thinking: my customers are nowhere near this. Their procurement teams, their compliance officers, their enterprise security reviews — none of them are ready to let an agent loose on their SaaS stack. And you would be right, today. Enterprise adoption of agentic workflows will lag this developer enthusiasm by three to five years, easily.

But that’s not the question worth asking. The question worth asking is: what does it tell you about where the gravity is pulling?

What is actually happening with OpenClaw is not a new AI model or a clever piece of infrastructure. It is the first widely-adopted proof that you can eliminate the interface entirely from daily work. For thirty years, software has charged users a tax — the cost of learning the product. Every SaaS you have ever built asks your users to pay it. They navigate your UI. They learn your vocabulary. They figure out where the filter is. They go through your onboarding. They submit a support ticket when they can’t find the export button.

OpenClaw collects no daily tax. Once it is running, you never open another app. You describe what you want in the language you already speak, and the system figures out the rest. Calendar, email, GitHub, task management, file searches — all of it happens through conversation. What people are mesmerized by is not artificial intelligence. It is the elimination of every learned behavior they had to acquire to use software. You never navigate someone else’s information architecture again. You never hunt for a feature. You never click through three menus to export a CSV.

You just ask.

We Have Seen This Movie Before

Cast your mind back to 2004. Salesforce had been quietly building APIs since day one in 2000, and they had just turned “Software as a Service” into “Platform as a Service.” Today 90% of Salesforce’s revenue flows through their API.

Twilio launched in 2008 with a single API for making phone calls. By 2018, that had grown to $129 million in quarterly revenue — up 48% year-over-year. Stripe turned payment processing into seven lines of code. By 2015, APIs were responsible for over 60% of all web traffic.

What drove all of it? Someone removed a tax that developers had been quietly paying for years — the cost of standing up your own infrastructure for common problems. Twilio didn’t invent telephony. They made telephony stupid easy to integrate. Stripe didn’t invent payments. They made payments stupid easy to integrate.

Crucially, Twilio and Stripe were API-first from inception. They didn’t have fifteen years of UI-coupled architecture to unpick. They built clean, predictable surfaces and made other systems dependent on their data. That dependency became their moat.

The CTO thinking about agent-native architecture today is not Twilio. They are the enterprise product that watched Twilio emerge and had to figure out what to do with an existing monolith. That is a harder and more honest problem. And it is the problem worth solving.

Your SaaS Has the Wrong Customer

The assumption baked into every SaaS product built in the last twenty years is that a human being will open a browser tab and interact with it through a mouse or a touchscreen. Every design decision you have ever made — your navigation, your information architecture, your feature discoverability, your mobile experience — exists to serve that assumption.

That assumption is cracking.

Anthropic just launched Cowork. OpenAI has its own agentic surfaces. Every major platform is racing toward agent-native workflows. In these models, the thing that integrates with your SaaS is not a person. It is an agent. And agents do not click. They call APIs. They consume structured data. They act on outputs, not on visual interfaces.

A simple test: if an agent called your product’s API right now, would it get back structured, actionable data — or frontend scraps? The answer tells you more about your architectural readiness than any roadmap review.

This is not a reason to abandon your UI. Your human users still need it, and will for years. But it is a reason to ask a design question you have probably never asked: is my business logic separable from my visual layer? In a well-architected product, the answer should be yes. If your core functionality is tightly coupled to your frontend — and you would be surprised how many products at scale have exactly this problem — then every agentic integration you try to build will be fighting your own architecture.

The CTOs who will win the next decade are the ones who recognize this now, while they still have time to do something about it without a crisis forcing their hand.

The Protocol That Changes the Question

This is where MCP, the Model Context Protocol, Anthropic’s open standard for connecting agents to data sources, enters the picture. OpenClaw is built to integrate with MCP servers. So is Claude. So is every agent framework worth paying attention to right now.

MCP servers are to agents what APIs were to the Web 2.0 ecosystem. A standardized way for an LLM-powered agent to reach into your product, retrieve your data, and take actions on behalf of a user. When Salesforce opened their API, they were betting on ecosystem stickiness: get other systems dependent on your data and your logic, and you become infrastructure. The agent workflows that integrate your MCP server will become dependent on your data in exactly the same way.

A concrete example: Notion published an MCP server. Now an agent like OpenClaw can create pages, update databases, query your workspace, and surface documents — all without a human ever opening Notion’s UI. Notion’s data became reachable by automated workflows that their product team never had to design or build.

That’s the bet. Not replacing your product. Making your product’s value available to users who have stopped using interfaces.

The Practical Path

You do not need to rebuild your entire product. But you do need to be honest about what the work involves.

The first step is a design conversation, not a technical one. Draw a line between what your product does and what your product shows. The “does” layer, your business logic, your data mutations, your integrations is what agents need. It should be cleanly separable from your visual layer. If it isn’t, you are looking at non-trivial architectural work. Not a rewrite, but refactoring that will require real engineering time. Go into that conversation with your team clear-eyed about the cost.

Second, think about your data as a platform. The API economy taught us that the most durable businesses were the ones whose data other systems needed to function. Plaid doesn’t have a consumer-facing UI to speak of. It is pure data infrastructure. Your product almost certainly has unique data that agent workflows will eventually need. Decide now who should be able to reach it, and under what conditions.

Third, publish an MCP server. Start small. Pick your three most valuable actions, the things your power users do most often and package those as callable tools for an agent. This is exactly how the API economy started. Twilio put a few phone call actions behind a simple endpoint and watched what developers built. The developers who integrated early became dependent on Twilio. The same stickiness applies here.

The honest caveat: if your product’s core logic is tightly coupled to your frontend, step three will be harder than it sounds. You will hit the architectural problem before you hit the MCP server. That is useful information. It tells you something about your codebase that matters beyond agents entirely.

The Last Time We Were Here

There is a generation of CTOs who lived through the Web 2.0 API explosion and watched their competitors who moved early become platform companies. The ones who waited became integrations: dependent on platforms for distribution, at the mercy of their pricing decisions.

OpenClaw crossed 182,000 GitHub stars in under two months. It has been adapted for Chinese super-apps running on DeepSeek. SwitchBot just launched what they call the world’s first local home AI agent with native OpenClaw support. This is moving faster than most of us want to admit.

The zero-friction interface is not a distant trend. It is a working product that people are using right now to automate their lives by texting in plain English. Your enterprise customers may not be there yet. But the developers building tomorrow’s enterprise workflows are experimenting with this today. And the products that are agent-ready when that demand arrives will look an awful lot like infrastructure.

The agent era will sort companies the same way the API era did — into platforms and integrations.

Build the MCP server. Make your data reachable. Separate your logic from your UI.

Don’t become the integration.

With Love and Respect for you
Etienne

Are you rebuilding your SaaS architecture with agents in mind? I’d love to hear how you’re thinking about it. Email me directly or join one of our 7CTOs peer groups where CTOs are wrestling with exactly these questions.

Fast forward to 2016. Researchers at the University of Edinburgh were wrestling with a problem in neural machine translation: how do you handle rare words? Words like “antidisestablishmentarianism” or German compound nouns that stretch across half a page. Their solution? Dust off Gage’s compression algorithm and repurpose it for language. They published their findings, and within a few years, every major language model adopted some variant of this approach.

The same year that paper dropped, the ICO craze was building steam. By 2017, startups had raised over $5 billion through initial coin offerings. Tokens were everywhere. Bitcoin tokens. Ethereum tokens. Utility tokens. Security tokens. The word “token” became synonymous with speculative frenzy and blockchain gold rushes.

Now tokens are back. But these tokens have nothing to do with blockchain. They have everything to do with how AI reads, writes, and charges you for the privilege.

The global LLM market hit $6.33 billion in 2024 and is accelerating. Every API call, every ChatGPT conversation, every Claude response is measured and billed in tokens. Yet most CTOs I talk to have only a surface understanding of what a token actually is and why it matters for their technology strategy.

This is a problem.

The Invisible Tax on Your AI Budget

When OpenAI introduced GPT-4o mini, they priced it at $0.15 per million input tokens and $0.60 per million output tokens. Claude 3.5 Sonnet runs $3 per million input tokens. Gemini 2.5 Pro charges $1.25 per million input tokens for prompts under 200,000 tokens.

These numbers seem small until you realize what they mean in practice.

A token is not a word. A token is not a character. A token is a chunk of text that the model has learned to recognize as a meaningful unit. For English, that usually works out to about 4 characters or roughly 0.75 words per token. The sentence you’re reading right now? Probably 15-20 tokens.

But language is messy. And tokenization reveals just how messy.

Take the word “running.” In most tokenizers, that’s a single token. But “antidisestablishmentarianism”? That gets broken into five or six pieces. The tokenizer sees “ant” + “idis” + “establishment” + “arian” + “ism” and treats each piece as a separate billing unit.

Code and structured data behave differently. This is where CTOs building production systems should pay close attention. JSON structures, API responses, configuration files: all tokenized according to patterns the model learned during training. A 1,000-word English document might consume 1,300 tokens. The equivalent JSON payload could easily hit 2,000.

And then there’s the multilingual dimension.

Research from 2023 found that tokenizers trained primarily on English text created significant cost premiums for underrepresented languages. A sentence in Burmese or Tibetan might require ten times the tokens of its English equivalent. The good news: modern tokenizers are rapidly closing this gap. OpenAI’s o200k_base vocabulary—double the size of GPT-4’s tokenizer—has reduced premiums for major languages to roughly 1.5x to 4x compared to English. For CTOs building products that serve global audiences, this represents meaningful progress, though the gap hasn’t fully closed.

Inside the Token Factory

Understanding tokenization starts with understanding why we need it at all.

Language models don’t read text. They process numbers. Every word, every character, every emoji must be converted into a numerical representation before the model can work with it. The question is: what’s the right size for these numerical chunks?

Character-level tokenization treats each letter as a separate token. The word “hello” becomes five tokens: h, e, l, l, o. This approach handles any input you throw at it, including made-up words, typos, and foreign scripts. But it creates sequences that are absurdly long and loses the semantic grouping that makes language meaningful.

Word-level tokenization goes the other direction. Every word gets its own token. Great for common words. Disastrous for the vocabulary explosion problem. English alone has over 170,000 words in current use. Add technical jargon, proper nouns, and the infinite creativity of internet discourse, and you’re looking at a vocabulary that grows without bound. Any word the tokenizer hasn’t seen before? It simply cannot process it.

Subword tokenization splits the difference. The algorithms learn which character combinations appear frequently in the training data and group them into tokens. Common words like “the” or “running” get their own tokens. Rare words get broken into recognizable pieces.

Philip Gage’s Byte Pair Encoding works by counting. Start with individual characters. Find the pair that appears most often in your training data. Merge that pair into a new token. Repeat until you hit your target vocabulary size.

GPT-2 used a vocabulary of about 50,000 tokens built this way. GPT-4 expanded to roughly 100,000. GPT-4o’s o200k_base tokenizer doubled that again to around 200,000 tokens—a major upgrade that dramatically improved efficiency for non-English languages and code. Each merge decision was made purely on frequency. No linguistic knowledge, no semantic analysis. Just counting.

This creates some interesting side effects.

Numbers are particularly chaotic. The number “12345” might tokenize as “123” + “45” in one model and “1” + “234” + “5” in another. This has implications for any application doing arithmetic or processing financial data.

Chinese characters often get tokenized one per token in older systems because they lack whitespace boundaries and weren’t as heavily represented in English-centric training data. The expanded vocabularies in modern tokenizers have helped here, but a Chinese user and an English user sending the same message still typically pay different rates because of decisions made during tokenizer training.

The Three Tokenization Families

Modern language models cluster around three main approaches:

1. Byte Pair Encoding (BPE) powers the GPT family. Frequency-driven, merging common pairs until reaching target vocabulary size.

2. WordPiece (BERT, some Google models) considers likelihood rather than raw frequency, adding special prefixes to indicate word continuations.

3. SentencePiece emerged for truly multilingual models, treating input as raw bytes rather than assuming whitespace marks word boundaries.

The practical differences matter when choosing models for production. A tokenizer trained heavily on English will be cheap for English but expensive for other languages. A more balanced tokenizer costs more per token on English but delivers consistent pricing across languages.

What This Means for Your Architecture

Every technical decision in an LLM application traces back to tokens.

Context windows are measured in tokens. GPT-4 Turbo offers 128,000 tokens. Claude 3 handles 200,000. Gemini 2.5 Pro pushes to 1 million. But here’s the critical insight that many CTOs miss: filling those windows costs money, and the model’s ability to use information degrades for content buried in the middle of very long contexts.

Research published in Transactions of the Association for Computational Linguistics found that LLM performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access information in the middle, even for explicitly long-context models. Having a 2-million-token context window doesn’t mean your model will reason equally well across all 2 million tokens. Structure matters.

Prompt engineering is token engineering. A verbose instruction like “Please provide a comprehensive and detailed explanation of the following concept” consumes about 12 tokens. “Explain thoroughly” accomplishes the same goal in 3 tokens. At scale, that’s a 75% reduction in prompt overhead.

Caching strategies depend on tokenization and on prompt structure. OpenAI automatically caches prompts over 1,024 tokens, reducing costs for repeated requests by up to 50%. Anthropic requires explicit cache control headers. But caching only works when your prompts share an identical prefix.

Here’s a high-value tip: if your team puts a timestamp at the start of every prompt, you’re breaking the cache. Every single request gets processed from scratch because the prefix changes with each call. Move static content like system instructions, few-shot examples and reference materials to the beginning where caching can take effect. Dynamic content (user queries, timestamps, variable data) belongs at the end. Get this wrong, and you can burn thousands of dollars on requests that should have been cached.

Output costs consistently exceed input costs across all major providers. The ratio typically runs 3-5x, meaning that getting concise responses saves more money than optimizing prompts. Applications that generate verbose outputs pay a premium that accumulates fast.

The Emerging Alternatives

Here’s something worth tracking: tokenization itself may be a temporary architectural choice, not a permanent law of physics.

Research into token-free language models is advancing rapidly. Architectures like MambaByte and MEGABYTE learn directly from raw bytes, removing the inductive bias of subword tokenization entirely. These approaches show competitive performance with state-of-the-art subword Transformers on language modeling tasks while eliminating the entire vocabulary mismatch problem.

Why does this matter? Token-free models would end the multilingual cost premium entirely. A sentence in Burmese would cost exactly what a sentence in English costs—measured in bytes, not tokens. Code, structured data, and unusual text formats would all normalize.

We’re not there yet. These approaches face efficiency challenges that prevent immediate production deployment. But the research trajectory suggests that in three to five years, the entire token economy we’re building systems around today could look quite different.

For CTOs making architecture decisions now, the practical takeaway is to build systems that abstract away the tokenization layer where possible. Don’t hard-code assumptions about token costs into your economic models. Monitor your actual token usage by feature, by content type and/or by language so you can adapt as the landscape shifts.

Building Your Token Intelligence

Start by instrumenting your applications to track token usage at a granular level. Not just total tokens per day, but tokens per feature, per user segment, per content type. You need visibility into where your tokens go before you can optimize.

Test your content against multiple tokenizers. OpenAI provides a free tokenizer tool. Run your typical inputs through and compare the results against what you’d pay with Anthropic or Google. If you’re processing lots of code, compare tokenization efficiency across models designed for code versus general-purpose models.

Consider hybrid strategies. Simple queries might route to cheaper models with efficient tokenizers. Complex queries might justify premium models with larger context windows. The token economics should inform your model routing logic.

The Token Economy Evolves

The LLM API market shows aggressive price competition. Inference costs fell roughly 10x per year through 2024, with some analysts estimating that costs for GPT-3.5-class performance dropped 280-fold between 2020 and 2024. Prices for frontier models continue declining.

New tokenization methods continue to emerge. Research into morphologically-aware tokenizers promises better efficiency for agglutinative languages. Byte-level models that skip tokenization entirely are showing competitive results for some tasks. The field is far from settled.

What remains constant is the fundamental insight: tokens are the atomic unit of AI. Every capability, every cost, every limitation traces back to how text becomes numbers and numbers become text again.

Philip Gage probably didn’t imagine his compression algorithm would underpin a multi-billion dollar industry three decades later. But the principle he discovered holds: find the patterns, exploit the redundancy, and you can represent complex information efficiently.

For CTOs, the message is clear. Tokens aren’t just a billing unit. They’re the lens through which your AI applications see the world. Understand that lens, and you understand what your AI can and cannot do.

The blockchain tokens of 2017 were speculative instruments. The LLM tokens of 2025 are fundamental infrastructure. Both demand the CTO’s attention. Only one will shape the next decade of technology strategy.

Time to learn the currency.

Royce never used the word waterfall. More importantly, directly beneath his now-infamous diagram, he wrote something the industry conveniently ignored: “I believe in this concept, but the implementation described above is risky and invites failure.”

The man credited with inventing waterfall was actually warning against it.

Royce spent the remainder of his paper advocating for iteration, prototyping, and feedback loops. His third recommendation was explicit: “Do it twice.” Build a pilot model first—what he called a “simulation”—to test critical design and operational areas before committing to the version delivered to the customer. He described the unique skills needed for this pilot phase: developers who “must have an intuitive feel for analysis, coding and program design” and can “quickly sense the trouble spots in the design, model them, model their alternatives.” His son, Walker Royce, would later become a principal contributor to the IBM Rational Unified Process, an iterative methodology. The irony is complete.

Three Decades of Monuments to a Misreading

For three decades, software teams built monuments to a misreading. Requirements documents grew to hundreds of pages. Sign-offs multiplied. Testing became something that happened after all the code was written, right before the panicked realization that nothing worked as expected. Projects hemorrhaged money, missed deadlines, and delivered systems nobody wanted.

The industry was ready for a rebellion.

Seventeen Anarchists in the Mountains

On February 11, 2001, seventeen software practitioners drove up Little Cottonwood Canyon to the Lodge at Snowbird in Utah (I just moved here btw!!). They represented competing methodologies with names like Extreme Programming, Scrum, Crystal, and Dynamic Systems Development Method. Bob Martin, who organized the gathering, later joked that assembling a bigger group of organizational anarchists would be hard to find.

They came because the status quo had become unbearable. The average lag between identifying a business need and deploying a software solution had stretched to three years. Documentation had replaced delivery. Process had suffocated progress.

What They Agreed On

Martin Fowler, one of the attendees, expected little from the meeting beyond making contacts that might turn into “something interesting.” Alistair Cockburn had reservations about the term “lightweight methodologists” that the group had been using: “I don’t mind the methodology being called light in weight, but I’m not sure I want to be referred to as a lightweight.”

What emerged from those two days surprised everyone, including the participants. They agreed on four values and twelve principles that prioritized working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

The only concern with their chosen name came from Martin Fowler, who worried that most Americans didn’t know how to pronounce the word “agile.”

The Manifesto’s Unintended Reach

The Manifesto spread faster than any of its authors anticipated. Mike Beedle, one of the signatories, never foresaw its adoption in contexts beyond software, like leadership and sales. James Grenning took years to realize it was “such a big deal.” Kent Beck’s original vision for Extreme Programming was simply to make the world safe for programmers.

For two decades, Agile became orthodoxy. Sprints replaced phases. User stories replaced requirements documents. Standups replaced status meetings. The pendulum had swung.

The Core Idea

The methodology that wins is the one that matches how you actually build.

Waterfall failed because it assumed requirements could be known completely upfront. Agile succeeded because it embraced uncertainty. Now AI is introducing a third variable: when your implementer is an algorithm, the rules change again.

Why This Matters Now

Something unexpected is happening in engineering organizations that have embraced AI coding assistants. Teams are writing more documentation, not less. Design documents are growing longer. Requirements specifications are becoming exhaustive. One engineering leader described the emerging pattern as “Agile planning, waterfall execution.”

The reason is straightforward: AI thrives on precision. As one AI engineer put it, “the agents we have right now need what waterfall provides even more than people do.”

The High Cost of AI Coding

When you hand a vague prompt to Claude or Copilot, you get vague results. The AI will happily generate plausible code, but plausible isn’t the same as correct. The model makes assumptions at every turn. Sometimes those assumptions align with your intent. Often they don’t. You end up in a debugging loop that feels less like pair programming and more like archaeology.

Andrej Karpathy, co-founder of OpenAI, coined the term “vibe coding” in February 2025 to describe this loose approach: describing what you want in natural language, accepting AI suggestions without carefully reading the diffs, and iterating until something seems to work. It’s fast. It’s fun. And according to a randomized controlled trial published by METR in July 2025, experienced open-source developers using this approach on their own mature codebases actually took 19% longer to complete tasks than those working without AI assistance.

The METR Study: What CTOs Need to Know

The study deserves a closer look. METR recruited 16 developers who had contributed to large open-source repositories (averaging over one million lines of code and 22,000 GitHub stars) for an average of five years. These weren’t beginners learning a new codebase. These were experts on home turf, using frontier tools like Cursor Pro with Claude 3.5 and 3.7 Sonnet during the February-June 2025 study period.

The perception gap was striking. Before starting, developers predicted AI would make them 24% faster. After completing the study, they estimated AI had improved their productivity by 20%. The actual measurement: 19% slower. METR explicitly notes that their results may not generalize to other contexts—less experienced developers, unfamiliar codebases, or different types of tasks might see different outcomes. But for experts working on systems they know intimately, the vibe coding approach created more friction than it removed.

The problem isn’t the AI. The problem is the input.

The Distinction That Matters

Simon Willison, a programmer who has thought deeply about AI-assisted development, draws a clear line: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding. That’s using an LLM as a typing assistant.” The distinction matters because it identifies where the value creation actually happens.

Amazon’s Kiro, an agentic IDE launched in July 2025 and made generally available in November, embodies this insight. When you start a new project in Kiro, it asks you to choose between two modes: “Vibe” for exploratory chat-driven coding, or “Spec” for plan-first development. The Spec mode forces you through a structured workflow: first, requirements with detailed acceptance criteria written in EARS notation; then, technical design with diagrams and schemas; finally, implementation tasks sequenced by dependency.

Why AWS Built a Project Manager Into an IDE

AWS’s rationale was blunt. As product lead Nikhil Swaminathan and VP Deepak Singh explained: “When implementing a task with vibe coding, it’s difficult to keep track of all the decisions that were made along the way, and document them for your team.” The spec-driven approach emerged because users weren’t giving AI enough detail to get high-quality results. The tool itself acts like a project manager, guiding teams to plan before coding.

Research cited by AWS found that addressing issues during the planning phase costs five to seven times less than fixing them during development. This principle has always been true. What’s changed is that AI agents amplify the difference. A human developer encountering an ambiguous requirement might pause, walk over to a product manager’s desk, and ask a clarifying question. An AI agent encountering the same ambiguity will make a decision and keep generating code.

We’ve Heard This Before

If you’re experiencing déjà vu, you’re not wrong. “The spec is the code” echoes promises from the 1990s—UML, Model-Driven Architecture, CASE tools that would let us draw diagrams and generate applications. Those initiatives failed because the visual specifications became as complex as the code they were supposed to replace. The abstraction didn’t abstract; it just moved the complexity sideways.

LLMs are different in one important respect: they handle natural language ambiguity far better than the rigid schema-driven tools of that era. A CASE tool choked on anything outside its formal grammar. An LLM can interpret “make the button look clickable” and produce reasonable CSS, even though that phrase would have crashed any 90s code generator.

The Maintenance Trap

But the leaky abstraction problem hasn’t disappeared. When the AI-generated code breaks, someone has to debug it. When security vulnerabilities emerge, someone has to patch them. When requirements change, someone has to decide whether to regenerate the module or surgically edit it. That someone needs to understand what the code actually does—not just what the spec said it should do.

This is the maintenance trap that keeps CTOs awake. If a spec generates 1,000 lines of code, you now own 1,000 lines of code. The technical debt doesn’t vanish because you didn’t type it yourself. The security vulnerabilities don’t excuse themselves because they came from a model.

Spec-driven development addresses this partially through synchronization. Kiro, for instance, keeps specs and code connected: developers can author code and ask the tool to update specs, or update specs to refresh tasks. This solves the common problem where documentation drifts from implementation. But it doesn’t solve the deeper question of how you refactor AI-generated code when requirements change. Do you regenerate everything and lose the human refinements? Do you surgically edit and let the spec drift? The tooling is still immature, and honest practitioners admit that the Day 2 operations story remains incomplete.

English Is Not the New Coding Language

Karpathy’s quip that “the hottest new programming language is English” makes for a great tweet, but let’s be serious for a minute. Writing a spec precise enough for an AI to implement correctly is still programming, just with different syntax.

If a product manager writes a spec detailed enough that an AI can implement it without clarification, that product manager has essentially written logic. They’ve specified what happens when the user submits an empty form, what happens when the database times out, what happens when two users edit the same record simultaneously. That’s programming, whether or not it looks like code.

The better framing isn’t “anyone can code now.” It’s that AI forces engineers to become architects first. The value shifts from implementation to specification, from typing to thinking. This isn’t democratization; it’s elevation. The developers who thrive will be those who can decompose problems, anticipate failure modes, and communicate intent with precision—skills that were always important but are now existential.

The Security Question

We also worry about what happens when detailed technical designs flow into an LLM. A comprehensive spec for your core product is, in effect, a “god prompt” containing trade secrets, architectural decisions, and competitive advantages. Even enterprise-grade models raise questions about data handling, training pipelines, and access controls.

The emerging best practice is to keep the spec-to-code pipeline within controlled environments. Tools like Kiro run on AWS infrastructure with options for customer-managed encryption keys and controlled data usage. Organizations with stricter requirements are exploring private VPC-hosted models or retrieval-augmented generation (RAG) architectures that keep sensitive context local while leveraging cloud models for generation. The tooling is evolving, but the principle is clear: if your spec contains your competitive moat, treat it with the same security posture as your source code.

When Spec-Driven Development Fails

Spec-driven development isn’t a silver bullet. CTOs should watch for these anti-patterns:

The Infinite Refinement Loop.

Teams get trapped perfecting specs instead of shipping software. The spec becomes a procrastination device. If your team has spent three sprints refining requirements and generated zero working code, you’ve replaced one form of paralysis with another.

The Premature Precision Problem.

Some features shouldn’t be specified in detail upfront. Exploratory work, R&D projects, and early-stage prototypes benefit from vibe coding’s looseness. Forcing exhaustive specs on discovery work kills the discovery.

The Specification Theater.

Teams produce beautiful specs that look comprehensive but contain the same ambiguities in longer sentences. “The system shall handle errors gracefully” doesn’t become clearer by expanding it to three paragraphs of corporate prose. Precision requires thinking, not word count.

The Ownership Vacuum.

When AI generates the code and the spec lives in a shared document, accountability diffuses. Nobody feels responsible for understanding the implementation. Bugs become orphans. The fix is explicit ownership: someone’s name goes on every generated module, and that person is responsible for understanding what the AI produced.

The Regeneration Roulette.

Teams discover that regenerating a module from an updated spec produces subtly different code. Tests pass, but behavior changes in ways nobody anticipated. Version control becomes treacherous when the “source” is a spec and the code is an output.

The New Shape of Development

If I still have your attention then you are one of the few CTOs who knows that the reading of the methodology needs to evolve. The binary of Agile versus Waterfall is dissolving into something more nuanced.

The insight from spec-driven development is that front-loading thinking doesn’t mean returning to six-month requirements phases. It means investing in clarity before asking an AI to execute. The spec becomes the prompt. The better the spec, the better the output.

Thoughtworks describes this emerging practice as using “well-crafted software requirement specifications as prompts, aided by AI coding agents, to generate executable code.” The specification is more than a product requirements document. It includes technical constraints, architectural decisions, interface definitions, and acceptance criteria precise enough that an AI can validate its own work against them.

How the Workflow Separates

The workflow separates planning and implementation into distinct phases. During planning, you collaborate with the AI to understand requirements, identify edge cases, and document constraints. This is iterative work. The AI asks clarifying questions. You refine your thinking. The spec emerges from the conversation.

Once the spec is finalized, implementation becomes more mechanical—though never fully automatic. The AI generates code that conforms to the documented requirements. Tests verify behavior against acceptance criteria. Documentation stays synchronized because the spec is the source of truth, not a byproduct.

Kiro’s approach takes this further with what it calls “hooks”—event-driven automations that trigger agent actions when you save or create files. A hook might validate that every new React component follows the single responsibility principle. Another might ensure security best practices are enforced. These hooks encode team standards in a way that the AI can execute automatically, replacing the mental checklists that developers previously carried in their heads.

The Validation Stack

The tools for validating AI-generated code are maturing rapidly. SWE-bench tests models on real GitHub issues from popular repositories. Code review benchmarks measure whether AI tools catch meaningful bugs without overwhelming pull requests with noise. In one July 2025 evaluation by Greptile, leading AI review tools achieved bug-catch rates ranging from 6% to 82% on fifty real-world pull requests from production codebases. The variance is enormous, which means tool selection and configuration matter.

Evals—the systematic evaluation of AI outputs against defined criteria—are becoming a core competency. Teams are building pipelines that automatically measure functional correctness, code quality, performance, and security. The pass@k metric quantifies whether generated code passes all defined tests. Tools like SonarQube and Semgrep flag issues in readability and maintainability. Security audits detect vulnerabilities before they reach production.

The goal isn’t to eliminate human judgment. It’s to focus human judgment where it matters most: defining what the software should do, validating that it does it, and evolving the system as requirements change.

What To Do Monday Morning

If you’re leading an engineering organization, you don’t need to overhaul your entire methodology. You need to adapt your practices to match how AI tools actually work.

Start with a single team and a single feature. Before anyone writes a prompt, spend the time to write a proper spec. Include user stories with acceptance criteria. Document the technical design: data models, interfaces, dependencies. Break the work into discrete tasks. Be specific about edge cases and failure modes. If you find yourself writing “handle errors appropriately,” stop and specify what appropriate actually means.

Then hand that spec to your AI coding tool and observe what happens. You’ll likely find that the output quality improves dramatically. The AI will make fewer assumptions because you’ve made your intent explicit. Debugging will shift from “what did the AI think I wanted?” to “how do I refine what I actually want?”

Build Validation Into Your Workflow

If you’re generating code at scale, you need tests at scale. Define acceptance criteria that can be automatically verified. Run static analysis on every generated artifact. Treat AI-generated code with the same rigor you’d apply to code from a new hire: review it, understand it, and hold it accountable. The METR study found that developers who couldn’t explain what the AI had generated spent more time fixing problems than they saved in writing code.

Establish clear ownership for AI-generated modules. Someone needs to be responsible for understanding, maintaining, and securing that code. Don’t let the fact that no human typed it obscure the fact that humans are accountable for it.

Invest in Specification Skills

Invest in the spec-writing capability of your team. Product managers who can write precise requirements become force multipliers. Engineers who can translate ambiguous requests into unambiguous specifications become the new 10x developers. But be clear-eyed about what this means: spec-writing at this level is a technical skill, not a documentation chore.

Consider tools that enforce the spec-driven workflow. Kiro is one option. GitHub’s Copilot Workspace and Cursor’s agent mode offer similar capabilities. The common thread is structure: these tools separate thinking from typing, planning from implementing.

Address Security Upfront

Address security upfront. If your specs contain sensitive architectural details or trade secrets, ensure your AI tooling runs in controlled environments. Evaluate whether your compliance requirements allow cloud-hosted models or necessitate on-premise alternatives. Don’t discover your security posture after you’ve fed your product roadmap into a model.

Track the Outcomes

Track the outcomes. Measure time to first working implementation. Measure rework rates. Measure defect rates in production. Measure how long it takes to onboard a new developer to an AI-generated codebase versus a human-written one. If spec-driven development is working, you should see fewer iterations to reach a correct solution, less time spent debugging AI assumptions, and more consistent quality across the team.

The Battlefield Has Shifted

The methodology wars aren’t over. They’ve just shifted to a new battlefield. The CTO who recognizes that AI changes the calculus, who embraces detailed planning not as a return to waterfall but as a precondition for AI effectiveness, will build faster than competitors who are still vibe coding their way to production.

Royce was right in 1970: the risky approach is the one without iteration. He just couldn’t have imagined that the iteration would happen in a conversation with an AI, and that the output of that conversation would be a specification precise enough to generate working software.

The spec is the new prompt. Write it well and own what it produces.

The AI research community called it the “DeepSeek Shock.” Venture capitalist Marc Andreessen called it “one of the most amazing and impressive breakthroughs I’ve ever seen.” But for CTOs watching from the sidelines, the implications were more unsettling than impressive.

If a small team in Hangzhou could match frontier AI performance at roughly 1/100th the cost, what did that mean for the $200/month coding assistants we were happily paying for? What did it mean for the enterprise contracts we were signing? What did it mean for the vendor relationships we were building our engineering workflows around?

The answer, as 2025 unfolded, became increasingly clear. And as we move deeper into 2026, the CTO who ignores this shift does so at considerable risk.

The Collapse

When GitHub Copilot launched, paying $10/month for AI-assisted coding felt like stealing. When Claude Code emerged at $200/month for complex multi-file refactoring, the ROI math still worked. These tools genuinely accelerated development. They still do.

But the economics underneath them are crumbling.

DeepSeek’s R1 model achieved 90.8% accuracy on MMLU compared to GPT-4’s 87.2%. On the AIME 2024 mathematics benchmark, it scored 79.8% against GPT-4’s 9.3%. And it did this using “nerfed” H800 GPUs that the U.S. government had restricted China to using, thinking the hardware limitations would slow them down.

They optimized around the restrictions instead.

The Multi-Head Latent Attention architecture DeepSeek developed reduces memory requirements by 93%. Their Mixture-of-Experts approach activates only 37 billion of the model’s 671 billion parameters per token. The result is frontier-level intelligence that runs on hardware a well-funded startup can actually afford.

Within months of DeepSeek’s release, Chinese AI labs released a cascade of open-weight models that now occupy seven of the top ten spots on global coding benchmarks. Qwen 3 Coder scores 67% on SWE-bench Verified at roughly 1/30th the cost of Claude Sonnet. GLM-4.7 hits 91.2% on SWE-bench, outperforming most proprietary options. Kimi K2 Thinking solves 69% of real GitHub issues, within a few points of GPT-5’s performance.

These aren’t research curiosities. They’re production-ready models with Apache 2.0 licenses that you can download today and run on your own infrastructure.

Why This Matters for Your Engineering Budget

IBM’s Chief Architect for AI Open Innovation, Gabe Goodhart, put it plainly in a recent interview: “We’re going to hit a bit of a commodity point. It’s a buyer’s market. You can pick the model that fits your use case just right and be off to the races. The model itself is not going to be the main differentiator.”

The model itself is not going to be the main differentiator.

Read that again. If you’re a CTO currently paying per-seat licensing for AI coding tools, that sentence should make you uncomfortable.

A 500-developer team using GitHub Copilot Business faces $114,000 in annual costs. The same team on Cursor’s business tier pays $192,000. Tabnine Enterprise exceeds $234,000. These numbers assume stable pricing, which historically trends upward, not down.

Meanwhile, Kimi K2 is available at $0.088 per million tokens. GLM-4.5 runs at $0.11 per million tokens. DeepSeek’s pricing sits as low as $0.07 per million tokens with cache hits. For organizations processing thousands of pull requests, that’s the difference between a line item that requires budget approval and one that rounds to zero.

The gap between open-weight and closed proprietary models has effectively vanished for most practical coding tasks. Multiple analysts now predict full parity by Q2 2026.

The Vendor Lock-In Problem You Don’t See Yet

I coach CTOs who run engineering teams of 40 to 120 people. When I ask them about their AI coding tool strategy, most describe a single vendor relationship they’re increasingly dependent on.

They’ve trained their developers on specific workflows. They’ve integrated the tools into their CI/CD pipelines. They’ve built muscle memory around particular interaction patterns. And they’ve done this without an exit strategy.

Vendor lock-in in the AI coding space doesn’t announce itself the way traditional software lock-in does. There’s no proprietary file format holding your data hostage. The lock-in is subtler. It lives in the habits your team forms, the workflows they optimize for, and the switching costs that accumulate invisibly over time.

When your developers spend six months learning the quirks of a specific AI assistant, when your code review process assumes that assistant’s output format, when your documentation reflects that assistant’s conventions, you’ve built dependencies that don’t show up on any balance sheet.

The CTO Magazine recently published a piece titled “The Great AI Vendor Lock-In: How CTOs Can Avoid Getting Trapped by Big Tech.” Their conclusion: “The collapse of Builder.ai serves as a stark warning: overreliance on proprietary AI platforms can leave businesses stranded without access to critical systems or data.”

The companies most at risk aren’t the ones using AI coding tools. They’re the ones using AI coding tools without considering what happens when the economics shift underneath them.

What the Smart Money Is Doing

Red Hat’s recent analysis of the open-source AI landscape found that organizations in highly regulated sectors like telecommunications and banking are moving toward open models as a requirement, not a preference. Data residency regulations demand that AI usage stay local. Compliance requirements demand transparency into how models operate.

These organizations aren’t choosing open models because they’re cheaper. They’re choosing them because closed models create audit risks they can’t accept.

But even outside regulated industries, the pattern is emerging. Enterprise teams are adopting hybrid approaches. They use GitHub Copilot for general coding assistance while deploying open-source tools like Aider for sensitive projects that can’t leave their network. They route simple completions through cheap local models while reserving expensive API calls for genuinely difficult problems.

The PyTorch Foundation’s Executive Director, Matt White, identified three forces defining open-source AI in 2026:

1. global model diversification led by Chinese multilingual releases

2. interoperability as a competitive axis, and

3. hardened governance with security-audited releases and transparent data pipelines.

The organizations paying attention are building optionality into their AI strategy. They’re ensuring they can swap models without retraining their entire engineering team. They’re treating AI coding assistance as infrastructure rather than a service relationship.

The Models You Should Know About

If you’re going to reduce your dependency on paid AI coding services, you need to understand what’s available. The open-source landscape has matured faster than most CTOs realize.

Read more

But that number is the polite version of the story.

Dig deeper into the …

Read more

Marcus runs engineering for a fintech company. He has an executive assistant. He also reviews every calendar invitation she sends, rewrites half her emails, and spends Sunday nights reorganizing his week because he doesn’t trust anyone else to get it right. He tells me he’s exhausted. He tells me his EA “help…

Read more

“Walk me through what happened in your last p…

Read more

The reasoning sounds compelling enough. More flexibility. Better control over costs. No more dependency on third-party platforms. They’ve done the math on paper and the numbers …

Read more

Read more

The impact went beyond feelings: 86.5% …

Read more

Read more