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.

DeepSeek V3.2 remains the benchmark for efficiency. The MIT-licensed model handles 128,000 tokens of context, meaning it can analyze entire codebases without losing track of what it’s doing. The Speciale variant achieves gold-medal scores on competitive programming benchmarks.

Qwen 3 Coder from Alibaba offers 256,000 tokens of native context, expandable to one million. Its dual-mode architecture lets developers choose between rapid completions and deep reasoning depending on the task. At 67% on SWE-bench Verified, it solves roughly seven out of ten real programming problems.

GLM-4.7 from Zhipu AI was built specifically for agentic coding workflows. It integrates with tools like Claude Code, Cline, and Kilo Code with zero friction. The model runs on eight NVIDIA H20 chips, making self-hosting accessible to organizations that would struggle with larger models.

Kimi K2 Thinking from Moonshot AI uses a trillion-parameter Mixture-of-Experts architecture that activates only 32 billion parameters per token. Independent benchmarks rank it as the strongest model not made by OpenAI, Google, or Anthropic. Its agentic capabilities let it execute 200-300 sequential tool calls autonomously.

These models aren’t coming. They’re here. And they’re improving faster than the proprietary alternatives because the open-source community can iterate on them without permission.

The Prediction That Matters

By the end of 2026, the market for paid AI coding models will look fundamentally different than it does today.

I don’t mean that GitHub Copilot will disappear. I don’t mean that Claude Code will shut down. These products will continue to exist, and they’ll continue to improve.

What I mean is that the economic rationale for paying premium prices will erode to the point where it only makes sense for a narrow slice of use cases. The CTO paying $200,000 annually for AI coding assistance will look at the CTO paying $20,000 for equivalent capability and wonder what they’re getting for the extra $180,000.

The answer, increasingly, will be “not much.”

Tom Tunguz, GP at Theory Ventures, recently predicted that small language models and open-source alternatives will rise in popularity as research labs determine how to specialize them for particular tasks. Developers will prefer them for 10x cost reductions.

Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by end of 2026, up from less than 5% in 2025. But they also warn that over 40% of agentic AI projects will be canceled by 2027 due to escalating costs.

Those escalating costs come from vendor relationships that made sense at small scale but become unsustainable as usage grows. The organizations that avoid this trap will be the ones that built optionality into their AI strategy from the beginning.

What to Do About It

If you’re currently relying on a single AI coding vendor, you don’t need to abandon them tomorrow. The tools are genuinely good. The productivity gains are real. Ripping out working infrastructure to chase theoretical savings is rarely smart.

But you should be doing three things right now.

First, establish model-agnostic workflows. Your developers should be comfortable prompting AI assistants, not comfortable with a specific AI assistant. The interaction patterns that work with Claude Code work with Aider work with open-source alternatives. Build skills that transfer.

Second, run experiments with open models. Set up Ollama on a development server. Deploy a Qwen model behind your firewall. Give a small team permission to use local AI for a sprint. You need firsthand experience with what open models can and can’t do before you need to make migration decisions under pressure.

Third, negotiate your contracts carefully. If you’re signing annual enterprise agreements, build in flexibility. Avoid volume commitments that assume stable or growing usage. The leverage in these negotiations is shifting toward buyers faster than most vendors want to admit.

The paid AI coding market isn’t dying this year. But the conditions that made premium pricing rational are disappearing. The CTO who recognizes this shift and builds accordingly will have options. The CTO who doesn’t will be locked into contracts that their competitors have already walked away from.

The models are commoditizing. The question is whether you’ll be ahead of that curve or behind it.

But that number is the polite version of the story.

Dig deeper into the data and you find something more troubling. The average company uses only about half of the software licenses they’ve purchased. Large enterprises with 10,000+ employees spend $284 million on SaaS annually while using 660 different applications. Two-thirds of IT leaders report unexpected charges due to consumption-based or AI pricing models they didn’t fully understand when they signed the contract.

And we haven’t even talked about the integration tax yet.

When a CFO asked me recently why her engineering budget seemed to be disappearing into “connective tissue,” I had to explain what most CTOs already know but rarely say out loud: the middleware, the consultants, the custom pipelines stitching together systems that were never designed to talk to each other. These costs often exceed the subscription fees themselves.

For two decades, we accepted this trade. SaaS promised lower friction in exchange for compromise. We rented generic tools, adapted our workflows to vendor assumptions, and accumulated operational overhead in the form of integrations, administrators, and compliance scaffolding.

That trade no longer reflects the underlying economics.

The Rental Model We Never Questioned

SaaS solved a 1990s problem: how to distribute complex software when infrastructure, deployment, and maintenance were prohibitively expensive. It succeeded by centralizing ownership and standardizing behavior.

The model made sense when custom software meant six-figure development projects, 18-month timelines, and the constant dread of maintenance. Building your own tools was a rich company’s game. Everyone else rented.

But here’s what’s strange. We never stopped to ask whether the rental model still made sense once the underlying economics shifted.

Consider what’s actually happening inside most scaling organizations. According to Grip Security’s 2025 SaaS Security Risks Report, SaaS applications per employee have steadily risen, marking an 85% increase in the number of accounts per user. The average employee now juggles 13 different SaaS tools in their daily work.

Each of those tools comes with its own login, its own data model, its own API quirks. Each creates a new integration point. Each adds to the cognitive load of your teams. And each one guards its own silo of company data, preventing your AI systems from seeing the full context of your business.

The SaaS landscape has consolidated into what I call concentric circles of dependency. At the center sit platform giants: Salesforce, Microsoft, Google, Oracle, SAP. Their gravity pulls in smaller vendors who build integrations, extensions, and complementary tools. Around them orbit the integration layer: the middleware providers, the consultancies, the “implementation partners” who make their living connecting systems that don’t want to be connected.

Customers orbit furthest from the center, subject to forces they don’t control. Pricing changes ripple outward without negotiation. Feature deprecation happens on vendor timelines. Data portability remains theoretical. Switching costs compound over time.

The Math Has Inverted

Something fundamental shifted in 2024, and most CTOs haven’t fully processed it yet.

AI-assisted development didn’t eliminate the need for engineering judgment. It did reduce the cost of execution. Translation from intent to code is faster. Iteration cycles are shorter. Large codebases are more legible to machines than to humans. Routine refactoring and dependency management can be automated.

According to McKinsey’s State of AI 2024 report, 65% of organizations now regularly use generative AI in at least one business function, nearly double the percentage from the previous year. And software engineering is one of the top functions where organizations are applying these tools. Research from Microsoft, MIT, and Wharton showed developers using AI coding assistants achieved a 26% increase in productivity. GitHub’s own studies found developers completed tasks 55% faster with AI assistance.

What does this mean in practical terms? The breakeven calculation for custom software has collapsed.

Consider a typical scenario. A team of 50 using a specialized SaaS tool at $50 per seat per month pays $30,000 annually for the privilege of adapting their workflows to someone else’s product decisions. That’s before integration costs, before the consulting fees to customize it, before the productivity losses from features that don’t quite fit.

With AI-assisted development, a purpose-built alternative can now be synthesized in days, not months. The ongoing maintenance that once required dedicated engineering teams can be largely automated through continuous testing, dependency monitoring, and AI-assisted refactoring.

The historical objection, “custom software rots,” assumed maintenance was manual. It assumed you needed humans who understood the system to patch vulnerabilities and update dependencies. That assumption has dissolved.

What I’m Calling Made as a Service

I’ve started using the term “Made as a Service” to describe what’s emerging. MaaS replaces software rental with software stewardship. Customers subscribe not to a static product, but to an ongoing capability: software continuously synthesized, governed, and evolved to match their exact workflows, deployed into infrastructure they control, with full ownership of data and logic.

This isn’t the old “bespoke development” model rebranded. The difference lies in three critical areas.

First, shared foundations. Common logic like authentication, billing, compliance, and audit trails is reused across clients. The wheel isn’t reinvented.

Second, unique orchestration. Workflow logic and interfaces are custom, not templated. The surface is shaped to fit.

Third, continuous stewardship. Evolution is included, not renegotiated. The relationship persists.

Consider one example documented by a Swiss digital consulting firm: an industrial group with 500 users across three subsidiaries opted for a custom solution to centralize quality processes. The initial project cost 600,000 CHF in capital expenditure, followed by 40,000 CHF annually for maintenance. The SaaS alternative would have billed 120 CHF per user per month, totaling nearly 2,160,000 CHF over five years. Beyond the financial gain (total cost of ownership reduced by 70%), the group integrated its own continuous analysis algorithms, boosting quality performance by 15%.

This pattern is emerging across industries. One software development firm reports that a logistics client started with a well-known SaaS tracking tool. After 18 months, they had spent over $40,000 and were still manually exporting data to patch things together. A custom dashboard paid for itself in 14 months and continues to scale with their needs without a rising monthly bill.

The Security Argument Flips

One of the strongest objections to custom software has always been security. “Shared SaaS platforms have dedicated security teams. You can’t match that.”

The argument made sense until the supply chain attacks started.

Shared SaaS platforms create shared blast radius. Every supply chain attack on a major vendor reminds us: millions of customers exposed simultaneously. The Log4j vulnerability. The SolarWinds compromise. The endless parade of breaches at companies whose entire value proposition was handling data securely.

MaaS isolates risk. Smaller attack surfaces. No cross-tenant exposure. Auditable code paths. Explicit threat models. Security improves when responsibility is explicit, not abstracted.

This matters enormously for regulated industries. Healthcare, finance, and government organizations often find compliance is easier to achieve with software designed for specific regulatory requirements than with generic platforms jury-rigged for regulated environments.

Where SaaS Still Wins

I want to be clear about something. SaaS will not disappear. Its domain contracts to areas where structural advantages remain.

Commodity utilities like email, basic document editing, and video conferencing are genuinely universal with no competitive differentiation. Buy these.

Network-effect platforms like LinkedIn, Slack (for cross-company communication), and marketplaces derive their value from the people, not the code. The value is in the network.

Heavy compute applications requiring massive proprietary infrastructure belong in SaaS. Video rendering, large-scale simulation, frontier AI training. These demand infrastructure investment that makes no sense to replicate.

Everything else is vulnerable.

The question to ask yourself: Does this software create competitive differentiation, or is it a commodity? If your company’s secret sauce lives in how you do things differently, forcing those processes into generic SaaS means diluting the very thing that makes you valuable.

The Path Forward

If you’re a CTO looking at this shift, the question isn’t whether to abandon SaaS entirely. That would be foolish. The question is where to start reclaiming sovereignty.

Look at your highest-friction SaaS tools first. The ones requiring the most customization, the most integration work, the most workarounds. Calculate the true total cost of ownership over five years: subscription fees plus integration plus administration plus training plus the productivity losses from workflows that don’t quite fit.

Then ask: could a purpose-built alternative be synthesized for less than this total cost? With AI-assisted development timelines, the answer is increasingly yes for any domain where workflows materially differ across organizations, competitive advantage lives in process, data context matters for AI systems, or integration overhead dominates subscription cost.

The shift from renting software to owning it is not ideological. It is economical. The math has changed. The only question is how long before your organization catches up.

I’ve written a fuller exploration of this transition in what I’m calling “The MaaS Manifesto.” If you want to go deeper on the economics, the technical architecture, and the strategic implications for your organization, you can find it at etiennex.com.

The era of rental is giving way to the era of stewardship. SaaS was software for everyone. MaaS is software made for you.

The transition has begun.

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 “helps a little.”

Sarah leads a 60-person engineering org. When I ask about her EA, she tells me about the project coordinator she shares with two other directors. This person schedules her meetings and sometimes books her travel. Sarah still manages her own inbox, still tracks her own action items, still spends four hours every weekend preparing for the week ahead. She doesn’t have an EA. She has occasional administrative support.

David automated everything. Calendly for scheduling. Zapier for workflow triggers. Notion databases for tracking. Superhuman for email. He spent eight months building the perfect productivity system. He still works 65-hour weeks because software can’t call his CEO’s assistant to negotiate a better meeting time, can’t sense when he needs a buffer day after a board presentation, can’t tell him that the vendor demo he agreed to is a waste of time based on a conversation she had with his head of infrastructure.

Three CTOs. Three versions of the same problem. None of them have what they actually need going into 2026.

The Partnership You’ve Never Experienced

Here’s what I want for every CTO I coach in the coming year: a real executive assistant partnership.

Not a task executor. Not a calendar manager. Not a shared resource. A professional whose entire purpose is making your week work.

I know your brain just went to automation. Mine did too, for years. We’re CTOs. We solve problems with systems. When something is inefficient, we build a better process. When something is repetitive, we script it away.

But here’s what I’ve learned from coaching hundreds of technology leaders: the time problem isn’t a systems problem. It’s a judgment problem. It’s an anticipation problem. It’s a “someone needs to protect you from yourself” problem.

Software doesn’t have judgment. Software can’t look at your calendar and realize that back-to-back-to-back meetings on Thursday will leave you worthless for the board prep you need to do Friday morning. Software can’t tell your product lead that no, you’re not available for a “quick sync” because she knows you’ve been in reactive mode all week and need deep work time. Software can’t read the room.

A skilled EA can.

Why Most CTO-EA Relationships Fail

I’ve watched this pattern play out dozens of times. A CTO hires an EA, gives them tasks, wonders why they still feel overwhelmed, and eventually concludes that having an EA “isn’t worth it” for their working style.

The relationship fails. The CTO goes back to doing everything themselves or automates what they can. Another EA gets hired eighteen months later. The cycle repeats.

I coached a CTO last year who had been through four EAs in three years. Four. He was convinced the problem was finding the “right fit.” During our sessions, I started asking questions about how he worked with each of them.

He approved every expense before they could submit it. He wanted to see every email before it went out under his name. He provided detailed instructions for tasks and then revised the output because it wasn’t quite how he would have done it. He kept his own calendar “just in case” and often scheduled meetings directly, creating conflicts his EA would have to untangle.

He didn’t have an EA relationship. He had a very expensive mirror.

The warning signs are consistent across almost every failed EA partnership I’ve seen:

You review everything. If you’re checking every calendar invitation, every email draft, every expense report, you’re not delegating. You’re creating a approval bottleneck with extra steps.

You provide solutions, not outcomes. There’s a difference between “I need you to call the Marriott and book the corner room on the third floor” and “I need a quiet room for focused work during the conference.” The first is task execution. The second allows for judgment.

You feel the need to explain every decision they’ve made. When your EA moves a meeting, do you ask why? When they decline something on your behalf, do you need a debrief? That’s not partnership. That’s surveillance.

Your EA asks permission for everything. This one cuts both ways. If they’re asking before every action, either you’ve trained them to be afraid of your reaction, or they don’t have the context to make decisions. Both are your responsibility to fix.

You secretly keep your own systems. A shadow calendar. A private task list. A personal inbox triage. If you’re duplicating their work “just to be safe,” you’ve signaled that you don’t trust the partnership.

The Joy You’re Missing

I want to talk about something that doesn’t get discussed enough: the joy of this partnership when it works.

There’s a CTO I’ve been coaching for two years. When she first came to me, she was classic startup-scale burnout. Sixty-plus hours a week, constantly in reactive mode, couldn’t remember the last time she had a week that felt like her own.

Six months into our work together, she hired an EA. Not a part-time admin. A professional who had supported C-suite executives for fifteen years.

The first three months were rough. She fought every instinct to control. She bit her tongue when meetings got rescheduled without her input. She felt anxious not knowing exactly what was on her calendar until she looked at it in the morning.

And then something shifted.

She told me about a Thursday when she walked into the office and realized she had two hours blocked for thinking. She hadn’t asked for it. Her EA had noticed the pattern—noticed that she was sharper in meetings when she had prep time, noticed that her Thursdays had become a gauntlet of back-to-backs, and made a decision.

She told me about a conference where her EA had booked her a hotel room on a different floor from the rest of her team. She was initially annoyed until she realized it meant she could actually rest between sessions instead of fielding hallway conversations.

She told me about the vendor meeting that never happened. A sales pitch her EA declined on her behalf because “it didn’t align with your current priorities.” The vendor had gone around her EA to email her directly. Her EA intercepted it, responded professionally, and she never had to spend a calorie on it.

She told me about something else too. Something that surprised her. She started using her EA as a sounding board before difficult conversations. A quick five minutes to vent about a frustrating product decision before walking into the executive meeting. A chance to process her irritation about a missed deadline before her 1:1 with the engineering manager responsible. Her EA became the person who absorbed the emotional weight so she could walk into rooms clear-headed.

And there’s a simpler joy too. The relief of saying “I need Friday afternoon free” and having that be someone else’s problem to solve. Not your problem. Not a puzzle you have to untangle between meetings. Just a statement of what you need, handed off to someone whose job is to make it happen.

That’s not task management. That’s someone thinking about her week more strategically than she has time to think about it herself.

That’s joy.

The Rules of Engagement

If you’ve never had a real EA partnership, there are things you need to understand going in.

The math works in your favor. Dan Martell, in his book Buy Back Your Time, offers a simple formula: take your annual income, divide by 2,000 working hours to get your effective hourly rate, then divide by four. That’s your “Buyback Rate”—the threshold below which you should be paying someone else to do the work. If you’re a CTO earning $400,000, your effective rate is $200/hour. Your buyback rate is $50/hour. Every hour a skilled EA works on your behalf at $75/hour creates $125 in recovered value.

Now think about what that means for you specifically. Every hour you spend on calendar management, expense reports, travel logistics, or inbox triage is an hour you’re not spending on technical strategy, coaching your engineering leaders, aligning with your CEO on product direction, or recruiting that senior architect you desperately need. The EA doesn’t just give you time back. They give you back the right time, the hours you should be spending on the work that only you can do.

You are hiring judgment, not labor. A professional EA isn’t expensive because they can manage calendars. They’re expensive because they can anticipate, prioritize, and protect. You’re paying for the meeting that never got scheduled, the email you never had to write, the decision you never had to make.

Decisions will be made that you don’t understand. This is the hardest part for CTOs. We like to understand systems. We like to know why things work the way they work. In a real EA partnership, you have to accept that sometimes a meeting moves and you don’t know why, and that’s okay. You hired judgment. Let it work.

You cannot control the outcome. If you’re specifying exactly how every task should be done, you’re not getting the value of partnership. You’re getting task execution at partnership prices. Define outcomes. Define boundaries. Then get out of the way.

It takes longer than you think. A real EA partnership takes 6-12 months to mature. The first 90 days are about building context. The next 90 are about building trust. After that, you start to see the leverage. If you’re evaluating at 60 days, you’re measuring the wrong thing.

This is not a part-time job. I cannot stress this enough. A shared admin resource, a project coordinator who “also does EA stuff,” a part-time contractor who manages your calendar—these are not EA partnerships. They might be useful. They are not the same thing. A professional EA needs to be in your context full-time to build the judgment that makes the partnership valuable.

Your 2026 Resolution

Going into the new year, I want you to consider that you might be the reason you don’t have the support you need.

Not because you’re bad at your job. Because you’re too good at it. You’ve survived this long by being the person who handles everything, knows everything, controls everything. That’s how you got here.

It’s also what’s keeping you stuck.

According to a ServiceNow State of Work report, executives spend an average of 16 hours per week on manual administrative work. The equivalent of two full days every week. A Unit4 study across 11 countries found that office workers lose roughly one-third of their working year to administrative and repetitive tasks. That’s 69 work days annually, gone. And research consistently shows that a skilled EA can reclaim 15-20% of an executive’s working hours.

But “skilled EA” is doing a lot of work in that sentence. Most executives don’t have one.

So here’s what I want you to do.

Start by asking yourself an honest question: do you actually want a partner, or do you want an assistant? If the answer is assistant, someone to execute tasks you’ve defined, fine. But stop wondering why you’re still exhausted.

If you want a partner, start with trust. Not trust that’s earned over months of proving competence. Trust that’s given because you’ve decided to give it. Trust that says “I’m hiring you to make decisions about my time, and I’m going to let you make them.”

Find someone who has done this before. A professional EA is not an entry-level role. You want someone who has supported executives, who understands the pace and complexity of C-suite life, who has developed the judgment to know when to protect you and when to push back.

Then give it time. Real time. Not 60 days. Not 90 days. At least six months before you evaluate whether the partnership is working.

And when they make a decision you don’t understand, resist the urge to ask why. Resist the urge to “provide feedback.” Just notice. Notice whether your week worked. Notice whether you had the time you needed. Notice whether you felt protected.

Because that’s what a real EA partnership gives you. Not just time. Protection. Anticipation. Someone whose entire professional purpose is making your week work so you can make your company work.

That’s my wish for you in 2026. Not another productivity system. Not another automation tool. A partner.

I know many brilliant EAs—professionals who have transformed the working lives of the CTOs I coach. If you want help finding your perfect match, send me an email at etienne@7ctos.com.

It might be the most important introduction I ever make.

“Walk me through what happened in your last planning meeting,” I say.

The CTO exhales. “The CEO presented the annual target. $23 million in revenue. Everyone nodded. Then she asked for the plan to get there, and the room just... fragmented.”

He describes the scene. The COO wanted more aggressive outbound. Sales wanted better product differentiation. Marketing wanted to double down on content. Finance wanted operational efficiency. Every suggestion reasonable. None of them connected.

“And where did that leave you?” I ask.

“Nowhere. I still don’t know what to build. Every feature request feels equally important because we never decided what actually matters.”

I turn to the whiteboard and write a single question: How much of that $23 million do you already have locked in?

The CFO in the room pulls up a spreadsheet on her laptop. Contracted renewals. High-probability deals. After ten minutes of calculation, we have an answer: $17 million is essentially guaranteed. Another $3 million is probable from the existing pipeline.

“So you’re not solving for $23 million,” I say. “You’re solving for a $3 million gap.”

I watch the tension in the room shift. A $23 million target feels abstract, almost oppressive. A $3 million gap feels like a problem with a solution.

Over the next two hours, I facilitate a conversation that transforms their revenue target into three specific business objectives. By the end, the CTO finally has what he needs: clarity on what the company is betting on, what they’re deliberately not pursuing, and how his technology organization will drive the outcomes.

This is the work that separates CTOs who are seen as cost centers from CTOs who are seen as strategic partners. And it’s the work that has to happen before you can build a technology roadmap that means anything.

The Translation Problem

Revenue targets are not business objectives. A target like “grow revenue by 20%” tells you where to go, but not how to get there. Business objectives are the strategic bets your company makes to reach that destination.

Most C-Suites skip this translation step entirely. They hand technology teams a financial target and expect magic. The consequences cascade through the organization: initiatives multiply without prioritization, resources spread thin across competing interpretations of “what matters,” and year-end retrospectives devolve into debates about what “success” even meant.

A 2023 study by Bridges Business Consultancy found that 67% of well-formulated strategies fail due to poor execution. But the problem often starts earlier. You can’t execute a strategy that was never translated into actionable objectives in the first place.

The CTO sits at a unique intersection. Deep visibility into technical capabilities. Understanding of business constraints. Access to data that reveals customer behavior, system performance, and operational bottlenecks. This position makes the CTO the natural facilitator for the conversation that transforms targets into objectives.

Five Levers, Not Fifty Ideas

Every revenue target is achieved through one or more of five fundamental levers. Understanding these levers is the first act of strategic discipline.

Acquire — Bring in new customers who weren’t buying before. Land new logos. Enter new segments.

Retain — Keep existing customers from leaving. Reduce churn. Increase renewal rates.

Expand — Grow revenue from existing customers through upsells, cross-sells, and increased usage.

Price — Increase pricing on existing offerings. Capture more value from what you already deliver.

Enter — Access new markets, whether geographic, vertical, or product-based.

Most companies cannot effectively pursue more than two or three of these levers simultaneously. If your executive team claims all five are priorities, you don’t have a strategy. You have a wish list.

In that CTO Compass session, we identified the primary lever as Expand (grow existing accounts) and the secondary lever as Acquire (new enterprise logos). The constraint of an EBITDA target meant they couldn’t just throw resources at growth. They needed efficiency improvements alongside revenue expansion.

This clarity eliminated dozens of potential initiatives before we even started discussing them. The CTO visibly relaxed. For the first time in months, he could see a path forward.

The Five-Phase Facilitation Process

Here’s the process I use to guide C-Suite conversations from revenue targets to actionable objectives. Each phase builds on the previous one, and skipping phases leads to objectives that fall apart under scrutiny.

Phase 1: Establish the Gap

Before discussing strategy, everyone must understand the mathematical reality. This grounds the conversation in facts rather than aspirations.

Ask these questions:

• What is our current run rate, and what does the target require?

• What revenue do we have locked in through contracts or high-probability renewals?

• What’s our current pipeline, and how much is realistic to close?

• What gap remains after accounting for the probable?

In our session, the target was $23 million. Contracted revenue was $17 million. Probable pipeline was $3 million. The actual problem we needed to solve was a $3 million gap. This reframing made the impossible feel achievable.

Phase 2: Identify the Levers

With the gap defined, determine which revenue levers offer the best opportunity to close it.

Ask these questions:

• Of the five levers, which one or two represent our best opportunities this year?

• Where are we currently strongest? Where are we leaving money on the table?

• What did we try last year, and what worked?

• What constraints eliminate certain levers from consideration?

Watch for warning signs. If no one can articulate why one lever is better than another, you need more data. If the chosen levers change every meeting, you have an alignment problem, not a strategy problem.

Phase 3: Surface the Obstacles

If pulling a lever were easy, you’d already be doing it. Understanding what’s blocking progress reveals where objectives must focus.

Ask these questions:

• If this lever is so promising, why aren’t we already pulling it harder?

• What would have to be true for us to succeed with this lever?

• What are we missing—capabilities, resources, information, alignment?

• Where do deals get stuck? Where do customers leave? Where does value leak?

For the Expand lever in our session, the obstacles were clear: existing customers didn’t know about add-on products, account management was reactive rather than proactive, and there was no visibility into usage patterns that indicated expansion readiness.

For the Acquire lever: long sales cycles, extensive custom implementation requirements, and a small sales team.

These obstacles pointed directly to where the objectives needed to focus.

Phase 4: Formulate the Objectives

Now synthesize the lever choice and obstacle analysis into three clear business objectives. Each objective should be specific enough to guide action but broad enough to allow creative solutions.

Use this formula: [Action verb] + [Specific outcome] + [For whom/what] + [Measurable target]

Compare these:

• Weak: “Grow revenue”

• Better: “Acquire new customers”

• Best: “Land 10 new enterprise healthcare accounts representing $500K in annual recurring revenue”

Why three objectives? Research on cognitive load and organizational behavior consistently shows that more than three strategic priorities creates dilution rather than ambition. Three objectives allow for depth of execution while maintaining strategic coherence. Richard Rumelt’s work on strategy in “Good Strategy Bad Strategy” emphasizes that focus is the essence of strategy—spreading attention across too many objectives guarantees mediocrity in all of them.

The three objectives from our session became:

1. Increase platform seat count within existing accounts by 30%, generating $3M in expansion revenue

2. Land 5 new enterprise accounts representing an additional $3M in first-year revenue

3. Reduce services delivery cost by 20% through productization and automation

Phase 5: Validate and Commit

Before finalizing objectives, stress-test them against reality.

Ask these questions:

• If we accomplish these three objectives, will we hit our revenue target?

• Do we have—or can we acquire—the resources to pursue all three?

• Are these objectives within our control, or dependent on external factors?

• Can we measure progress monthly or quarterly?

• Is everyone in this room willing to make trade-offs to achieve these?

The commitment step is operational, not ceremonial. Document the objectives, the owners, and the timeline. Make explicit what will NOT be pursued as a consequence of these choices.

Earning the Right to Facilitate

I can already hear the objection: “This assumes I have permission to lead this conversation.”

Fair. Many CTOs weren’t hired to run strategy sessions. They were hired to ship software. Walking into a planning meeting and asking “How much of that $23 million do we have locked in?” could land as presumptuous. Out of lane. The CEO views strategy as their domain. The CTO’s job is to execute.

If that’s your situation, you don’t start by facilitating the whole C-Suite. You start smaller.

Start with the problem, not the process. Go to your CEO with the symptom: “I’m getting conflicting priorities from different stakeholders, and I need help understanding which initiatives actually matter for hitting our number.” You’re not claiming strategic authority. You’re asking for clarity so you can do your job.

Bring data as your entry point. The CTO has access to information no one else sees. Customer usage patterns. Feature adoption rates. Support ticket trends. Churn indicators. When you surface an insight like “Customers who complete onboarding within 48 hours retain at 3x the rate,” you’ve earned a seat in the strategy conversation because you brought something valuable.

Propose a working session, not a takeover. Instead of announcing that you’ll facilitate quarterly planning, suggest: “Would it help if I pulled together some data and we spent an hour pressure-testing our assumptions about next year?” Frame yourself as a resource, not a rival.

Document what you hear. After any planning conversation, send a follow-up: “Here’s what I understood our three priorities to be. Am I tracking this correctly?” If no one corrects you, you’ve just created the clarity that didn’t exist before. If they do correct you, you’ve surfaced a disagreement that needed surfacing.

The goal isn’t to seize control of strategy. The goal is to be so useful in clarifying strategy that people start expecting you in the room.

When the Room Won’t Align

The five-phase process reads as linear and rational. Real C-Suites are not.

Executive teams are full of competing agendas, protected budgets, and information people aren’t sharing. What happens when the CFO and Head of Sales fundamentally disagree on which lever to pull? What happens when the CEO has already made up their mind and this “facilitation” is theater? What happens when someone in the room is actively working against alignment because clarity threatens their position?

Name the disagreement explicitly. When two executives are advocating for different levers, don’t let the conversation drift. Say: “It sounds like we have two different hypotheses here. Sarah thinks retention is our best opportunity. James thinks acquisition is. Can we look at the data that would tell us which is right?” Force the debate into the open where it can be resolved, rather than letting it fester as passive resistance.

Identify who owns the decision. Not every strategic choice is democratic. Sometimes the CEO decides, full stop. If that’s the case, your job shifts from facilitating consensus to ensuring the CEO has the information needed to decide well. “I want to make sure you have visibility into the technical implications of each path before you choose.”

Watch for the pocket veto. Some executives agree in the room and undermine in the hallway. The best defense is specificity. Vague objectives are easy to reinterpret. “Grow the customer base” can mean anything. “Land 5 new enterprise accounts representing $3M in first-year revenue” is harder to quietly redirect. The more specific the objective, the harder it is to claim you’re pursuing it while actually doing something else.

Accept that perfect alignment is rare. Your goal isn’t unanimous enthusiasm. Your goal is enough clarity that you can build a roadmap and defend your prioritization decisions. If the Head of Sales is still grumbling about not getting their pet feature, that’s fine—as long as the CEO has committed to the objectives and you have that commitment in writing.

When Q2 Blows Up Your Plan

Even if you get three perfect objectives defined and committed, business conditions shift. A key customer churns. A competitor launches something unexpected. The board changes their mind. Six weeks later, the CEO walks in and says “we’re pivoting.”

This is not a failure of the process. This is reality. The question is whether you have a foundation to work from when things change.

Objectives are more stable than tactics. When conditions shift, the first question is: “Do our objectives still hold, or do the objectives themselves need to change?” Often, the objectives remain valid even when the actions underneath them need adjustment. “Land 5 new enterprise accounts” might still be the right objective even if your original approach isn’t working. The pivot is in how you pursue the objective, not whether you pursue it.

Re-run the gap analysis. If a major customer churns or a big deal falls through, the math has changed. Go back to Phase 1. What’s the new gap? Does the size of the gap change which levers make sense? A 15-minute recalculation can prevent months of misdirected effort.

Protect the process, not the plan. The value of this framework isn’t that it produces a perfect plan. The value is that it gives you a shared language for adapting when things change. When the CEO says “we need to pivot,” you can respond: “Okay, let’s revisit our gap calculation and see which lever gives us the best shot at closing it now.” You’re not starting from scratch. You’re updating the model.

Document the change. When objectives shift mid-year, write it down. “As of June 1, we’re deprioritizing Objective 2 and reallocating resources to Objective 1 because of X.” This protects you at year-end when someone asks why you didn’t deliver on the original plan. It also forces the decision-makers to own the pivot rather than pretending it never happened.

The companies that struggle most aren’t the ones that have to adapt. They’re the ones that never had clarity in the first place, so every shift feels like chaos rather than a recalibration.

Why the CTO Leads This Conversation

The CTO brings four capabilities to this facilitation that no one else in the room possesses.

Data visibility. The CTO sees patterns others miss: user behavior analytics, system performance metrics, support ticket trends, feature adoption rates. In our session, the CTO knew that customers who completed onboarding within 48 hours had 3x the retention rate. That data point shaped which obstacles we prioritized.

Possibility awareness. The CTO knows what technology can enable. While others debate strategy in the abstract, the CTO can inject feasibility and timeline reality. “We could launch a free tier within 8 weeks, but European localization would take two quarters. That changes which objectives are achievable this year.”

Constraint transparency. The CTO understands technical debt, infrastructure limitations, and team capacity in ways that affect what’s realistic. Their payment infrastructure didn’t support the pricing model someone proposed. Knowing that constraint saved them from committing to an objective they couldn’t deliver.

Translation capability. The CTO bridges business intent and technical execution. Well-formed objectives emerge from the ability to translate business language into actionable terms and back again.

From Objectives to Actions

Once the three objectives were defined, the CTO could finally do what he’d been trying to do for three months: build a technology roadmap that connected to business outcomes.

Each objective spawned specific actions. Objective 1 (expansion revenue) required implementing customer health scoring, building an expansion recommendation engine, ensuring usage data privacy compliance, and creating an account manager enablement dashboard.

Objective 2 (new enterprise accounts) required accelerating implementation timelines, developing self-service onboarding, completing SOC 2 certification, and building an interactive demo environment.

Objective 3 (services efficiency) required automating data integration workflows, developing reusable configuration templates, documenting proprietary methods, and creating a services-to-platform migration path.

Without clear objectives, a technology roadmap is just a list of features someone asked for. With clear objectives, every item on that roadmap has a reason to exist and a way to measure its impact.

Your Next Planning Conversation

Before the meeting, prepare the math. Calculate the gap between current state and target. Pull relevant analytics on customer behavior, feature adoption, and churn patterns. Have informal conversations with key executives to understand their perspectives. Come with potential objectives to react to, not a blank slate.

During the meeting, start with agreement on the numbers. Use the whiteboard to make thinking visible. Draw the gap, the levers, the obstacles, the objectives. Name the trade-offs explicitly: “If we pursue X, we’re choosing not to pursue Y. Are we aligned on that?”

Inject technical reality gently. “That’s achievable if...” works better than “We can’t do that.” Summarize relentlessly: “So what I’m hearing is... Is that right?”

After the meeting, document the objectives in writing within 24 hours. Circulate for confirmation. Begin translating objectives into specific technology actions. Schedule the first progress check-in.

The first time you facilitate this conversation successfully, you’ll feel the shift in how your C-Suite perceives you. You’re no longer the person who explains why things take so long. You’re the person who helped the company figure out what actually matters.

Revenue targets are destinations. Business objectives are the strategic bets that get you there. The CTO who masters this translation becomes indispensable.

Learn This Framework in Depth

If you want to experience this process firsthand and learn how to facilitate these conversations with your own C-Suite, join us at the next CTO Compass workshop. We work through real scenarios, practice the facilitation techniques, and build the artifacts you’ll take back to your organization.

Register at ctocompass.com/7ctos

What business objectives is your company betting on this year? If you can’t name three, you have work to do before your next planning session.

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 look promising. I can see the enthusiasm spreading across the table like a contagion.

And I open my mouth and say, “That’s a dumb idea.”

I elaborate. Why would we spend eighteen months and millions of dollars rebuilding a platform that has been built over and over again by companies with far more resources than us? Amazon, Akamai, Cloudflare. They’ve poured billions into solving this exact problem. Our competitive advantage isn’t in content distribution. It’s in the product itself. And the product has deficits. Real deficits that customers are complaining about. Deficits that are costing us renewals.

I’m making perfect sense. I’m technically correct. I can see it in their eyes that they know I’m right.

They fire me a few weeks later.

The Chief Translation Officer

I’ve spent years thinking about that meeting. Not because I was wrong. I wasn’t. The company eventually abandoned the CDN project after spending significant resources on it. But I’ve come to understand something that would have saved my job and served my company far better: the CTO’s primary function is not to be right. It’s to translate.

Translate business objectives into technology action. Translate technology progress back to the C-Suite. Translate complexity into clarity. Translate technical reality into business language.

I wasn’t a Chief Technology Officer in that meeting. I was a Chief Correction Officer. And no one wants to be corrected, especially not by someone who reports to them.

According to research from Netskope’s 2024 report “Crucial Conversations,” 39% of CIOs say they are misaligned with their CEO on key decision-making. More troubling, 34% of CIOs report they do not feel empowered to make long-term strategic calls. And 31% are not confident they know what their CEO really wants.

These numbers don’t describe a technical problem. They describe a translation problem.

The 28-Point Collapse

Capgemini has been measuring business-IT alignment for over a decade. In 2012, 65% of senior executives believed business and IT leaders agreed on IT’s role within the organization. By 2024, that number had plummeted to just 37%.

A 28-point collapse in alignment over twelve years.

This collapse happened while organizations poured trillions into technology investments. It happened while “digital transformation” became mandatory vocabulary in every boardroom. It happened while every company claimed that technology was central to their competitive advantage.

The investment went up. The alignment went down.

Why? Because technology leaders kept speaking technology language to business audiences. We kept producing status reports that no one read. We kept explaining complexity instead of showing progress. We kept being technically correct while being strategically invisible.

Showing Complex Work Simply

After years of wrestling with this translation problem, both in my own career and coaching hundreds of CTOs through 7CTOs, I developed what I call the CTO Compass. It’s built on a simple premise: visual indicators work better than text-heavy reports.

The framework uses four domains we call CTO Sentinel: Speed (delivery velocity), Stretch (future capabilities), Shield (organizational protection), and Sales (cross-functional enablement). Every technology initiative maps against all four.

But the real power isn’t in the categories. It’s in the colors.

Green means on track. Yellow means caution. Red means roadblock. Blue means complete.

One glance tells the entire story. No lengthy explanations required. No translation needed. The CEO looks at the grid and understands immediately where things stand.

When I think back to that 2018 meeting, I realize I had no visual language to share. I had opinions. I had arguments. I had technical correctness. But I had no way to show my executives the landscape of technology decisions in a format they could grasp instantly.

If I had been able to show them a grid, here’s where we’re green, here’s where we’re yellow, here’s the red that will turn green if we focus resources here instead of building a CDN, the conversation would have been entirely different.

Transparency Builds Trust

Peter Yared, former CIO/CTO at CBS Interactive, observes: “There’s always been a lack of transparency in IT. As costs start to creep up, that creates a lot of dissatisfaction and then people don’t spend what they should. A lot of this can get fixed with greater transparency.”

The CTO Compass philosophy holds that transparency builds trust. Yellow and red statuses aren’t failures—they’re demonstrations of proactive leadership. They show executives that you see the problems before they become crises. They invite conversation rather than shutting it down.

When I called my CEO’s idea “dumb,” I shut down conversation. I created an adversary instead of a partner. I demonstrated my intelligence while destroying my influence.

A visual framework changes the dynamic entirely. Instead of “your idea is dumb,” it becomes “let me show you how this initiative would affect our other priorities.” Instead of correction, it becomes exploration. Instead of winning an argument, it becomes building understanding.

The Standish Group found that organizations with “high decision latency”, meaning slow, uncertain decisions due to poor strategic alignment, achieve only an 18% project success rate. Organizations where teams understand why their work matters hit 63%.

That 45-percentage-point gap isn’t about technical capability. It’s about shared understanding. It’s about translation.

The Grid That Could Have Saved My Job

Looking back at 2018 with what I know now, I can see exactly what I should have done.

I should have mapped the CDN initiative against the four Sentinels. Under Speed: eighteen months of development before any value delivery. Under Stretch: new capabilities our team would need to build and maintain indefinitely. Under Shield: security and compliance requirements for handling video distribution at scale. Under Sales: zero customer-facing benefit until completion, while existing product deficits continued costing renewals.

Then I should have shown the alternative. Focus those same resources on product improvements. Under Speed: incremental value delivery starting in weeks. Under Stretch: building on existing capabilities. Under Shield: addressing known vulnerabilities in current systems. Under Sales: immediate impact on customer satisfaction and retention.

Same technical analysis. Completely different presentation. Visual. Comparative. Inviting discussion rather than demanding agreement.

Would they have made a different decision? Maybe. Maybe not. But I wouldn’t have been fired for the way I communicated. And I would have built trust for the next difficult conversation instead of destroying it.

The Flight Risk

Russell Reynolds Associates found that 74% of technology officers expressed interest in making a career move in the second half of 2024, up dramatically from 50% in 2022.

Three quarters of technology leaders are looking to leave their positions. The research attributes this to “the growing gap between ambition and organizational readiness.” Technology leaders feel confident leading transformation but face internal barriers including limited cross-functional support and unclear or shifting mandates.

Technology leaders aren’t leaving because they can’t do the work. They’re leaving because they can’t get their organizations to understand the work. They’re leaving because translation has failed.

The CTO Compass addresses this directly. When you can show complex work simplylike when executives can glance at a grid and understand progress, challenges, and dependencies, the gap between ambition and readiness starts to close. You’re no longer fighting for understanding. You’re building it, visually, every month.

Your Monday Morning

If you’re a CTO who has ever been technically correct but strategically ignored, you know the frustration I felt in 2018. You know the helplessness of watching bad decisions get made while your expertise goes unheard.

The answer isn’t to argue more forcefully. It isn’t to produce longer reports or more detailed analyses. The answer is to translate—to show complex work simply, to use visual language that creates immediate comprehension, to build trust through transparency rather than eroding it through confrontation.

I’m running a CTO Compass workshop in January where I’ll walk through exactly how to build this translation capability. How to map your initiatives against the four Sentinels. How to use color-coding to create instant understanding. How to turn your next executive update from a status report into a strategic conversation.

You can register at ctocompass.com/7ctos

I lost my job in 2018 because I confused being right with being understood. They’re not the same thing. They never have been. And the sooner you build the translation skills to bridge that gap, the more valuable you become.

Not just as a technologist, but as a leader.

Read more

The impact went beyond feelings: 86.5% …

Read more

Read more

Line 10: PRINT “What’s your name?”
Line 20: INPUT NAME
Line 30: PRINT “Hello, “ …

Read more

“Tell me what happened,” she says.

I launch into it. The dishwasher. How loading it became World War III. How a simple conversation about whether glasses go on the top or bottom rack escalated into us retreating to separ…

Read more

Over fifty years later, we’re still using that same paradi…

Read more

Read more