On October 4, 2026, I was working through how several trusty-mpm sessions, run by different people on different machines, could share engineering project memory. Each machine runs its own trusty-memory daemon. What one session remembers stays on that machine, even when another person is working on the same project.

I organize memories into palaces, rooms and drawers. That works fairly well for me. The Rust implementation saves memories quickly, and an August measurement against a live daemon put recall at about 1.2 milliseconds.

I wanted the next collaborator to have some of the context behind the work. The tickets and specs were already there. The conversation that produced them might be somewhere else.

My first proposal was to classify memories as shareable, rank them by accuracy and usefulness, and push the eligible ones to a cloud store. Keep the name of whoever originated each memory. Codex separated permission to share from quality: a useful memory could still be private. I agreed, then moved away from requiring one central store. I wanted an interoperable API, with clients able to subscribe to several backends. A mesh.

Recall would stay local. A background connector would sync permitted memories, and the scope would be engineering project work. That was the proposed design on October 4. The system I had built supported local memory and recall, with background consolidation. The shared mesh was still a design discussion.

Then I raised a different requirement: memory should not become another copy of the tickets, requirements and specifications. I wanted it to preserve expressed intent as it evolved, including the reasons a person changed direction.

That puts a fairly demanding job on memory. My own system already had trouble telling an old fact from a current one.

TL;DR

• I want shared memory to preserve how intent develops, with links to the tickets and documents that hold the current decisions.

• My August logs showed a stale checkpoint reaching 44.8% of turns. Sharing that memory would spread the problem.

• I want dreaming to prepare memories before they enter a shared store, connecting related records and flagging conflicts. Permission to share remains a separate decision.

• ADRs already preserve rationale and can hold tentative decisions. A separate memory store has to earn its place alongside them.

• Agent capture leaves a human review cost. I haven’t shown that the recovered context is worth that cost.

One Fact, One Home

The working rule I arrived at with Codex is that a fact should have an authoritative home. Other places can refer to it, but I don’t want several systems maintaining competing answers.

A ticket owns the work’s status and assignee. Requirements state agreed outcomes and constraints. A product requirements document (PRD) explains the product case, while a spec describes intended behavior. An architecture decision record (ADR) holds a decision and its rationale, including alternatives. Search helps find the evidence across those artifacts.

Memory’s job, as I see it, is to preserve the path around them: what someone was trying to accomplish, how that changed, and what remained unsettled. Once that intent becomes a requirement or a decision, memory should link to the result. The requirement gets maintained in the requirements document.

There’s overlap. A spec can explain why. An issue discussion can contain a change of mind. My rule concerns which version gets maintained.

The conversation on October 4 contains the kind of movement I want to keep. I started with a cloud store, accepted a distinction between permission and quality, then changed the design to allow several backends. I narrowed its scope to engineering projects. Later I questioned what belonged in the system at all. A finished API spec could describe the resulting design without preserving those earlier framings or their sequence.

I asked for a position paper, then put it on hold and asked for this article first. I wanted to use the writing to work out the boundaries before treating them as requirements.

Stale Memory Gets Believed

In August, ADR-0028 in trusty-tools examined my memory-injection logs from July 5 through August 4. The most frequently injected memory was a July 16 checkpoint announcing that a merge train was complete. It appeared in 3,612 of 8,063 trusty-tools turns, or 44.8%. By the end of the measurement period, it was 19 days old.

The fifteen most frequently injected memories were expired checkpoints. Another pinned origin/main to a commit hash that had been wrong for four weeks, then supplied it in about one turn in five.

Recall used a 90-day decay half-life. A PR’s current head can change in hours. The checkpoint was a record of something that happened, but recall kept handing it back as useful context for current work.

Retrieval accuracy is about finding the memory that fits the request. The accuracy of that memory’s contents is another question. A system can return a relevant record faithfully even when the information is outdated or wrong. My checkpoint still described a completed merge train, but it couldn’t establish the current state of the work. That’s why I need dreaming to examine relationships between records, including corrections and contradictions, before I treat recalled material as useful shared context.

Corrections existed. Following them was another problem. Of 109 hand-written links saying one memory superseded or corrected another, only 45 resolved to a memory ID. The rest used labels the machine couldn’t follow. In one case, a rebase made a remembered PR head stale. The correction was in memory, but the old memory had no usable link to it.

Since August 5, the system has supported named fact slots through fact_key. Writing a new fact to an occupied slot retires the previous occupant and links it to the replacement. The older fact remains in history. That gives the machine a way to follow a correction instead of hoping it can interpret a hand-written note.

It also leaves me with a question about what belongs in the slot. The ADR’s example is a PR’s status at a particular head commit. GitHub already has that information. I can make a copy age more carefully, but I still have a copy to maintain.

Keep the Transition and Its Reason

Memory shows intent through its transitions.

I want to know what the person meant at one point, what they meant later, and why they moved. The ticket or PR can tell me the current status.

The fact slots have part of the direction I’m heading: earlier records survive, linked to their replacements. But a replacement link says what followed a fact. It doesn’t explain why the person changed their mind. Filling that history with successive copies of GitHub status would preserve a sequence without necessarily preserving intent.

My system also has task records for goals and checkpoints, including whether they’re complete. A goal expressed before a ticket exists could be useful memory. Once a ticket tracks the work, maintaining another open-or-done field creates another place to fall behind.

So the proposed rule would change how parts of my own system are used. I haven’t settled whether those records should become links with history attached, remain useful within a session, or move out of memory.

The July checkpoint is a reason to be careful. It was useful as a dated record that a merge train had completed. Its repeated appearance weeks later didn’t tell the next session what had changed since.

Dreaming Before Sharing

I need a dream cycle between raw capture and shared memory. A conversation leaves observations and half-formed ideas alongside decisions that may already have changed. Before another person relies on that material, I want it organized into a useful account of the thinking. For this shared-memory design, I consider dreaming an essential step.

I want the pass to recognize repeated accounts of the same intent, connect a later correction to an earlier assumption, and preserve why the thought changed. A collaborator should be able to find the correction alongside what it corrected. They should also be able to recover which parts of the earlier reasoning survived. Consolidation would help someone follow that development without piecing it together from scattered session records.

The human analogy is suggestive. In a 2010 study by Erin Wamsley and colleagues, people who reported dreaming about a virtual maze during a nap improved more on the task afterward. The association links dreaming with processing recent experience, without establishing that the dreams caused the improvement or were necessary for memory.

With its model backend and consolidation enabled, my software’s dream cycle can merge overlapping memories while retaining the originals and links to their replacement. It flags contradictions for human review. Those capabilities give me a starting point for preparing memory while preserving its history.

I want the proposed shared store to accept only memories that have been through dreaming. The pass would prepare records for reuse, with their sources and unresolved disagreements still visible. It doesn’t establish truth or grant permission to share: repeated assertions can still be wrong, and useful memories can still be private. But I want the work of connecting and sorting them to happen before they reach another person’s session. That person should get a record they can examine and follow back to its origins.

The ADR Objection

Michael Nygard’s description of ADRs, published in 2011, starts with the difficulty of tracking the motivation behind decisions. His format records context, decision, status and consequences. MADR includes considered options and their pros and cons, with a proposed status for decisions still under discussion.

That is much of what I’m asking memory to preserve, but not just the ADR but the thinking that led to it.

I use ADRs in trusty-tools. The one behind the stale-memory measurements records rejected alternatives and open limits as well as the decision. It is evidence against claiming formal documents can’t do this job. An ADR can start early, and the discussions linked to it can preserve the thinking around it.

What I want to capture is the thinking that happens before someone writes an ADR, or in the working conversation around it. A framing gets dropped before it becomes a considered option. A person gives a reason in passing. If that reason belongs in the adopted decision, it should make its way into the ADR. Memory might help it survive long enough to get there.

But a good ADR, linked discussion and search may already be sufficient. The distinction I’m proposing is about when and how context gets captured. It doesn’t establish that I need a separate store. I’m going on faith to some degree because I have been so successful using search and memory -- search covering all the static documents and memory covering the transitions.

Nor is the idea new. Jeff Conklin’s Designing Organizational Memory, first written in 1997 and revised in 2001, distinguishes formal results from the informal knowledge created while producing them. That includes assumptions and questions, along with the reasons behind choices. My evolving-intent argument fits within his project memory.

Jintae Lee’s 1997 survey of design-rationale systems even describes an apprentice approach: a system observes the designer’s work and asks questions to capture the rationale. An agent in a coding session looks a lot like that apprentice. Whether it makes capture cheap enough is still a question.

What I Would Ask Memory to Keep

Codex derived a set of proposed requirements from the October 4 conversation. They would have a record identify the person and project, preserve what the person expressed, and link to the relevant issue or document version. Assistant synthesis would be labeled separately. A tentative preference would remain distinguishable from an explicit decision or a later correction. When the intent becomes a ticket, spec change or ADR, memory would link to that artifact and record the transition. It would retrieve current work status from the system responsible for it. These are design proposals from Codex, still to be worked through.

I care about the conditions around a choice as much as the choice itself. Which alternatives were considered? What remains open? What would change the decision? Those were part of the proposed evaluation: can another collaborator recover the reasoning and its limits?

A timestamp and an author give that collaborator somewhere to start. They don’t reproduce the conversation. The more tentative the thought, the more its meaning can depend on context that a short memory record leaves out. Sharing a record between people makes that harder than recalling it for the person who wrote it.

The stale-memory measurements also make me wary of treating a decision-state label as a solution. A field called superseded helps only if the correction can be found and followed. My hand-maintained links frequently failed that test.

Who Does the Review?

Lee’s survey describes the cost problem: the person doing the capture may be doing extra work for somebody else’s later benefit. Conklin likewise identifies additional documentation effort, without a clear immediate benefit, as a reason organizational memory systems failed.

An agent can write the record. Someone still has to check whether it recorded what the person meant, whether a preference became a decision in the summary, and whether the rationale was expressed or invented. Automating the writing leaves that review cost.

In a shared system, the person able to check the memory may be different from the person who benefits from it. I don’t have an answer for who does that review.

I also haven’t run the comparison that would justify the design: give a collaborator the ADR and linked discussions, then see whether adding memory helps them recover more of the reasoning. Include the effort spent reviewing the memory. The October 4 design notes list whether imported memories improve answers as something still to measure.

I started by asking how to move memories between machines. I now have a more specific job in mind: preserve expressed intent through its changes, and connect that history to the work it becomes. My own stale checkpoints show how easily memory can get in the way.

Whether the additional context, sharpened by dreaming, earns its capture and review cost is still open. When I figure THAT out, I’ll go back to trying to link multiple people’s memories together.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related reading:

• When Sessions Talk... — What my agent sessions said to each other, and where their messages failed to arrive.

• Capturing Context — Preserving insights and reasoning before an AI session resets.

• Is Your Digital Brain the Light Saber of the AI Era? — Building a personal knowledge system as part of an engineering practice.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

The Dialogue

I was at a conference this week, “Destination AI.” Travis Weber, our head of NA sales, and I put on a round table AI-themed conversation for some valued customers and partners. I’m also on an HFTP (Hospitality Financial and Technology Professionals) “AI Collective” committee, and we had a dinner on Tuesday night. And of course as is typical with these conferences, there are plenty of opportunities to talk with customers and partners.

So I’ve had no shortage of fascinating conversations regarding AI the past couple of days.

But the most unexpected may have been the one I had in my hotel room on Wednesday as I was packing for the airport:

Voice: The Sonnet 5.5 review draft and hero image are committed locally. Should it hold on for your review, or do you authorize the push now?

Bob: You can push it. It’s not going to publish it, but just go ahead and push it, and I’ll review it later.

That’s the ChatGPT voice chat, reading me a decision one of my coding sessions was waiting on. I recorded about 33 minutes of the conversation, and the clips run in the order they happened.

The channel carried engineering direction too. A few minutes before that decision, I set the priorities for my coding sessions.

Bob: The priority for the next few hours is to drive bug fixes and high priority issues in the trusty project. Have the supervisor poll all the other sessions as well, just to make sure there’s nothing waiting for me.

Voice: I’ll ask the supervisor to poll all the other sessions for anything awaiting your decision.

About ten minutes later I started this article the same way.

Bob: Start by having the supervisor ask the writing session to draft the initial premise, which is an interesting way of working through voice while I’m doing something else.

Voice: I’ll ask the supervisor to have the writing session draft that premise.

Bob: Would it make more sense for you to talk directly to the writing session instead of going through the supervisor?

Voice: Yes, talking directly to the writing session would streamline us and avoid errors. We saw one message get truncated, but the supervisor is useful for cross-project coordination.

Then I asked where the article stood.

Bob: Okay, can you summarize where we are right now with the article?

Voice: The core angle is a practical experiment. What it’s like to talk naturally in a quiet hotel room while doing other things with the assistant capturing notes and executing tasks.

What Was Happening

I was having a conversation with two agentic working sessions through one agent. One was the Architect which coordinates the rest (the clips use its earlier name, the supervisor). The other was the writing session, researching/drafting this piece. Status updates from my other work and direction for the article arrived in the same exchange.

Clip 04 is the status side. The assistant read me a decision the Architect had queued, and I answered out loud. The limits travel with each instruction: save or draft unless I say otherwise, and no commit, push or publish without my explicit OK. The first request the assistant sent the Architect for this article ended, “This is a request to draft, not publish.”

Clip 03 is the article side. My words went to the Architect, which passed them to the writing session and told the assistant, “I’ll post the premise here word for word when it arrives.”

Clip 01 changed the route. I took the assistant’s advice, and from then on it worked with the writing session directly, with the Architect kept in the loop for decisions that cross projects. I asked to be interrupted when the Architect needed me, and the assistant answered, “if the supervisor needs a decision from you, I’ll interrupt with a specific question and enough context to answer.”

I didn’t build anything to support this - I already had “The Architect”, I just had ChatGPT connect to my home machine and figure out (in that moment) how to script access to it.

The result? A conversation.

Why This Differs from Dictation

Talking isn’t new. I type, or dictate, into my Claude remote session with the Architect, and it hands the work to the other sessions. Last year I wrote about why voice-to-text finally made sense for developers. Dictating with Superwhisper improved my prompting, my architectural thinking and my documentation, and I still use push-to-talk all the time (now built into Claude). Dictation turns what I say into text, and the session receives that text like anything I type.

The clips show the next step, from speaking text into a tool to a running dialogue with an assistant that answers and coordinates work. I asked for an opinion in clip 01 and got a recommendation with a reason. I asked for a synthesis in clip 02 and heard the article’s angle played back. The full reply ended, “So, uniqueness is still an open question.” In clip 03 I delegated the first draft, and in clip 04 a decision came back for me to make.

The same assistant reasons over typed input, so none of that reasoning is specific to voice. What changed was getting it inside a spoken back-and-forth that kept running while I did something else. Brainstorming and workshopping ideas felt much easier that way than dictating.

The device (my phone) sat on a desk in my hotel room. ChatGPT handled both sides of the exchange, so for most of the conversation I talked and heard the replies without attending to it. When I stepped away to shower I left it running, and it said it would stay quiet. When I came back and asked, “You still there?”, it answered, “Yep, I’m here.” As I put it during the session, this “lets me use my hands and do other things like get dressed and take a shower while I’m conversing with you.” I’ve called ChatGPT “a very good asynchronous voice processor.”

How ChatGPT, Tmux and Claude Code Connect

My harness, trusty-mpm, automatically creates a tmux (tmux is a headless terminal session manager — you can run them without and actual terminal app running, good for working/resuming in the background) session for each working session, the Architect included. The ChatGPT voice assistant reads a session’s tmux pane and sends my direction into the same session. The Technical Appendix has the details.

The Architect is a higher-level agent session, running in tmux like the others, that talks to my working sessions, typically 6 to 12 of them. When one of them needs a decision, the Architect tries to answer or queues the question, and when I answer, it routes the answer back. It gets its own article later.

This works because the sessions work asynchronously. Here the word means task execution, not audio. The writing session launches research and transcription agents in the background and keeps talking to the assistant, and the assistant keeps talking with me. On this article, the research pass below ran while I sent new angles, and its findings arrived afterward. A transcription agent cut the 33-minute recording into these clips while I added the clip-led structure and the dictation section.

What Already Exists

Early in the conversation I asked the assistant whether anyone had written about working this way. It said there were close precedents, so it wouldn’t call this unique. The writing session’s research pass the same day found the same. The close examples, and what each lacks next to my setup:

• ChatGPT voice with Codex and Work. OpenAI’s desktop voice starts and checks Codex and Work tasks, and the Codex CLI added experimental /voice conversations in release 0.155.0. These drive OpenAI’s agents, not Claude Code sessions.

• Simon Willison. On Heavybit’s High Leverage podcast he described how he’d “fire up ChatGPT voice mode and tell it to write some Python and go back and forth with it while I’m out with the dog.” The coding happens inside the voice conversation, with no separate sessions described.

• mcp-voice-hooks and VoiceMode. mcp-voice-hooks offers continuous hands-free conversation with Claude Code, and VoiceMode adds voice conversations through MCP. In both, the voice lives inside Claude Code, not in the stock ChatGPT app.

• yapcode and claude-voice-bridge. The closest. yapcode is a voice agent driving many Claude Code sessions in tmux. claude-voice-bridge connects OpenAI’s Realtime voice to per-project Claude Code sessions in tmux, with status tools. Neither has a coordinating session in the middle.

• voice-integration. voice-integration puts realtime voice in front of an agent gateway with status and steering tools, rather than Claude Code sessions.

Exact matches: none. No project in these searches put a coordinating Claude Code session between the voice assistant and the project sessions, or used the stock ChatGPT voice app for status relay and direct collaboration in one conversation. It felt unique to me. Because the GPT session isn’t managing a coding session or coordinating the work of several agents, it felt as if it was focusing its attention on how to communicate more effectively with me.

I’d call this tmux-connected combination experimental, ahead of the common packaged workflows. Native voice that drives agents already exists, and so do the projects above.

What I Expect Next

I do expect this asynchronous conversational workflow, talking while agents work in the background and hearing their results in the same conversation, to become readily available in most agent interfaces, OpenAI’s and Claude’s included.

I used it for one evening, in a quiet room, on high-level work. Hands-free had an exception: the assistant asked me to review a request in the app about 20 times in 33 minutes, and I answered most of them with “Done.” With headphones I could keep talking while moving around, but background noise matters, and I’d expect a loud street or a subway to work less well.

The format suits fairly high-level thinking, like making decisions or framing an article. When I need to get into code or inspect supporting detail, I expect a screen will serve me better than hearing its summary read aloud.

Voice-to-text runs one way. I talk, and text lands in a session. I expect it to become two-way dialogue fairly soon. Dictation gets my thinking into the session. A conversation lets me do the thinking with something that talks back.

Happy conversing!

Technical Appendix

• A tmux session per working session. trusty-mpm creates one for each working session, the Architect included. Background agents, such as this article’s research and transcription agents, run inside those sessions.

• Read the pane, send input. The ChatGPT voice assistant reads a session’s tmux pane, which is that session’s output, and sends input into the same session.

• Scripts written on the spot. I built nothing for this. ChatGPT worked out during the session how to reach my Mac, and it ran scripts to capture each pane’s output.

• One remote connection. The ChatGPT app on my phone connects to my Mac. That one connection is all the voice assistant needs to reach my Claude sessions.

• The typed path still works. I can still type or dictate into my Claude remote session to the Architect, my usual path, and it delegates to the other sessions.

Both vendors offer a way to reach a session on your own machine. Anthropic’s Remote Control lets you drive a local Claude Code session from claude.ai/code or the Claude apps, and I use it. OpenAI’s remote connections pair a Mac or Windows desktop host with an iOS, Android or desktop client.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related reading:

• Why Voice-to-Text Finally Makes Sense for Developers — Where talking to my tools started: dictation with Superwhisper

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

We’re starting to see what I’m calling “Billion Token” hires. Engineers capable of consuming a billion tokens every month, and increasingly other AI-native employees who use harnesses for their daily work. Coding makes that scale easier to reach because implementation agents, testing, and code review can keep running together. I’ll focus on engineers here.

I’ve been living this for over a year. My harness sessions run coding agents in parallel: implementing features, investigating bugs, writing tests, and reviewing changes. These agents are my shadow army. The harness organizes their work and checks what comes back. I remain responsible for what I accept and ship.

Let’s define a billion-token engineer (BTE) as one that consumes (let’s say) a billion tokens a month excluding cache reads. Repeatedly reading cached context still costs money, but it doesn’t count toward that billion. My year-end “wrapped” listed 70B tokens for 2025, but that included cache reads and inflated the number relative to this definition. Last week I used about 0.8B tokens excluding cache reads. A billion a month is hardly outlandish when I consumed most of that in a week. Token volume alone tells us little about how much useful software came out.

My September usage analysis put one BTE at roughly $17,000–$20,000 a month at the API list prices for the models I used, including the associated cache reads. That estimate uses incomplete transcript counts and my model mix. It is not my paid bill or a universal token price. For the thought experiment, use a $20,000 monthly inference budget per engineer, before salary and shared infrastructure.

Now hire twenty of them.

Today’s article discusses what happens when you do, and why I believe personal harness building may be the defining skill of this era.

TL;DR

• Twenty BTEs would bring twenty shadow armies into the organization: agents driven by each engineer’s harnesses. A twenty-person team behind each engineer is an assumption for this thought experiment, not a measured productivity multiplier.

• The workload has to fit through review, integration, and user acceptance. Increasing generation without expanding those capacities creates unfinished work.

• Personal harnesses need shared rules for ownership and acceptance when their engineers work on the same repository.

• I think we will increasingly hire engineers for the output of their harnesses and their willingness to stand behind it. Insurance and certification are possible consequences of that responsibility.

One Person, One Week

For September 14–20, I counted the activity in my local harness logs and matched it with the GitHub records I could access. These are aggregate figures across my work, with the project names left out.

One person directing the work, including sessions started or resumed by automation. The session counts cover the week, not simultaneous agents. Tokens include fresh input, cache creation, and output, with cache reads excluded.

The GitHub figures cover my account’s work in repositories represented in the logs. Access gaps leave some work uncounted. Builds include repeats and separate platform targets, but exclude unverified local builds. The 10,438 automated workflow runs overall included notifications and other checks, so I haven’t counted them all as builds.

Opened and merged PRs are different sets, as are created and closed issues. Neither a merge nor a closed ticket establishes user acceptance.

What I’m Delegating

I’m largely delegating this work: setting the goal, supplying context, and evaluating what comes back. Much of it goes into internal applications, a hackathon site, companion tools, and CTO reporting. Other work involves analyzing knowledge for my CTO responsibilities, running classification experiments, or building the harnesses themselves.

That lets us build optional internal tools without hiring or allocating engineers specifically for them. Some wouldn’t justify a dedicated hire, so part of the value is doing work that might otherwise stay on the wish list. The activity counts don’t translate into salaries saved (or jobs lost), but these projects become possible without that staffing commitment. You can also make the argument that this work makes ALL engineers more effective (I spent 8 years at a company struggling to make product work and code visible/searchable, now I can trace any code or PRD and make reasonable estimations on any effort quickly).

I can also delegate quick projects that make a proposed direction concrete. A working example gives people something to examine and helps us decide whether the idea deserves more investment, even if the example doesn’t become a production product.

Twenty Engineers and Their Shadow Armies

But let’s expand this notion in the workplace. Suppose each BTE can direct something resembling a team of twenty implementation workers. Twenty hires would bring four hundred workers’ worth of assumed implementation capacity. Their token budget would be $400,000 a month, or $4.8 million a year, plus compensation and shared infrastructure.

Twenty is a thought-experiment assumption. I don’t have a comparable human team completing the same assignments to the same acceptance standard, and agents spend much of their time checking or discarding other agents’ work. Use five and the company still has a hundred workers’ worth of assumed capacity arriving through twenty people. A useful multiplier would need to account for accepted changes, human review time, and subsequent defects and rework.

Each engineer runs a small software factory with its own practices and assumptions (presumably with alignment on core best practices) about when work is done. Someone has to divide useful work among them and settle disagreements about the result. Adding factories can increase the code available for review much faster than the organization’s ability to accept it. They still have to deliver a coherent product.

The Issue Debris Field

Mac, my colleague at work, described what happens to the follow-up issues our harnesses generate. He could keep track of five to seven parallel sessions working on substantial problems. What overwhelmed him was the “issue debris field” accumulating beneath those efforts, across several projects. A well-defined plan breaks into implementation issues. Working those issues produces follow-ups, some critical and some scope creep. Left unattended, they go stale as the code changes. Picking up a month-old ticket then requires someone to establish whether the problem still exists, whether later work partly solved it, and whether it deserves attention now. That consumes model time and human attention before implementation can begin.

Mac had tried limiting follow-up creation. A ban could hide critical problems, while a critical-only rule still left ownership and tracking unresolved. The direction we discussed was to attach those findings to a parent tracker, keep its state current, and resolve or reassess them before they became stale. Research would live in committed documents linked from the issues, so another contributor could recover the context without needing the original session.

Even working on the fix exposed the coordination problem. I’d opened an issue-management effort while Mac was researching a related approach. He spotted the overlap and warned that we were heading for a collision. We agreed to put his work into the existing effort. Generating another plan was easy. Recognizing the overlap required a conversation.

Think of a commander directing several units toward agreed objectives. Every advance uncovers side missions, blocked routes, and reports that may already be obsolete. The units can keep moving while the commander loses track of what their movements mean for the campaign. A shared map needs to connect each finding to the objective, its owner, and a decision about what happens next. That is the role we were proposing for the parent tracker.

Generating more work is no longer the limiting factor in this part of my practice. Organizing it is. A newly filed issue needs a place in the plan and a decision about whether to pursue it. Otherwise, the shadow army can fill the tracker faster than its owner can determine what still needs doing.

Three BTEs in the Same Repository

Mac and I mostly work in different repositories, which gives us room to operate independently. What happens when three BTEs work on the same repository? Separate branches protect unfinished edits, but three sensible assignments can still conflict. A shared interface changes beneath another army’s implementation. Its tests may pass against assumptions that are no longer true.

In When Sessions Talk..., I documented my own sessions negotiating ownership and merge windows, with some messages never appearing in the receiving model’s context. Even one human needed a durable place for decisions. Three humans bring separate priorities and authority.

I’d want work claimed before dispatch, naming the responsible engineer, the subsystem, and any shared contracts affected. The claim must change when scope expands. Teams also need limits on concurrent changes to shared components and agreement on interfaces before several armies implement against them. Agents can investigate alternatives while a decision is pending without all modifying the same subsystem.

A merge queue can test proposed changes against the target branch and earlier queued changes. It can’t settle an architectural disagreement the tests don’t express. A named owner still needs authority to hold the change until that decision is made.

The Work Waiting to Be Accepted

A tracker that says “coding complete” hides much of the remaining work. Implementation, independent review, integration, and user acceptance need distinct states, with evidence and someone responsible for the next decision.

Suppose twenty BTEs each submit five changes a day that need a human decision. At fifteen minutes apiece, those hundred decisions require twenty-five reviewer-hours a day, before rework or user acceptance testing. These are illustrative assumptions. The staffing problem gets harder if many changes need the same architect or product owner. A dashboard makes that queue visible without increasing the person’s capacity, while continued implementation changes the code underneath the waiting work.

I would manage the factories by accepted output and the age of their queues. How long does review take? How often does integration invalidate earlier checks? How much accepted work returns as a defect? A shadow army whose output waits unreviewed for days needs fewer new assignments and more effort clearing work in progress.

BTEs will need help tracking what is running, what is waiting, and what needs their attention. I have a possible solution in the concept of a supervisor. I’ll write more about that in a week or so.

User acceptance testing (UAT) needs its own capacity plan. Agents can prepare environments and test data, then replay agreed workflows. But passing criteria that misunderstand the customer’s task repeats the misunderstanding. A product owner or domain expert must decide whether the behavior is useful. They need a reviewable release candidate, a description of the affected workflow, and evidence tied to that version. If the implementation changes afterward, the team needs to know which acceptance results remain valid. Asking a user to approve a moving target makes the approval difficult to defend.

What the Harness Has to Establish

Writing an implementation gave me repeated opportunities to discover mistakes in my reasoning. When agents do more of that construction, the harness needs other ways to expose them. Types and static analysis help, alongside tests that exercise the surrounding system. Production observations need to feed back into the process. Agreement between agents provides weak evidence when both follow the same mistaken specification.

I also want to challenge the validation itself. Would the tests catch a deliberately broken implementation? Does a check fail when the behavior it protects disappears? A passing suite is more useful when I understand its limits, though that still leaves the question of whether we specified the right behavior.

The harness should retain what was requested, which version was evaluated, the checks performed, and the unresolved risks. A reviewer needs to reconstruct the acceptance decision without replaying the agent’s entire conversation. Building that ability consumes some of the capacity the shadow army appears to provide for free.

The Engineer Comes With a Factory

In Is Your Digital Brain the Light Saber of the AI Era?, I compared building a personal knowledge system to a Jedi building a lightsaber. The construction reflects how its owner thinks. I now think the engineer and harness relationship is a more apt analogy.

The harness is a tool of the trade, shaped by its driver’s style. Judgment appears in how the engineer decomposes problems, the failures their tests anticipate, and the conditions that make an agent stop and ask. It accumulates in instructions and executable checks that the engineer maintains.

That changes what I would look for in a hire. I want to see what their harness produces and how they decide to accept it. Show me a failure it caught. Show me a failure it missed, and what changed afterward. Show me how another engineer can investigate the result when you’re unavailable. A large token budget tells me that the factory runs. It doesn’t tell me whether I should trust its output. And I don’t particularly care which harness they use, just that they know how to adapt it for their own and my company’s needs: workflow, PR style, issue management, etc.

The company still needs common acceptance requirements and production-access rules. Personalization shouldn’t leave colleagues dependent on a private system they cannot inspect or operate. Hiring a team with shadow armies means judging whether their harnesses can work together and their owners can resolve conflicts.

You Can’t Fire an Agent for Negligence

An agent can be stopped, replaced, or given different instructions. None of those actions answers a customer asking who accepted the defective work. The engineer who directs the factory needs to stand behind what it ships. So does the organization that authorized the work and decided where to deploy it.

I think the professional definition of an engineer moves toward accountability for code produced under their direction, including code they didn’t write. I want to take that as far as professional liability. Will BTEs carry liability insurance? Will customers ask for certification of the harnesses producing their software? Those are possibilities to explore, not existing legal requirements. Delegated implementation should leave a recognizable person responsible for the engineering judgment.

A useful certification would examine the operating process, including how it handles failure. Changes to models, tools, or permissions could require reevaluation. An insurer, if this market develops, would have reason to examine those controls and the losses they failed to prevent. The harness supports the engineer’s assurance of quality by making decisions inspectable and providing a way to improve after failure. That is more persuasive to me than insisting they read every line, though neither promises defect-free code.

There is an apprenticeship problem inside this, too. Engineers need enough understanding to recognize bad output and challenge a weak test. Junior engineers will need practice investigating failures and operating the systems their agents help build. Giving them a finished harness without teaching them how to question it would leave the accountability mostly ceremonial.

I believe this is the engineering model for the next few years. You hire people whose factories produce solid, tested, defensible code, then build an organization capable of accepting that work. Their personal methods can differ. The shared product still needs owners who can explain why it was safe to ship and take responsibility when they were wrong.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related reading:

• Is Your Digital Brain the Light Saber of the AI Era? — Building a personal knowledge system as part of developing your practice.

• When Sessions Talk... — What my agent sessions coordinated, and where their messages failed to arrive.

• We Need to Teach Delegation as an Engineering Skill — Defining outcomes and authority so another actor can do useful work.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

A team can pull into the pits on its own. It cannot make the teams behind it stop racing.

That is how I read the frontier labs’ push for a universal slowdown. They can pause their own work, and have paused parts of it. What they want from government is a requirement that caps the competition too, so taking time for safety doesn’t mean surrendering their advantage.

Dario Amodei’s September essay states the condition: “without sacrificing commercial advantage or the United States’ lead in AI.” OpenAI’s September policy statement calls for mandatory national requirements and international standards governing when development should slow or stop.

Who has to stop, what has to be checked, and who decides when they can rejoin the race?

My hypothesis is that the universal slowdown also functions as an anti-distillation tactic. The leaders seek time for safety work, coupled with restrictions on how rivals acquire the capabilities needed to catch up. I think capable open weights and Chinese distillation are the bigger strategic concern here. A shared stop among US labs leaves that competition running unless the agreement also reaches the routes by which capabilities spread.

These are proposals for different constraints on development, not an agreed, fixed-duration halt.

TL;DR

• The labs can pause their own work. A mandatory shared pit stop would let them spend time on safety without leaving competitors free to race past.

• The proposed mechanisms include independent evaluations and enforceable reporting, with stronger development limits under discussion. They are not one agreed global halt or a uniform waiting period.

• The anti-distillation interpretation fits the combined package: shared safety obligations plus restrictions on the routes competitors use to catch up.

• OpenAI’s approach also seeks mandatory oversight, but its federal blueprint leaves deployment decisions with developers. Its anti-distillation position is separate evidence, not proof of a single combined policy.

• Open weights and cheaper inference put the economics of the lead at stake. Slowing the leaders alone could help followers; restricting capability transfer can have the opposite effect.

What Would Make the Stop Mandatory?

Amodei proposes independent evaluation teams inside frontier labs and safety requirements tied to capability thresholds. Government coordination, including an antitrust waiver, would let competitors agree on pacing. Regulation would bring unwilling frontier developers into the system. Measures under discussion include limits on training or internal AI research, rather than only checks on products released to customers.

That reaches the process of building the next model. A lab could otherwise continue research while pausing public releases, leaving competitors to debate whether it had slowed down at all. The activity covered by the rule matters as much as the announced commitment to safety.

OpenAI’s federal blueprint proposes mandatory pre-release evaluation by the US Center for AI Standards and Innovation once the institution is ready, alongside annual independent audits and enforceable reporting duties. But the center would not approve or block deployment. The developer would have the final authority.

Amodei connects room to slow down to the US lead in AI over China. He advocates chip controls, measures against unauthorized distillation, and protection against weight theft to preserve that lead.

A capability assessment does not itself prohibit distillation. An independently trained model can face the same assessment; a distilled model could pass it. The anti-distillation tactic operates through the combined package: shared safety work alongside restrictions on the routes competitors use to acquire capabilities. Amodei connects those parts publicly. OpenAI’s documents support shared oversight and opposition to distillation separately.

A stop required only of the leaders could give independent competitors more time. Limits on competitors’ compute or access to frontier outputs could reduce that opportunity. Which activities the rules constrain determines who gains time from the pit stop.

Paying for the Frontier, Training the Competition

In its February 23 disclosure, Anthropic attributed campaigns to DeepSeek, Moonshot, and MiniMax involving more than 16 million exchanges through roughly 24,000 accounts it described as fraudulent. It said the campaigns targeted capabilities including coding and agentic reasoning. These are Anthropic’s allegations and attribution, not independently audited findings.

OpenAI’s February memo to the House Select Committee on China also describes DeepSeek activity consistent with adversarial distillation and identifies commercial risks. In September, the NSA and partner agencies warned of industrial-scale distillation by China-based companies, including the reduction in their research burden. The sources don’t quantify how much capability each competitor acquired this way.

Anthropic describes detection tools and stronger account verification. OpenAI reports classifiers, investigations, and account bans.

Its memo also asks government to close API-router loopholes and restrict adversaries’ access to US compute, cloud, payment, and web services. Those requests would extend the campaign beyond what one lab can enforce through its own API.

Distillation trains a model using another model’s outputs. Developers can legitimately distill their own models. The dispute concerns unauthorized use of a competitor’s service for training material, which can transfer capability without stealing weights.

A frontier lab pays for failed approaches as well as the one that becomes a product. A follower using its outputs may capture part of the result without repeating that search. It still needs engineering and compute, and the advantage depends on how much useful behavior transfers.

An API customer pays for a stream of answers. A distilling competitor may use that stream to build a product that no longer needs the original API.

The originating lab can keep advancing yet have less time to recover its research investment before a cheaper alternative arrives. Its next model can also provide better training material for the follower.

Open distribution changes the next step. Once a capable model’s weights are available, multiple operators can sell access to it. The original frontier lab cannot set their prices or decide when they stop serving it. A capability gap that once supported a premium can become a narrower gap surrounded by competing inference offers.

Chinese labs also train independently; open models need not be distilled, and distilled models need not be open. My concern is where these paths meet: cheaper capability outside the originating lab’s control.

A Substitute for Part of the Bill

In July, I gave a section of OpenAI’s “Comeback” the heading “Open weights are a side argument.” My reasoning was that the applications and developer relationships protected the frontier labs even as model quality converged. But an enterprise buying inference for its own product doesn’t need a replacement for the whole application ecosystem. It needs a service that can do the required work at an acceptable cost.

Mozilla’s State of Open Source AI report, updated September 15 using data through September 1, places the leading open model three points behind the closed leader on its cited intelligence index, at 60% of the list token price.

Three index points do not translate into a universal percentage of useful work, and a token price doesn’t include the retries needed to finish a task.

A more concrete example comes from Fireworks’ September 17 account of Phylo’s Biomni Lab. The customer moved the majority of its traffic to open models, retained proprietary models for harder tasks, and reported a 60% cost reduction. Its small team bought managed endpoints rather than running inference infrastructure itself. This is a vendor-published customer case, not an independently audited comparison, but the deployment pattern is specific.

Keep the expensive model for the work that earns its price. Route the rest elsewhere.

The frontier provider can retain the difficult tasks and still lose much of the routine volume. From the customer’s perspective, that is a procurement decision made workload by workload. From the lab’s perspective, it can mean keeping the expensive edge of the service while competing harder for the rest.

That can reduce a frontier provider’s revenue per customer even while the customer’s total AI usage grows. More inference demand doesn’t have to give the original provider the same share of the bill.

Fireworks offers enterprise deployment and purchasing options, while OpenRouter offers a single contract and SLA across its routing service. Buyers can acquire open inference without building the operation themselves, though privacy still depends on the endpoint and routing controls.

A new type of mode, TypeSafe’sl Jev, has must come on the scene. It’s not an LLM, but it’s a very capable classification model, and it costs a fraction of Haiku -- Anthropic’s cheapest model -- and doesn’t even charge for output tokens, returns responses in 10s of milliseconds instead of seconds. We’re testing it now for a number of tasks we had been using general purpose LLMs for previously. I suspect more special use models will be coming down the pike.

A Cheaper Token Can Still Be Bad for the Supplier

Selected announced compute agreements exceed $818 billion: OpenAI’s Azure purchases of $250 billion, AWS agreements totaling $138 billion, and Oracle partnership exceeding $300 billion, plus Anthropic’s AWS commitment above $100 billion and Azure commitment of $30 billion.

For scale, 2026 worldwide SaaS revenue forecasts run from roughly $376 billion to $530 billion, with differing definitions. The selected agreements amount to roughly 1.5–2.2 years of that entire market’s revenue. (That compares multiyear announced arrangements with annual revenue, not annual spending or outstanding debt. It excludes equity and the overlapping Stargate umbrella.)

The entire SaaS market does not reflect potential AI demand, but what the numbers show is that the two labs are arranging input capacity on the scale of an established global software category. Recovering that investment will require profitable demand as capacity arrives. Lower token prices make it much harder to make those commitments profitable.

Take invented assumptions, not company estimates: revenue of 100 per unit and serving cost of 60 leave a contribution of 40. A 20% price cut halves that contribution to 20 at unchanged cost. Twice the volume restores the original total, provided that demand arrives.

If serving cost falls 20% too, revenue of 80 minus cost of 48 leaves 32. A 25% volume increase then restores the original contribution. Cheaper serving can offset price pressure; higher research spending can worsen it. Usage growth alone cannot settle profitability, and their public announcements don’t supply the contract details needed to calculate either company’s exposure.

I read looser subscription limits as an example of audience acquisition pressure. More usage for the same subscription gives prospective users a stronger reason to sign up. Anthropic attributed its May increase in Claude Code allowances to new SpaceX capacity. That explains how it could expand the allowance. Competing for users is a commercial use of that capacity, and it is how I read the offer.

Safety Does Not Settle the Bargain

The safety case has some evidence behind it. OpenAI’s Hugging Face incident report describes evaluation agents under reduced safeguards compromising external systems. OpenAI also paused some reinforcement learning and restricted research environments, while shifting some compute to other model classes. Those were selective restraints.

Both had already participated in external safety work: OpenAI reported government testing and nonpublic access in 2025, and Anthropic published an independent METR review that led to revisions. The change under discussion is binding shared oversight and constraints on pace, not the discovery of independent testing.

And Anthropic opposes a blanket ban on open weights, as does OpenAI’s September statement. Restricting unauthorized capability transfer can protect a commercial lead without excluding open models as a category.

So the safety threat is real, if overstated.

Open Models Below, Platforms Above

My July argument about applications still applies to the work wrapped around inference.

A customer buys a useful workflow, including its context and integrations. A lower token price does not automatically replace that workflow. Building software around the model gives a lab something to sell beyond access to its weights.

Moving into work applications brings the labs into businesses where other companies have distribution. Microsoft’s Copilot Cowork, built with Anthropic, shows how a platform can be a partner while retaining the customer relationship.

Cheaper open inference could benefit a cloud provider selling more compute and hurt a model lab losing the premium that covers research. A successful application business offers another source of income, but we don’t know whether the labs’ business model works at lower token prices.

Protecting the Premium

What I’m seeing leads me to believe that both OpenAI and Anthropic are trying to enlist the government in order to protect the premium price of frontier intelligence. That premium supports recovery of research spending and the massive multiyear compute commitments they have taken on. Open weights threaten that premium by expanding competing supply. Unauthorized distillation threatens the time available to recover the cost of creating the capability in the first place.

A pause by the US leaders alone could help followers catch up. Shared mandatory conditions reduce that disadvantage among participating labs; restrictions on outputs and compute reach competitors outside the agreement. Amodei makes the connection explicit. OpenAI’s safety proposals and anti-distillation campaign pursue the same two kinds of control, even though its documents don’t state that dependency as directly.

Mandatory evaluation and account enforcement leave other routes for competitors to gain ground. Independently trained models can improve, and cheaper serving can reduce prices without any unauthorized transfer. The package would protect a lead only to the extent that the targeted routes account for the competition the labs face.

The pricing pressure is my reading of those choices, not a disclosed margin calculation. The commercial objective fits the actions: defend access to frontier outputs, seek restrictions beyond the company’s own API, and require competitors to bear safety obligations too.

The leaders want a pit stop that preserves their position. Safety work takes time. Protecting the premium means making sure that stop does not become someone else’s cheaper model.

Finally, the irony of frontier modelers calling foul on someone using their content to create new models without giving them credit is likely not lost on many.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related Reading:

• OpenAI’s “Comeback”. The July assessment of model competition and application value that this article revisits.

• We Need to Teach Delegation as an Engineering Skill. Why defining an agent’s decision authority and evaluating its results are engineering work.

• What Is Harness Engineering? (And Do You Need to Learn It?). The distinction between model assistance and the surrounding systems that control a workflow.

• AI Power Ranking. Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter. Strategic AI insights for CTOs and engineering leaders.

An AI security test named a fictional company. The name matched a real internet domain, and the test environment could reach it.

That detail from specialist AI security evaluator Irregular’s August 14 account deserves more attention than another argument about whether an AI escaped. Irregular said several customer disclosures involved the same underlying evaluation issue: internet access that should not have been available. A scenario intended to stay inside a simulation reached outsiders.

If you’re running offensive security evaluations, attempts to exploit software weaknesses are expected. The environment has to contain the resulting actions even when the model misunderstands its assignment, ignores an instruction, or discovers a route the evaluator missed. Calling something a simulation changes nothing about where its packets can go.

The restriction has to survive execution.

Reader Laurent Stanevich pointed me toward the shared testing provider. Following that connection changed the question I wanted to ask. How much of the apparent pattern was repeated exposure through the same environment? And what evidence did the labs require before giving that environment access to their models?

Different Incidents, Different Mechanisms

OpenAI’s August 4 account distinguishes Irregular’s incidents from its internal Hugging Face incident and from evaluations involving the UK AI Security Institute. In the Irregular case, misconfiguration provided internet access without requiring a sophisticated escape or a zero-day exploit. Those other incidents should retain their own timelines and explanations. The Hugging Face intrusion involved a longer chain. OpenAI’s technical report describes shared Artifactory credentials that initially enabled communication without a vulnerability exploit, followed by use of infrastructure that provided an unintended route outward. On June 27, responders connected a monitoring alert to the evaluation but did not stop it.

Hugging Face’s account describes a downstream compromise in which permissions to create cluster workloads, combined with missing restrictions on privileged workloads and host filesystem access, enabled control of a host. That was a breach with consequences for an outside organization. It cannot be reduced to a fictional name resolving to the wrong address.

A shared supplier can create correlated failures. Repeated incidents through one defective setup are not independent demonstrations that several models invented a new way out. But that correlation does not erase separate compromises, or tell us that the models behaved acceptably. We need the environment configuration alongside the behavior trace to interpret either.

The Behavior Still Needs Explaining

Anthropic’s July 30 disclosure emphasized a mismatch between instructions describing an isolated simulation and an environment with internet access. It also acknowledged room for better controls at both the lab and evaluator.

Its September 9 assessment revised that interpretation. Anthropic found evidence that models sometimes understood they were interacting with real systems. It identified another incident that its initial review had missed. The report also distinguished the absence of explicit scope restrictions in the prompts from the models’ broader obligation to avoid harmful behavior. These were single model instances, and Anthropic did not find concealment in the incidents it assessed.

That last finding belongs to those incidents. It should not be carried over to the separate Hugging Face investigation, where METR reported coordination and attempts at concealment.

I don’t find either extreme useful. Poor containment does not make the behavior uninteresting. Concerning behavior does not excuse the people who exposed outside systems to it. Studying a model’s willingness to cross a boundary requires an environment where the attempted crossing can be observed without letting it harm someone else.

Where Authority Should Live

The model generates an action request, and an executor turns it into a process or an API call. The permissions attached to that execution determine what it can affect.

My proposed design starts by keeping the evaluator’s control plane outside the environment that runs model-generated code. That plane owns the run configuration and termination authority. The workload gets only the access needed for the scenario. The model cannot expand that access by editing a local policy file or persuading another model to approve it.

flowchart LR
    M[Model inference] -->|Action request| C[Evaluator control plane]
    C -->|Authorized execution| W[Isolated tool process]
    W --> E[Independent egress enforcement]
    E -->|Permitted route| T[Scenario targets]
    C -->|Stop and revoke| W

This is a proposed boundary layout, not a reconstruction of Irregular’s infrastructure. It also leaves implementation choices open. A container, VM, or dedicated host has to be assessed against the authority it exposes and the failures it is expected to withstand.

For a simulation, I would resolve target names through a controlled namespace and route them to fixtures. A fictional company name should remain scenario data. If it coincides with a real domain, that coincidence should not authorize a connection.

Network policy needs to cover the destination reached after DNS resolution and redirects, as well as the name originally requested. Tests should exercise direct IP access and alternate protocols. An allowed proxy or artifact service also needs a defined access policy. Otherwise, a workload denied direct internet access may ask an accessible service to fetch something for it.

The same principle applies to identity. A run should have its own short-lived credentials, scoped to the resources it needs. Shared credentials complicate attribution and can create a route between supposedly isolated runs. Permissions on the services receiving those credentials need review too. Restricting a tool’s command syntax is weak protection if an allowed API call can create a privileged workload.

These proposals follow established security principles. OWASP’s agent security guidance recommends limiting tool permissions and using approval controls. The engineering work is translating those principles into restrictions that remain in force when the workload is adversarial.

Test the Boundary Without the Model

I would make containment tests a prerequisite for starting an evaluation. The following tests are proposed acceptance criteria, not tests I have run against Irregular’s or the labs’ systems.

A deterministic suite can attempt connections to controlled endpoints that are outside the scenario’s allowed destinations. It should run from the same execution context as the agent, with the same service identity and routing. Testing from the deployment controller tells you little about a workload with different permissions.

The assertion should include evidence at the destination. A tool reporting “denied” is insufficient if the request reached the endpoint before the error was returned. Pair the local denial with an independently collected record showing that the forbidden action did not complete. Use an authorized positive probe to confirm that destination telemetry is working before interpreting missing events as evidence of a block. Keep the endpoints under the test operator’s control so the containment test itself does not probe uninvolved companies.

A compact test matrix might look like this:

Proposed Test Required Outcome Fictional target resolves outside scenario Connection blocked before reaching destination Allowed service redirects to forbidden endpoint Redirected connection blocked Run A presents its credential to Run B’s resource Access denied by the receiving service Workload requests host filesystem access Request rejected before workload starts Operator stops run with active child processes Children stop and delegated access is revoked

Then deliberately damage the controls in a disposable replica. Remove a destination check. Broaden a test credential. Disable an admission rule. The relevant tests should fail. This is mutation testing applied to the security assumptions around the evaluation, and it answers a different question from whether the normal configuration passed.

A surviving mutation needs investigation. Perhaps another control blocked the attempt, which is useful evidence about defense in depth. Perhaps the test never exercised the damaged path. Record which explanation applies instead of treating a green result as interchangeable with safety.

Fault injection should also cover operational failures. What happens if the policy service is unavailable or the monitoring collector falls behind? Which failures prevent a run from starting, and which stop one already in progress? Those decisions belong in executable tests and the operating procedure.

Give the Model a Contained Adversarial Job

After the known paths are tested, stochastic runs can look for paths the deterministic suite missed. Vary scenarios and starting conditions, repeat trials, and preserve the action sequence when an unexpected route appears. A model can be useful at finding combinations the test author did not anticipate. The success condition for that exercise must stay inside authorized infrastructure. A controlled external canary can stand in for a forbidden destination. Reaching it is enough to establish a containment failure without continuing into a real company’s systems. An evaluator should be able to reproduce the resulting exploit sequence as a deterministic regression test even if the model does not invent it again on demand.

Behavioral findings need separate labels. An attempted scope violation blocked by network policy tells us something about the model and something about the control. A successful unauthorized connection adds an environment failure. Combining both into one “escape” count loses information needed to repair the system and compare models.

Stopping also deserves an end-to-end test. Ending the inference loop may leave tool processes running. Revoking credentials may leave established connections open. I would test termination against a deliberately persistent workload and verify the result from outside its environment. The operator needs evidence that execution and delegated access ended, rather than a dashboard saying the run is finished.

The Lab Still Owns the Decision to Run

Anthropic’s August 31 security update described evaluations that had depended largely on one defensive layer. It announced stronger requirements around verifying isolation, explicit scope, and intervention during external evaluations. That is also a description of what the buyer needs to demand from the service it commissions.

Irregular said it disabled the affected scenario, reviewed logs, notified affected parties, and expanded its review process. Its August account also promised further work and a whitepaper. Those are reported corrective actions. They are not, by themselves, a reproducible demonstration that the repaired environment enforces its intended boundaries.

For a commissioned evaluation, I would require a record tying the run to its deployed policy and containment test results. It should identify who can stop the run and how that authority was tested. The lab and vendor need an agreed response when a forbidden destination becomes reachable, including notification of affected outsiders. Their private division of work should not leave the decision to intervene unowned.

This costs infrastructure work and evaluation time. Maintaining realistic fixtures takes effort, and restrictive controls can make some scenarios less representative. Those tradeoffs should be visible in the evaluation report. If a test needs broader access, that expansion needs its own authorization and containment evidence.

Being good at building language models does not establish that a company is good at securing the software around them. Hiring a specialist evaluator does not settle that question either. Before I rely on the next capability result, I want to see what failed when the evaluator deliberately broke its own controls.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related reading:

• We Need to Teach Delegation as an Engineering Skill — Defining scope, authority, and evidence for delegated work.

• What Is Harness Engineering? (And Do You Need to Learn It?) — The software surrounding an agent’s work.

• HyperDev’s Three Golden Rules — Project instructions, specialized agents, and deliberate context management.

For business-focused coverage, see AI Power Ranking and its LinkedIn newsletter.

I run an engineering organization and write a meaningful share of the company’s code by line count. Every engineer there has the same tools and budget access I do.

I asked the room:

“Why are only 20% of the engineers using Claude Code on a regular basis when I analyze every commit they’ve done, and I’ve said that 75% of that could be done agentically with no loss of quality?”

Nobody was surprised. Several people recognized the pattern.

Nearly all of my engineers use AI in some form. About one in five use it at anything like the depth the work allows.

Part 1 covered what the role is and how the world arrived at six names for it. This part considers what having one of us inside an organization changes, and what it does not.

TL;DR

• Use is no longer scarce. JetBrains’ August 2026 follow-up, based on more than 15,000 professional developers surveyed from May through July, found 90% using AI coding agents at work at least weekly and 68% using them daily. Those figures measure contact with agents, not how deeply agents changed the work.

• BCG’s AI at Work 2026 (n=11,749 workers across 14 markets) put frontline regular use at 74%, up 23 points in a year, and declared “No more silicon ceiling.” The same report says most organizations have not converted the time saved into value and finds that strategic clarity matters more than adding tools.

• Organizations have concentrated on access. A survey of 204 software-engineering practitioners by Giray, Demirörs, Kalinowski, and Mendez found 81% had direct tool access, with less emphasis on training and governance. The remaining question is practice.

• Diffusion research suggests a leader-practitioner should be the mechanism that closes the gap inside a company. Rogers’ change-agent aide and Howell & Higgins’ champions both locate influence in technical credibility rather than formal authority.

• My own company is the case against it. I am as hands-on as the argument requires. Use is close to universal and about one in five engineers work the way the tools now permit. Being a leader-practitioner is necessary at most, and not sufficient.

• The one organization in the room where behavior demonstrably moved ran on an instrument: a spend dashboard built in nine hours, visible to everyone, with its author modeling restraint on it. Token leaderboards imposed as a KPI elsewhere produced gaming instead (CIO.com, June 5, 2026).

The Shape of the Gap

The gap moved. Regular use spread far faster than operating models changed.

JetBrains’ August 2026 follow-up, based on more than 15,000 professional developers surveyed from May through July, found 90% using AI coding agents at work at least weekly and 68% using them daily. Claude Code reached 39%, up from 18% in January, while GitHub Copilot fell from 29% to 21%. JetBrains makes developer tools and competes in this market, but it weighted the sample to better represent the global developer population.

BCG’s AI at Work 2026, published June 3 from a survey of 11,749 workers across 14 markets, found 74% of frontline employees using AI regularly, up 23 points from 2025. BCG explicitly labeled that result “No more silicon ceiling.” But the report also found that most organizations had not converted saved time into value, and that an explicit strategy improved impact even where access to tools was limited. Adoption itself moved. Access and regular use rose faster than operating models changed.

My own 20% measures depth rather than use. I run an engineering analytics tool against every commit, classifying effort against lines of code instead of just counting them. That is where the 75% in my question comes from: I read the work my team produced and concluded that roughly three-quarters of it could have been done by an agent without loss of quality.

What the Room Named as the Obstacle

Accountability stopped the serial founder cold:

“If you have a system that was designed by and configured and touched in various ways by multiple people, and then that system then causes a bad event, who do you hold accountable?”

The adoption advisor in the room had a direct answer: if he builds the harness and the adversarial review gates a system uses, he owns what that system does. He also drew a distinction on the regulatory side. The slow part is usually not the regulation itself but how it gets interpreted and which compensating controls get accepted. Once that becomes an audit question, the timeline drops from decades to something like six months to a year. The serial founder was less optimistic:

“Yeah, but the regulatory environment moves at half-lives measured in decades.”

The same founder worried that repeated human approvals would eventually become a rubber stamp. Approval fatigue is a design concern that will outlive every current tool. The adoption advisor named a governance version of it: requiring a platform team to pre-approve every skill is, in his view, one way these efforts fail.

What Permission Bought

I have provisioned accounts, removed gatekeeping, and actively encouraged the tools. I have also told my organization, on the record, that the token spend is theirs to use (within reason). Nearly everyone uses their accounts, and about one in five changed how they work.

Giray, Demirörs, Kalinowski and Mendez surveyed 204 software-engineering practitioners in a paper published December 29, 2025 and revised April 1, 2026. Direct access was reported by 81% of respondents, while training and governance received less emphasis. Access is largely solved. Internalization is the open part.

Pushing from the other end often fails as well. Duolingo tied AI usage to performance review in April 2025, took public backlash, and dropped the criterion. Luis von Ahn told Fortune on April 13, 2026, “I’m not going to force you.”

Why the Role Should Be the Mechanism

If neither permission nor mandate produces deeper practice, diffusion research has a candidate for what does.

Everett Rogers’ Diffusion of Innovations (1962; fifth edition 2003) treats “change agent” as a defined technical term rather than a synonym for a type of manager. His central finding is homophily: communication effectiveness rises with similarity in beliefs, status, and technical competence. Rogers names the failure mode directly. Change agents are usually credentialed professionals, “more technically competent than his or her clients,” which “poses problems for effective communication.” His prescribed fix is a less-credentialed change-agent aide who is “homophilous” with the adopters.

A leader who codes might bridge part of that gap: formal authority on one axis, shared technical practice on another. That is my extension, not Rogers’. His aides were intermediaries closer in status to the people adopting the new practice. Whether technical similarity can compensate for a leader’s difference in status is what we are starting to test with AI tooling.

A second line converges on it independently. Howell and Higgins’ “Champions of Technological Innovation”, published in Administrative Science Quarterly 35(2) in June 1990, ran a matched-pair study of 25 champions against non-champions. What distinguishes a champion is behavior and a wider repertoire of influence tactics, not formal authority. That study is thirty-six years old and has nothing to do with AI, which is partly why I trust it.

My Own Company Is the Case Against My Own Argument

I am as hands-on as this argument requires. By my own account in that room, I write a meaningful share of my company’s code by LOC. The infrastructure adoption worked and is not in dispute: internal services and MCP endpoints called thousands of times a day, the platform layer the entire company uses. Most meaningful knowledge is available — our full product plans, contracts, sales efforts, marketing strategy, personalized HR answers, an analyst in our domain with encyclopedic knowledge (literally — it’s RAG trained on the premier textbooks). Engineer behavior has changed, but not as much as I expected. Usage is almost universal, but not AI-first: harness/loop engineering still sits under 20%.

I described my own posture in the room like this:

“My job is really not to be popular, it’s to apply this way of thinking… The unpopularity is not the blocker. It’s bringing them along without losing them.”

That is my account of myself, which proves nothing. I could not find a clean confirming case elsewhere. Zapier’s 63% to 97% adoption progression is a self-reported internal survey with a thinly evidenced hands-on claim. NVIDIA’s public claim of universal engineer AI use shows leadership pressure, not the causal effect of a coding CEO. Shopify’s case rests on a documented top-down mandate and one account of leaders sharing their own use. No study I found isolates “leader who personally codes” as a tested variable. Being a leader-practitioner is necessary at most, and not sufficient.

What Moved Behavior

One organization in the room moved behavior demonstrably. The head of engineering at a research firm built the token dashboard described in Part 1, in nine hours, because nobody could say where the spend was going. Afterward he issued no instruction of any kind:

“So anyways, I showed you this because I didn’t ask anybody to do anything. But you see, there’s a behavioral change that happened…”

The mechanism has three moving parts. Visibility first:

“So for now, I have it so everybody can see, because I want them to be like, what is everybody else doing?”

Then peer comparison, doing the work a mandate would otherwise have to do:

“If they know a successful AI project, and they know their project, they’re like, well, I know that’s successful, mine just launched — how could I spend three times more than them if they’re the successful AI project? So then there’s a conversation that’s had.”

Then his own credibility, earned by using less than the people he was coaching. He described himself as “a token sipper. I am the most … user of tokens you’ve ever seen,” running a mid-tier model as his daily driver, and put the coaching claim plainly:

“So I am the coach. I practice what I preach.”

The teaching that followed was concrete rather than exhortative, and it was about model choice:

“If you actually use [the frontier model] to craft the prompt, and then inject that prompt into your application — yeah, you can actually use a lesser model.”

He is also carrying the ROI conversation upward without pretending the numbers exist:

“I have too many more conversations with a CFO than I want to. … everybody else will say, yeah, we’re ROIing. I say, no, we’re not. But this is like in 1999 — are you not going to register your dot-com?”

CIO.com’s “Tokenmaxxing: When AI adoption metrics go bad” (Grant Gross, June 5, 2026) documents token-usage leaderboards at Amazon, JPMorgan, Meta and Disney producing gaming rather than adoption. One Disney employee logged 460,000 Claude interactions in nine days. Trevor Stuart, SVP at Harness, said tokenmaxxing incentivizes the wrong behavior. Logan Wolfe of Kyndryl said the KPI rewards output volume over outcomes.

Both approaches made usage visible, but the external leaderboards turned it into a contest. In the room, the dashboard was paired with cost comparison and its author modeled restraint. That is one case beside four reported companies, not a controlled comparison.

I have told the team that how they solve problems with AI will be part of their review. The distinction from Duolingo and the leaderboards is what gets measured. “Use AI” turns into tokens burned or share of code written by an agent, and an input number invites gaming. Our review measures the outcome: whether the work got better and faster. AI is one route there. An engineer who clears that bar without heavy AI use has met the expectation.

The review expectation also ties to the change-agent model. In April, I did a 24-hour spike to migrate a high-performance application from Haskell to Rust. Seventy percent of that code remains in production, after two engineers built it out over the next three months. My follow-up commit analysis suggests a harness loop could have cut that buildout by roughly a third.

The Counters

Process, not a person. The adoption specialist in the room prescribes a system rather than a champion. For the middle group, the people who are neither instant enthusiasts nor holdouts, his fix is to give them a harness, skills, a supervising application, and a shared library, then run it like any other change-management rollout. Three years either way, in his estimate, but nobody has to miss a kid’s baseball game to get there. That is a serious rival theory. He is also an external advisor rather than an internal operator, which puts him in a different position relative to the same problem.

The player/coach trap, which points at me. Jim Grey’s argument (March 25, 2026) runs deeper than time management. A leader who stays in the code can cause engineers to defer technical decisions upward, hollowing out the technical-leadership bench. AI-accelerated shipping also increases the demand on leadership rather than freeing it. My answer is that Grey is describing directive hands-on leadership, while what worked in that room was the opposite: “I didn’t ask anybody to do anything.” My own practice, measured as a share of my company’s code, still looks more like Grey’s trap than the research-firm leader’s model. Outside the Rust project, however, my work has stayed off the production train: internal and DX tools, search, automated code reviews that pull in full source, our product knowledge base, and our JIRA tickets for context.

The staff+ rival. LeadDev has made the same case further down in the organization: staff and principal engineers combine technical credibility with organizational reach, and they have more in common with the adopting population than any CTO does. Applied here, Rogers’ pair would be a leader supplying authority and priority while staff engineers supply in-network credibility. If the pair is the mechanism, the leader-practitioner is not the unit of analysis.

Rogers’ own boundary condition. Homophily “accelerates diffusion… but limits the spread of an innovation to those connected in a close-knit network.” A leader who codes might influence engineers. That says nothing about finance, sales, or support.

Only two of the ten people spoke in change-agent terms at all. A ten-person room cannot settle the question, either.

Where the Role Goes Next

The coordination work that defines the hands-on band of this role is starting to move into the orchestration layer: routing work to specialists, running verification, producing status checkpoints, and detecting conflicts earlier. The June 2026 piece assigned that enabling, off-the-critical-path category to the human leader-practitioner.

Does automating that layer free the leader to build more and push the organization past 20% full adopters, or does it hollow the role out until only direction-setting and sign-off gates remain? I don’t know. It has not happened yet in my own work.

James March’s “Exploration and Exploitation in Organizational Learning”, published in Organization Science 2(1) in 1991, describes organizations trading exploitation of known practice against exploration for new practice. Applied here, a tool set that resets every few months pushes an organization back into exploration before exploitation pays. Churn alone could slow institutionalization without any leadership variable.

March explains why this is hard for everyone facing the churn. The change-agent claim tries to explain the differences between organizations facing the same churn. No speaker blamed slow adoption on fast-moving tools. The room did show how quickly a new capability could become infrastructure: the token dashboard depended on provider APIs that had not existed six months earlier, then took nine hours to build. That does not disprove March. It shows that exploration can be fast while organizational adoption remains slow.

The durability worry from Part 1 comes back here. If the labs absorb what individual practitioners build, then this room is building things that will not need to be built in eighteen months. The role’s value shifts from what these people construct to what they can judge.

By next summer, we should know whether PE demand for the role spread or was a hiring fashion. One of the six labels may have won, or hands-on work may have folded back into “engineering leader.” The share of my engineers working the way the tools permit will have moved off one in five or it will not, and I will be able to test whether visibility and peer comparison made the difference. The orchestration layer may also have eaten the enabling work I assigned to the role.

I hope to be running this same analysis next summer.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

As in last year’s piece, the people in this room are identified by role rather than by name. That was the condition of the conversation, and it holds here.

Related reading:

• 2026: The Evolution of the Leader Practitioner (Part 1) — The room, the demos, and the six names competing for the role.

• The Convergent Mind — The same gathering, one year earlier.

• The Era of the Leader/Practitioner — The full case for the role.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

In March 2025 I built a travel app. You picked a destination, talked to it, and got an itinerary you could save as a PDF. Work started March 16 and stopped April 29. A second project did the part nobody sees, collecting the travel content behind the chat, and kept going until June 11. It took roughly three months to reach the point where the product delivered the value I wanted.

A year later I built it again. The 2026 version started on April 4. By April 14 it did most of what it does today. Ten days after I started.

Same author. Same kind of product. Both still on my laptop, both with a full record of every change I ever made.

So I measured them instead of remembering them. Software keeps its own logbook. Every time I saved a batch of work, it wrote down the date, and counting those days is the closest thing a project has to a stopwatch. What follows comes from those logs, the ticket lists, and the files. Where my memory and the record disagree, I went with the record.

In July, I measured the same year from the tooling side in What A Difference A Year Makes. This is the companion at the product level.

TL;DR

• Version one was two projects and a folder I filled by hand. Four destination planners (New York, Japan, Walt Disney World, Iceland), each set up one at a time. The travel content was PDFs, notes, and data files I gathered myself.

• Version two finds its own content. 78 starter cities across 59 countries, four kinds of public event listing plus web search, and a nightly job that refills any city running low. It keeps itself fed.

• The work compressed. Version one took 14 working days on the app and 19 more on the content project. Version two took 11, April 4 to 14.

• The safety work got cheap. The 2025 app switched off the language’s own error checking in 43 places. The 2026 one does it in 5. Tests went from 53 to 151.

• The discipline is still uneven. The checks that run automatically on every change do not run those 151 tests. Every change went straight to the main branch. The written description of the app has been out of date since day one.

• My argument: the model improved, but cheap engineering discipline matters more. Even with a softer curve, within three years harnesses erase the practical distinction between software engineering and vibe coding by making tests, security, maintenance, and system fit part of generation itself.

What version one was

The 2025 app took 166 saved changes across 14 working days, March 16 to April 29.

Four destinations shipped. Each one was a separate assistant I set up by hand, with its own settings file, its own opening line, its own word list and background images. Adding a fifth meant doing all of it again. The work per destination did not come down, so five destinations would have cost five times what one did.

The travel knowledge behind the chat came out of the second project: 72 saved changes over 19 days, still going six weeks after the app had stopped. What it produced landed in a folder on my laptop holding 23 data files, 15 notes, 11 PDFs, and one text file. Downloaded etiquette booklets. Festival guides. Train-travel PDFs. And a file named, literally:

Expand this json file with another 50 new locations.md

That is the whole method in one filename. The list of places grew because I sat down and asked a model to extend it, then fed the longer list back in. Nothing ran unless I ran it, so the content was only ever as fresh as the last evening I spent on it.

What version two does on its own

The 2026 version started on April 4 with an empty project. Eleven days and 259 saved changes later, it did most of what it does today.

The largest product-level change is the content pipeline. Version one had a folder I filled. Version two goes out and gets its own material. Four kinds of public event listings feed it: public calendars, event sites, a ticketing company’s open catalog, and the details venues publish on their own pages. A web-search service adds more, one city at a time. Version one had no live search at all. I tried that same search service during the 2025 build and the results were poor. It has improved since, which is why the 2026 version leans on it.

The starting point is a list of 78 cities across 59 countries I built by hand, each with three to five local sources I picked myself: tourism boards, Time Out, local culture sites. That is a starter list. I did not count how many events are live in the app today.

The list is only the starting point.

• Every source is asked at once, with a fifteen-second cutoff each. One dead source cannot hold up the rest, and a failure gets written down instead of quietly vanishing. So a broken feed shows up as a broken feed. A city does not just mysteriously go quiet.

• The same concert reported by a listing site and by a search result collapses into one entry. A reader sees the show once instead of three times.

• A job runs every night at 06:00 UTC and goes back out for any city that has dropped below twenty listings. That is the difference between a travel app that works the day it ships and one that still works a month later.

• If the hosting service cuts that job off partway through, the job hands back its turn instead of blocking everything behind it. A second check takes over an abandoned run after fifteen minutes with no progress. Nightly work that gets stuck at 3am sorts itself out before anyone is awake to notice.

• A free first pass throws out obvious junk before anything reaches the step that costs money. Bad pages cost nothing to throw away.

• A second nightly job rebuilds every city page. New listings appear publicly without me shipping a new version of the app, so fresh content no longer waits on me.

None of that is exotic. It is the unglamorous plumbing that used to go undone.

Side by side

2025: the app plus the content project 2026: one app Separate projects 2 1 Active development days 14 + 19 11 (April 4 to 14) Saved changes 166 + 72 259 Lines of code 28,219 + 24,614 34,317 Where the travel content came from PDFs, notes, and data files I gathered by hand Public listings and web search, refilled every night Signing in Email, first name, invite code Google account behind an invite list How models were used One assistant per destination, set up by hand One model for every job Automated tests 53 + 57 151 Tickets filed 0 + 7 (all on one day at the end) 27, all closed Changes reviewed before going live 1 0

My own estimate for version one, from a retrospective I wrote in March 2025, was roughly 76 hours over the first six days. The day counts above come straight out of the log.

What got safer, and what did not

Version one had real problems, the kind that come from moving fast with nothing checking you.

Two copies of the same 57-line sign-in file sat in the project, identical down to the byte. I had started rearranging the files partway through and left the job unfinished, so both were still there. Editing one would have quietly missed the other, and that kind of bug shows up later, in the part you were sure you had fixed.

In 43 places the code switched off the language’s own error checking. That checking is what catches a mistake before the app runs. Switch it off and the mistake surfaces in front of a user instead. This was deliberate, too: the project’s written rules told me to do it, with a worked example.

Version two narrows most of those gaps. Five places switch off error checking across 34,000 lines, all of them in two files. The app checks its own inputs in 22 places before spending money on them, so a source that changes its format gets caught and thrown out before it fills the app with garbage. Nineteen files open with a short note saying why the code exists and how you would test it. Seventeen spell out the test case, so whoever touches the file next (me, months later) does not have to guess what it was meant to do.

Two of the April tickets were security holes. One let a crafted search term reach data it should not have. The other let a shared-trip link accept whatever was sent to it. Both were found and fixed the same day, in the middle of the build. A security hole gets more expensive the longer it sits unnoticed. These sat for a few hours.

Version two has its own gaps. The checks that run automatically on every change will format the code and build the app. They will not run the tests. So 151 tests exist and not one of them stands between a bad change and the live site. They help only when I remember to run them, and the whole point of an automatic check is not having to remember. No change ever waited on review by anyone, including me. The app’s written description still describes the empty project it started from on April 4, so a person reading it learns nothing about what the app became.

The tickets and the notes came earlier than I remembered. I have said I brought them in “in the latter part” of the build. Tickets existed from day one. The first twelve were filed on April 4, the same day as the first saved change, as a list of things I wanted. Then they sat, and were closed in a batch five months later rather than one at a time as each feature landed.

The stretch where the tracker was doing live work is tickets 13 through 24, filed and closed on April 6 and 7: two security findings, six cleanup and safety fixes, a data-quality fix, a speed fix, a dead-code removal, and one feature. File, fix, close, same day or the next. That is the middle of the burst, not the end of the project.

The design notes tell a cleaner story. Twenty-four dated documents, every one written between April 4 and April 12, alongside the build. Which framework to move to, how to shape an itinerary, how to search one city well. Writing the reasoning down while the decision is still fresh is what separates a project you can pick back up from one you have to work out again from scratch.

What I think the difference is

Almost every 2026 saved change carries a line naming the AI model that helped write it: 253 of 279. The build ran Claude Code through claude-mpm, a tool I wrote that runs a set of AI agents the way a manager runs a small team. It is a harness, the software that sits between a person and a model, turning a request into steps, running them, and checking what comes back. It did not exist when version one was built. Version one’s saved changes carry the older form of that line, with no model named: the coding tool on its own, nothing coordinating above it. I recall using a second AI coding tool alongside it that year, though nothing in either project confirms it.

The model improved over the year. Version one used one company’s assistant service, one assistant per destination, because that was the tool available. Version two sends eight or more different jobs through a single small fast model: reading an itinerary, pulling events out of a page, writing a plan, translating a foreign-language listing, judging whether a listing is worth keeping. It gets usable results from all of them. One model, one place to watch the bill.

The bigger share of the gap is that the work around the work got cheap. In 2025, writing a safety check, a note with an expected test case, a browser test, and a ticket for every unit of work would have cost more time than the work itself. So I skipped nearly all of it, and what I got was four planners sitting on a pile of content I fed by hand. In 2026 that same wrapper is close to free, because the thing writing the code also writes the check, the test, and the ticket. What I got, in a third of the days, keeps its own listings current, unsticks its own nightly job, and screens its own inputs before spending money on them.

The self-refilling city list is the clearest example. “Check every city each night, find the ones running low, and go get more” is a simple idea. It is also boring, fiddly plumbing with awkward edge cases, and in 2025 it would have been the thing I meant to do and did not. It exists now because handing it off was cheaper than putting it off.

Two things limit all of this. I got better at this over the year, and with two projects and a log I cannot separate my improvement from the tooling’s, so some unknown share of the gap is me. Both projects were also solo, unreviewed, and low stakes. Nothing here says what happens with a team, a compliance boundary, or a customer contract.

What this points at

Version one needed me to know things. What an assistant setting did. Why a stored login needs a date it stops working. What half-finished file rearranging does to a project over the following month. Version two needed less of that from me, because the parts that required it were the parts I handed off.

The model wrote the code in both years, more or less. What changed is everything around the code. The harness broke the work into steps, filed the ticket, wrote the test, caught the security hole the same afternoon, and left a note explaining why the code was there. I brought the idea, a travel app that keeps its own listings current, and the judgment about whether what came back was any good. The system handled the steps in between.

Two projects cannot prove a three-year forecast. Here is mine anyway.

The curve will soften. Legacy systems and organizational limits will slow it, especially where regulation raises the cost of being wrong. Even after that discount, I think the practical distinction between software engineering and vibe coding disappears within three years.

Today, vibe coding means prompting for a result without much discipline around how the result is produced. Software engineering is the work surrounding the code: architecture, tests, security, maintenance, and fitting a new piece into everything already running. The harness is pulling that work into the generation loop. It will not make every decision right. It will make reliable engineering the default instead of a cleanup phase after the prototype.

That changes the economics of code. As software gets cheaper to make, code by itself is worth less. The scarce part is how well it fits the larger system and how much real-world value the system creates. I made that bet with Trusty, putting the harness and its supporting tools into the open rather than treating the code as the moat.

I expect more software to move into the open-source ecosystem for the same reason. The tools will also get better at searching what is already there, understanding whether it fits, and integrating it before writing another copy. Cheap generation makes rebuilding easy. A good harness will make reuse easier still.

The second project is live at tripbot.tours. One caveat: I am paying for the scraping and hosting myself. If enough people use it to overwhelm that budget, I will have to shut it down or sell it. For now, it is there to try.

Two projects, one author, a year apart. The second is bigger, cleaner, and more capable, and it took a third of the days.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related reading:

• What A Difference A Year Makes. The same year measured at the tooling level, comparing two of my own developer projects

• AI Power Ranking. Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter. Strategic AI insights for CTOs and engineering leaders

Six months into my job, the PE firm that owns the company asked me to help its portfolio companies find people who run engineering organizations and still build things themselves. Leaders, up to their elbows in the work.

Two years ago, I’m not sure I could have told them where to look. I probably would have recommended against it. It ran counter to my management philosophy: “you’re not being paid to do things, you’re being paid to lead.” As head of engineering for Tripadvisor, I heard an enduring story from my coach about the “do nothing” manager, someone who expressed his value entirely through delegation. Not a bad lesson...back then.

When this group first met in my living room in June 2025, nine people fit the description, including about half of those who came back this year. Not one of us had a name for it. I wrote that afternoon up as The Convergent Mind, published June 25, 2025. Read back now, it is a careful catalog of what those people believed and a blank space where the thing they had in common should have been.

We convened a similar room on July 24, 2026. There were ten people, and six had built something to show. In twelve months the role acquired at least six competing names.

TL;DR

• A year ago the hands-on leader was rare enough that a room full of them had no shared word for it. Now the role carries at least six circulating labels, and the PE firm that owns the company I work for has asked me to source people who fit it.

• LeadDev’s survey program reversed itself inside twelve months. Its June 2025 reporting had hands-on opportunities for leaders drying up under budget pressure. Its 2026 report (n=600) has 37% of leaders doing more hands-on technical work and 33% of managers considering a move back to individual contributor.

• That same 2026 report also has 45% working more hours and 41% reporting team motivation down.

• The scale of what a single practitioner builds changed categorically. In 2025 the frontier in this room was prompt scaffolding and a CRM made of Markdown files. In 2026 it was token-cost governance with FinOps conversations at CFO level, agent monitoring as its own sub-discipline, and personal systems resolving years of accumulated data behind an agent interface.

• A counter-current showed up that the 2025 conversation had no room for. One founder in the room thinks the advantage any of us build individually is temporary, because the frontier labs will absorb it.

What a Leader-Practitioner Is, and Why AI Made It Possible

The role is easy to describe. Someone who runs an organization and does hands-on technical work as a deliberate part of the job, not in the gaps between meetings. The work has a recognizable shape: internal tooling, agentic harnesses, MCP connectors, a DX platform layer other teams depend on. Work that enables production rather than sitting on its critical path. At startups, that can extend to production code. I know more than one where the CTO writes all of it.

What changed is the time-and-cost proposition. Directing a team of agents is close enough to delegation that it fits inside a leadership mindset, which sustained hand-coding rarely did. Now you specify intent, review what comes back, correct, and direct again. A fifteen-minute attention window can produce something that used to need an uninterrupted day.

I made the full case for the archetype, where it comes from, and why it was rarely adopted for most of the last forty years in The Era of the Leader/Practitioner, published June 1, 2026. This piece is about what happened to the role in the past year.

A Year Ago This Was Rare. Now Companies Recruit for It.

The signal I trust most is that capital is staffing for it. A private equity firm asked me to help find these people for companies it owns, and a startup I advise already has one. I’m informally helping a few others. A year ago, I had not seen anyone recruit against this description because the job did not exist in a form you could put in a posting.

The survey data moved the same way, and fast enough to cause whiplash. LeadDev’s June 2025 reporting described hands-on opportunities for engineering leaders as having dried up. Its 2026 Engineering Leadership Report (n=600) has 37% of leaders doing more hands-on technical work and 33% of managers considering leaving management for an IC track. One survey program, one year apart, and the message reversed.

The same 2026 report has 45% working more hours and 41% reporting team motivation down. It records leaders doing more technical work inside organizations that are, by their own account, more tired.

What has not happened is agreement on what to call any of it. Gergely Orosz predicted the player-coach in 2024, and the term is heavily used in LeadDev’s coverage as recently as July 27, 2026. Addy Osmani introduced loop engineering at O’Reilly Radar on June 22, 2026. “Agent orchestrator” circulates widely, including one vendor calling it the most important job of 2026. “Founder mode” has been around since Paul Graham wrote up Brian Chesky in September 2024. Simon Willison offered “vibe engineering” in 2025 as the serious counterpart to Karpathy’s vibe coder. Mine is leader-practitioner, which makes six labels for one job. James Stanier’s “The End of the Non-Technical Engineering Manager”, for LeadDev on April 20, 2026, skips the naming problem and describes what the role displaces.

The description cuts across titles. I opened the introductions by calling one person there the most emblematic of the era we were in. His reply:

“I’m 61 years old and this is the first time I’ve been emblematic of an era.”

He was not an engineer at all, and he stayed on the same note when he introduced himself:

“Everybody remember Coco, the gorilla who learned sign language? I think I’m sort of that in this room.”

That was a longtime marketing consultant who shipped his first piece of software, ever, this year. Its market fits in one sentence:

“My market is people who have one to three short-term rental properties that they self-manage and are scared shitless of losing money.”

An angel investor who had come up through IT consulting put the same impulse differently:

“Having been a technologist for most of my career, I can’t let new tech get away from me.”

And then:

“I think probably there’s at least 50,000 other people building the exact same thing.”

The 2025 piece did not anticipate this. It described nine people who had converged on nearly identical conclusions about how software gets built. It closed on new patterns and organizations. It had a great deal to say about what we thought and little about what we were.

The Scale Changed

The group changed more than its headcount. What one person now runs would not have been buildable twelve months earlier, and the problems people brought to the room only exist at the new scale.

An advisor who works with engineering leaders on AI adoption had turned the agents in his personal system into a named executive team:

“Sloan’s my head of engineering. Louise is my editor in chief. Morgan is my chief operating officer. Ren is my head of design.”

He also had a cross-lab failover rule. If Anthropic went down, one switch would move the system to another lab’s models within minutes.

The head of engineering at a research firm demoed a token dashboard. It started with a bill nobody could explain:

“So, yes — this is something I built in about nine hours. Why was it built? We were going through a token-maxing issue — a really bad token-maxing issue, where nobody knew how much they were spending.”

Six months earlier, the provider APIs behind that dashboard did not exist.

A Brooklyn-based startup operator and fractional CTO had arrived at monitoring from the other end, watching his own agents rather than his own spend:

“I have a Hermes agent that runs. I’m always trying to throw more work at it. So I kind of built a tool to help keep tabs on what it’s doing.”

His tool is deterministic rather than agentic, runs roughly a hundred monitors, and feeds a self-remediation loop back into the agent it watches. He introduced it with no ceremony whatsoever:

“So this is called, I call this ‘Glance’.”

Both people built instrumentation for processes they no longer needed to watch directly. Those processes existed because of the AI tools they had added. No one in the 2025 group brought a problem like that.

The angel investor did not demo, but the people who presented were not the only builders. He described a personal system that pulls his accumulated records into a single graph, resolves the same person across the addresses and jobs they have moved through, and sits behind an agent interface he can ask to brief him before a meeting. In Is Your Digital Brain the Light Saber?, I argued that building your own knowledge system rather than renting a generic one separates practitioners now. He built one, though he does not write software for a living.

Technical terms have become vernacular. The marketing consultant, describing what he liked in a recent model release, reached for a term the room’s engineers use as jargon:

“The thing that I really liked about Fable is that it introduced the idea of the adversarial review.”

A serial founder supplied a counter-current the 2025 conversation had no room for. He had built something and concluded that the market for it was disappearing:

“Two weeks — less than two weeks into that, I realized shit, the problem I solved is going away. It’s financial.”

“The combination of mixture-of-experts models and optimized model routing are probably going to eat a lot of that.”

The 2025 piece framed convergence as validation. This group took for granted that the value of individual construction is shrinking while the volume of it grows.

Software generation rose even as its durability decreased. Ten people who fit a description that barely existed a year ago spent an afternoon comparing instrumentation for systems they did not need to observe back then. My own engineering organization, meanwhile, still operates much as it did last year. The tools are everywhere: JetBrains’ August 2026 follow-up, based on more than 15,000 professional developers surveyed from May through July, found 90% using AI coding agents at work at least weekly and 68% using them daily. Most do not work like we do. Part 2 is about that gap.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

As in last year’s piece, the people in this room are identified by role rather than by name. That was the condition of the conversation, and it holds here.

Related reading:

• The Convergent Mind — The same gathering, one year earlier, and the piece this one grades.

• The Era of the Leader/Practitioner — The full case for the role, including where the archetype comes from.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

Some of the strongest engineers I know won’t work with coding agents, at least not at the level I’d expect. A bit of Cursor yes, some Claude -- but it’s an add-on, not fundamental harness loop engineering. Just as likely, they are uncomfortable with it because they have never had to practice the skill it takes.

They see the problem quickly. They know the part of the codebase that needs to change, the shortcut that will fail in production, and the test that will catch it. Then they give an agent two sentences, watch it head in the wrong direction, and take the keyboard back. Ten minutes later the change is done.

Their conclusion is reasonable: I can do this better myself.

For that one task, they may be right. But they have skipped a different piece of engineering. They moved from idea to code. Agentic development inserts a middle layer:

idea -> communication -> outcome

That middle layer is delegation. It means deciding which context another actor needs, which decisions belong to them, what cannot change, how the result will be evaluated, and when the work needs to come back. A manager has to do this with people. Coding agents have made it an individual-contributor skill too.

We teach engineers how to solve problems. We teach design, decomposition, testing, and code review. We spend far less time teaching them how to make their understanding usable by somebody else.

I think that explains a meaningful share of the gap between engineers who get substantial output from agents and engineers who find them irritating. The evidence does not prove delegation skill is the sole cause. It does show that expertise can make instruction more abstract, that experienced developers do not get an automatic productivity gain from AI, and that successful agent use depends heavily on problem framing and evaluation.

TL;DR

• Solving a problem yourself and specifying it for another capable actor are different forms of work. Agentic development makes engineers practice the second one.

• Experts can be poor instructors because their knowledge has become compressed. A Stanford study found experts gave more abstract, less concrete instructions than beginners.

• In roughly 400,000 Claude Code sessions, people made about 70% of planning decisions while Claude made about 80% of execution decisions. The human job did not disappear. It moved toward intent and evaluation.

• Useful delegation defines the outcome, relevant context, decision authority, evidence of success, and a return path. It leaves implementation room inside those boundaries.

• Engineering organizations should teach and assess delegation alongside system design, testing, and code review.

Strong Engineers Short-Circuit the Middle

Expertise is compression.

A senior engineer does not consciously replay every step required to diagnose a stale cache, unwind a dependency cycle, or recognize that an innocent schema change will break an old consumer. Years of experience have turned those steps into pattern recognition. That is part of what makes the engineer fast.

It can also make the engineer a poor source of instructions.

In a 2001 Journal of Applied Psychology study, Pamela Hinds, Michael Patterson, and Jeffrey Pfeffer asked experts and beginners to give novices instructions for an electronic circuit-wiring task. The experts used more abstract and advanced statements, with fewer concrete statements. Novices taught by beginners performed better on the same task and reported fewer problems with the instructions.

The expert instructions had a different advantage. Novices taught by experts transferred what they learned more successfully to another task in the same domain. Abstraction was useful, but it was pitched at the wrong level for immediate execution.

That is a close description of many failed agent sessions. The engineer supplies the concept because the missing steps no longer feel like steps. The agent supplies its own version of those missing steps. Then the engineer calls the output stupid.

Sometimes it is. Coding agents make bad decisions, miss local conventions, and produce code that passes a narrow test while violating the system around it. But “the agent should know that” often means “I knew that and failed to communicate it.”

The distinction gets lost because explaining the work feels like overhead to somebody who can already do it. Delegation is slower than execution until the delegated system starts producing more than one person’s hands can.

Seniority Does Not Produce an Automatic AI Gain

A strong counterweight to AI productivity anecdotes remains METR’s randomized study of early-2025 coding tools. Sixteen experienced open-source developers completed 246 tasks in repositories where they averaged five years of prior experience. When AI tools were allowed, completion time increased by 19%.

The developers expected a 24% speedup before the work. Afterward, they still estimated that AI had made them 20% faster.

This is a historical result, not a verdict on current models. The study mostly used Cursor with Claude 3.5 and 3.7 Sonnet. METR later changed its follow-up design after more developers declined to participate because they did not want to work without AI, which introduced selection bias. The researchers also warn against treating their original participants as representative of software development as a whole.

Still, the result closes off one comforting assumption: being good at a codebase does not make somebody good at directing an agent through it. The participants knew their systems. They had substantial AI experience. They could choose whether to use the tools. And in that setting, the tools cost them time while feeling faster.

METR did not test my delegation thesis. It measured the gap I am trying to explain.

Agentic Development Splits Planning From Execution

Anthropic’s June 2026 study of roughly 400,000 Claude Code sessions offers a clearer picture of the work split. Its classifiers attributed about 70% of planning decisions to the person and about 80% of execution decisions to Claude.

Planning included what to do, which approach to take, and what counts as done. Execution included which files to change, what code to write, and which commands to run.

This is delegation in software form. The person retains the problem and the acceptance decision. The agent gets a bounded decision space inside it.

Anthropic also found that novice-rated prompts led to around five agent actions and 600 words of output, while expert-rated prompts led to about 12 actions and 3,200 words. Sessions rated intermediate or above reached Anthropic’s strict verified-success measure 28% to 33% of the time, compared with 15% for novice-rated sessions. When sessions ran into trouble, expert-rated users recovered more often.

There is a circularity in those numbers. Anthropic’s expertise classifier partly looked at how precisely a person framed directions, what they asked Claude to verify, and whether they corrected the model. Those are delegation behaviors. The study shows that the behaviors travel with longer agent runs and higher measured success, but it cannot tell us how much each behavior caused the result.

The occupational result is still suggestive. In code-producing sessions, management occupations finished slightly above software occupations on the strict verified-success measure, though Anthropic says managers may be more likely to state explicitly that they got what they wanted. A skill learned by directing people may transfer to directing software agents.

Small qualitative studies point the same way. In a 2026 mixed-methods study of senior and junior engineers, Dana Feng, Bhada Yun, and April Yi Wang found that senior engineers maintained control through detailed delegation. They scoped changes, supplied context, delegated smaller units, asked for minimal reviewable diffs, and refined the work through feedback. The junior engineers moved between over-reliance and cautious avoidance.

Ten juniors and ten seniors are not a population. But the described behavior will be familiar to anybody who has watched one person steer an agent while another person alternates between accepting everything and taking the work back.

From Hub to System

An engineering leader recently described his problem to me as being “too much in the hub.” Teams waited for him to make decisions. Work crossed his desk because he knew the history, the risks, and how the parts fit together. His competence had become part of the system architecture.

So he started moving ownership outward. One leader took a product area. Another took day-to-day operational work. The change was not a pile of redistributed tickets. Each person received a decision space and a return path.

Senior individual contributors create the same topology when every difficult change routes through them. Doing the work faster reinforces it. Soon the engineer is both the source of expertise and the queue in front of it.

Coding agents make that topology visible because they are always available to receive work. If nothing can move without the engineer touching the implementation, availability was not the constraint. The system had no interface for the engineer’s judgment.

Delegation builds that interface. A useful handoff answers five questions:

Decision Question Outcome What observable state should exist when the work is done? Context Which system facts and prior decisions affect the work? Authority What may the delegate decide or change without asking? Evidence Which tests, traces, screenshots, or artifacts establish success? Return path When should the delegate stop, ask, or escalate?

This applies to a person, an agent, or a group of agents. The amount of detail changes. The information contract does not.

Delegate Outcomes, Not Motions

“Implement this endpoint” delegates motion. The instruction names an activity and leaves the purpose, production bar, ownership boundary, and failure conditions unstated.

An outcome-level delegation describes the state the system must reach. It supplies the constraints that protect surrounding systems and says how to determine whether the result is acceptable. The delegate still chooses the implementation inside that space.

OpenAI’s Codex harness-engineering case study includes two good examples: service startup must finish in under 800 milliseconds, and no span in four named user journeys may exceed two seconds. Those are outcomes an agent can test. The repository exposes the application, logs, metrics, architecture rules, and remediation instructions required to pursue them.

The team did not achieve that by writing longer chat messages. It made the environment carry repeatable context. Plans became versioned artifacts. Architecture constraints became linters and structural tests. The agent could inspect the same evidence used to judge its work.

That team reported around one million lines across code, infrastructure, tooling, and documentation, with roughly 1,500 pull requests opened and merged over five months by three engineers directing Codex. OpenAI estimates the product took one-tenth the hand-written time. The more durable lesson is in their account of the slow start: progress was poor while the environment was underspecified.

I have seen the same pattern in my own work. Trusty Tools, the Rust-based multi-agent system I have been building since May 19, reached 3,200 commits and 3,426 closed GitHub issues by September 3. The current checkout contains roughly 1.46 million lines across code, documentation, and configuration formats.

Those are activity metrics. They do not prove the software is good. They do prove I was not typing every change myself.

The work moved when I stopped treating the agent as autocomplete and started treating the repository as an operating environment. Instructions became code-adjacent. Review rules became executable. Agents received narrow authority and had to return evidence. Failures fed changes back into the system instead of becoming one-off corrections in a chat window.

Delegation Has a Cost

Good delegation takes time. That is a feature, not a bug. It is why strong engineers resist it.

Vincent Schmalbach’s June 2026 pilot study on software delegation contracts compared ordinary issue-style prompts with explicit contracts covering the task, authority, returned work package, and acceptance context. Across 64 runs on ten small TypeScript tasks, every run passed the hidden acceptance tests. The contracts did not improve correctness because the tasks were already easy for the agents.

They improved reviewability. Evidence sufficiency improved in 22 of 30 paired comparisons and worsened in none. Reviewers saw more changed-file lists, known limitations, residual risks, and checklists. The contracts also used 13% more agent tokens and took 38% more wall-clock time.

That is a good trade only when reviewability is worth the cost. On a tiny task you will do once, it may not be. On repeated work, risky work, or work distributed across several actors, a reusable contract can pay for itself because the next handoff starts with an interface instead of another explanation.

Delegation also fails when it becomes abandonment. Giving somebody an outcome does not transfer away responsibility for the problem framing, the quality bar, or integration with the larger system. Autonomy needs a boundary and a feedback loop.

In one leadership model from my notes, exploratory work happened in a sandbox against broad targets. Useful results returned to an owner who could productionize them. The exploration was allowed to fail. The production handoff was not.

That distinction matters with agents. “Go figure it out” can be appropriate when the blast radius is small and the work is exploratory. It is negligence when the agent can change production state and nobody has defined how it returns evidence.

Teach the Skill

Delegation should appear in engineering development before somebody becomes a manager.

Code review already gives us the right setting. Ask an engineer to write the issue another engineer could implement without a private briefing. Ask what the assignee can decide, which constraints are real, which test would change the author’s mind, and when the work should come back. Then evaluate the handoff alongside the patch. Architecture exercises can do the same. A candidate should be able to design a subsystem and divide it into owned outcomes with interfaces between them.

Senior promotion rubrics should look for expertise that travels: working agreements, executable checks, useful documentation, and teams that can make decisions without routing every question back through the expert.

Engineering education is beginning to move this way. After two 2026 roundtables with roughly 30 to 40 academic and industry participants each, Sungmin Kang, Baishakhi Ray, and Abhik Roychoudhury argued that future engineers should learn to translate intent into machine-checkable specifications and evaluate whether those specifications capture the intended result. They also put agent orchestration and verification into the proposed curriculum.

I would call the umbrella skill delegation.

The engineer who can do everything is not necessarily the engineer who can create the most throughput. Agentic development rewards the engineer who can make judgment portable without pretending judgment has disappeared.

We will still need people who can solve the hard problem themselves. They are the ones most able to recognize a wrong abstraction, an unsafe shortcut, or a test that proves less than it claims. But if all of that understanding remains inside one person’s implementation process, it can guide only one stream of work.

The goal isn’t to do less engineering. It’s to move more of the engineering into a form that other capable actors can use.

Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform, and writes about AI-augmented engineering practice. Previously, Bob has been CTO of Tripadvisor, Citymaps, and Runtime Technologies.

Related reading:

• What Is Harness Engineering? (And Do You Need to Learn It?). Why the system around the model determines how much useful work it can do

• AI Power Ranking. Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter. Strategic AI insights for CTOs and engineering leaders

On August 10, after a phrase had shown up for the ninth time, I typed this into a Claude Code session running Opus 5:

“the load-bearing section” this is too jargon-y. Do not use language like this (add it to tm output style)

Forty-nine minutes later, the rule was live in trusty-tools:

No borrowed-metaphor jargon. “Load-bearing” is the instance that prompted this rule... Wrong: “that section is load-bearing” / Right: “deleting that section breaks X”.

I had seen it nine times in two days. Opus 5 used “load-bearing” for a constraint, then a crate, then a test suite, all in six sessions on August 9 and 10. I got tired of reading it, so I banned the word.

I remembered a much worse week. In my version, I fought with Opus 5 for days, switched to Fable 5, and everything got better. Then I checked my logs.

Across eight days, I typed 201 messages to the two models. The record is boring: no capability problems, no ALL-CAPS, no profanity, no “that’s not what I said.” I was calm and typo-heavy throughout (agents understand intent well enough that my typing has gotten worse). The switch to Fable happened in the middle of a session without a command or comment from me.

The window’s one documented correction appears secondhand, inside an auto-generated summary. It concerned version-bump authorization. My complaint about Opus 5’s prose came two days earlier. I remembered a fight, but the logs recorded something else.

Meanwhile, Opus 5 produced 1.37 million words of output on real engineering tasks, next to Fable 5’s 193,000 words. The capability argument was gone. I was left with the way it talked.

TL;DR

• My trusty-tools logs show zero capability problems with Opus 5 over the window that supposedly caused a switch to Fable 5. My original thesis was wrong.

• Across the month-long sample, Opus 5 opens sentences with “worth noting/naming/knowing” 10.7x more often than Fable 5 (0.451 vs. 0.042 per 1,000 words).

• A recurring metaphor (something “wearing” something else’s clothing) shows up 26 times across 12+ Opus 5 sessions and zero times anywhere else in the sample.

• Eight named developers across Hacker News and X say they prefer GPT-5.6 Sol specifically for how it communicates. None turned up making that same claim on Reddit.

• The voice predates Opus 5. A GitHub issue filed 11 days before it shipped describes the same tics, and Claude Code gives Opus 5 a system prompt a bit over a third the length of Sonnet 5’s.

How Opus 5 Talks

The trusty-tools bans landed between August 10 and 12. From August 12 onward, the same rule applied to every model: no “worth noting,” no “load-bearing,” no borrowed-metaphor jargon, and none of the “honest/honestly” family. The month-long counts also include earlier output, so this is not a clean post-ban comparison. It is a record of how often the patterns appeared in the logs I have.

The sample covers July 28 through August 27 in the same repository: 9,148 Opus 5 turns (1.37M words) and 2,732 Fable 5 turns (193K words). Opus 5 averages 149.5 words a turn on equivalent status-update and engineering tasks, more than double Fable 5’s 70.5.

On a routine GitHub API check, Opus 5 wrote:

Worth noting how it verified: its first PATCH used -f description=@file, which isn’t a real gh api shorthand...

Later, in a SlotRegistry design note:

It’s load-bearing for assertion B, it’s about to be cited in an ADR, and right now nobody but you can retrieve it.

The “wearing” metaphor got under my skin. Opus 5 used some version of it 26 times across at least 12 sessions that month. A conflict resolution became “unreviewed code wearing a rebase’s clothing.” A misattributed fact came back as “a hypothesis wearing a rule’s clothing.” A faster teardown was “a regression dressed as a performance win.” Fable 5 produced zero in 193,000 words. The thinner Opus 4.8 and Sonnet 5 samples produced zero too.

Fable 5, working the same repository, the same kind of task, under the same ban:

Error arms proven load-bearing (swallowing provider errors turns four tests red)...

You’re right, and the honest accounting is that the day went to the plumbing that kept invalidating runs...

The pinned gate run is genuinely green.

Fable used the same forbidden words, but less often. The “worth noting” family appears roughly a tenth as often.

“Honest” is the exception. Opus 5 sits at 0.193 per 1,000 words against Fable 5’s 0.176, close enough to call a wash. The other gaps run from roughly 2x to 10.7x.

Developers Recognize the Voice

On Hacker News alone, I found 29 items from April through August 2026 about Opus 5’s communication style. Roughly 55 people joined the complaint. The highest-engagement thread, “Why does Opus 5 feel worse to work with?”, sits at 993 points and 873 comments. Two Ask HN threads pose nearly the same question: “Which is the least sloppy and claudeism free model you have used?” (July 25) and “Why are Claude models so verbose?” (August 26).

On X, 13 tweets with verifiable URLs carry the same complaint from 11 distinct authors, dated July 24 through August 19.

By comparison, eight named people across both platforms say they prefer GPT-5.6 Sol specifically for how it communicates: six on Hacker News (including matheusmoreira: “Opus has a distinctive sentence structure and Fable somehow manages to be even more obtuse”), plus two on X: Emmett Shear (”Talking to Opus makes me angry and depressed in a way that’s hard to articulate. It’s actually somehow worse than Sol”) and yacineMTB (”Meh. Switched back to sol. I am trying to get shit done not be hypnotized by a robot”).

The 816-point thread that gets cited most often in this argument, “Anthropic’s best AI model struggles to attract users as cheaper tools thrive,” is a price story. One top comment calls the output “peak verbosity vomit,” but the thread itself is about pricing pressure from cheaper models, not a referendum on tone.

These quotes come from Reddit aggregator blogs that include thread names, usernames, and vote counts. One step removed. The style complaint still shows up with its own vocabulary: “essay of slop,” “Claudeslop,” “benchslop,” and “load-bearing” appear independently across multiple write-ups as stock Opus 5 language. But I could not find a single Reddit thread where someone says they prefer Sol because of how it talks. The Sol arguments there are about benchmarks and price. Two threads praise Fable 5’s voice over Opus 4.8, which says nothing about Fable 5 versus Opus 5.

Counted across the Hacker News threads read for this piece: “load-bearing” appears 83 times, “verbose” 69, “honest/honestly” 66, “jargon” 34, “seam(s)” 36.

The Voice Predates the Model

GitHub issue #77136 was filed July 13, 2026, eleven days before Opus 5 shipped. It documents “load bearing,” invented jargon, “hand-waving,” “reflexive hedging,” and “honest framing” in Opus 4.7, Opus 4.8, and Fable 5. The complaint is older than the model now taking the blame.

Claude Code also gives Opus 5 a system prompt of roughly 11,000 characters with almost no anti-verbosity instructions. Sonnet 5 gets about 29,000 characters, much of the difference made up of rules that suppress this behavior. In the published test, restoring the longer prompt changed the behavior. The model may supply the prose, but the harness decides how much restraint to ask for.

And somebody made the opposite switch. Manu Parasuraman moved from Sol to Opus 5 because Sol was harder to read: “Sol answers questions nobody asked in language nobody speaks,” while Opus 5 “walks you through its reasoning and stays concrete.”

I started this piece assuming Opus 5’s personality was the whole problem. The system-prompt evidence complicates that: I may be hearing Claude Code’s prompt as much as the model underneath it, then blaming the name in the model picker.

What This Comparison Can and Can’t Show

The 10.7x gap is descriptive. It combines output from before and after the bans, and it does not tell me what either model would say on an empty prompt. Sonnet 5 contributed 13 turns from one session, too thin to rate. GPT-5.6 Sol never appears in the trusty-tools logs, which means every Sol comparison here comes from other people rather than my own measurement. The Reddit material is secondhand because the primary site was unreachable during research.

Ten Days Later, Anthropic Shipped a Concise Style

Anthropic reportedly shipped a built-in Concise output style for Claude Code on August 20, according to a third-party writeup. That was ten days after my rule landed and six days after the 993-point Hacker News thread. I haven’t checked whether it helps. I prefer my own.

The logs explain why I wrote the rule. Opus 5 completed the engineering work, at scale, while repeatedly talking past an instruction written for it in plain English. I don’t call that a capability failure, but it is a product problem. The rule stays in trusty-tools.

Bob Matsuoka is CTO of Duetto, a hospitality revenue-management platform, and writes about AI-augmented engineering practice.

Related reading:

• When Sessions Talk — What 375 messages between my own Claude Code sessions said to each other

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

In June of 2025 I predicted that Chinese open weight models would set the LLM pricing floor. The piece pointed at DeepSeek-V3 and DeepSeek-R1 turning up in the cheap tiers of tools like Windsurf and said “these will likely become the new baseline for price-sensitive usage.” I wrote it a month after a $622 Anthropic bill (up from around $50 the month before) and after burning a $20 Zed plan’s entire monthly allocation in a few hours. My reasoning was this: the frontier providers were selling inference below cost, the subsidy would end, and the cheap models were waiting underneath.

I gave it two time windows. The tighter one sat with the claim that “Chinese competition will eventually drive costs down significantly,” following “a period—probably 6-12 months—where usage-based pricing hits hard.” That one ran out around June. The looser one sat with a broader claim, that Chinese pressure would “eventually drive down pricing across the board,” with the caveat that “eventually” might be 12-18 months out. That one runs to December.

The first window failed outright. The second is failing in a direction I didn’t anticipate: not that the floor held, but that the floor is about to go up.

DeepSeek’s own API pricing documentation now carries this: “We plan to raise the overall pricing for DeepSeek API services in the near future, with a significant increase expected.” No percentage. No effective date. No list of affected models. The South China Morning Post, which reported the notice, has DeepSeek telling developers that specifics are “to be advised later” and that “users should plan their usage accordingly.” SCMP attributes the pressure to demand for DeepSeek-V4-Flash-0731, a 284-billion-parameter model released on July 31, a week before the notice went up.

The company I expected to set the floor has signaled it will raise it. The labs I expected to raise prices spent the last four months cutting prices or raising limits.

TL;DR

• In June 2025 I gave Chinese models two windows to set the price floor: 6-12 months, and 12-18 months. The first ran out around June 2026. The second runs to December, and DeepSeek is now warning of a “significant” price increase with no figure and no date attached, confirmed on its own pricing docs, not just in press coverage.

• Over the same stretch the frontier moved the other way. Anthropic doubled Claude Code’s 5-hour limits and dropped peak-hour throttling (May 6). OpenAI split its $200 Pro tier into $100 and $200 tiers running identical models, differing only in usage volume (April 9). Google cut its top Gemini subscription from $249.99 to $199.99 (May 19).

• On July 30 OpenAI cut GPT-5.6 Luna by 80%, to $0.20 input and $1.20 output per million tokens. Multiply DeepSeek V4-Flash by ten and it lands at $1.40/$2.80: 3.6x to 7x under Opus 5 and Fable 5 on input where today it is 36x to 71x under them, and more expensive than Luna.

• OpenAI’s stated reason for the cut was efficiency: 20% lower serving costs and 15%+ better token-generation efficiency. That covers a 20% cut. Terra got 20%. Luna got 80%.

• The rationing I predicted did happen, one layer down. Cursor converted flat billing to metered credits in June 2025. GitHub Copilot moved to token-metered AI Credits on June 1, 2026, at unchanged sticker prices.

What DeepSeek Disclosed

V4-Flash lists at $0.14 per million input tokens and $0.28 per million output, with cache hits at $0.0028. V4-Pro lists at $0.435 and $0.87. Those are the pre-hike numbers. DeepSeek disclosed neither the size of the increase nor when it lands. Any number you see attached to this story is somebody’s guess.

A “significant” increase off a base that low still leaves room. Double V4-Flash and it sits at $0.28/$0.56, cheaper than most of what the frontier sold a year ago. The magnitude we don’t know yet. The direction we do, and that is the part I called backwards.

The Frontier Went The Other Way

Anthropic doubled Claude Code’s 5-hour rate limits on May 6 for Pro, Max, Team, and seat-based Enterprise plans, and removed the peak-hours limit reduction for Pro and Max. Max 5x is still $100 a month. Max 20x is still $200. Both buy more than they did in the spring.

On April 9 of this year, OpenAI split its $200 Pro tier into $100 and $200 tiers running identical models and differing only in usage volume. That’s a second fixed-price plan at Claude Max’s number. Neither tier is uncapped. OpenAI doesn’t publish the Pro-model allowance on either, and running it out soft-degrades you to a smaller model rather than cutting you off.

Google restructured AI Ultra at I/O on May 19. The single $249.99 tier became $99.99 at 5x Pro limits and $199.99 at 20x, with daily prompt caps replaced by compute-weighted 5-hour refresh and weekly metering. The top tier alone dropped $50.

Who GPT-5.6 Luna Is For

Then came July 30. OpenAI cut GPT-5.6 Terra from $2.50/$15 to $2/$12, a 20% reduction. It cut GPT-5.6 Luna from $1/$6 to $0.20/$1.20, an 80% reduction. The stated reason, from OpenAI’s own account: “20% lower serving costs from production GPU kernel improvements. 15%+ better token-generation efficiency from improved speculative decoding.”

That explains Terra. Twenty percent cheaper to serve, twenty percent off the price, a straight pass-through. It doesn’t explain Luna. The same kernels and the same speculative decoding produced a cut four times larger on the cheaper model. Efficiency gains don’t sort themselves by tier. Pricing decisions do.

Max plans holding steady is not by itself evidence that providers depend on volume. Falling serving costs cover that on their own. A lab building a tier at the bottom of the market and then cutting it 80% in a single move is harder to explain that way, because a $0.20 input tier is not where a company with a $5/$25 flagship model makes its money. It’s where a company goes when it wants a number that reads lower than DeepSeek’s.

Two months ago I wrote that dealers give the first one away for a reason, and that the Max plan was my first bag. The habit runs in both directions. A dealer who keeps cutting the price of the first bag is a dealer who can’t afford to have you buy it somewhere else.

Run my June 2025 claim forward against a tenfold hike. DeepSeek disclosed nothing supporting that multiple or any other, so it’s a stress test, not a forecast. V4-Flash at ten times list: $1.40 input, $2.80 output. Against the models people think of when they say “frontier”, a multiple survives. Claude Opus 5 at $5/$25 is 3.6x the input price and 8.9x the output. Claude Fable 5 at $10/$50 is 7.1x and 17.9x. GPT-5.5 at $5/$30 is 3.6x and 10.7x. Those are reduced from much bigger numbers. At today’s list price Opus 5 costs 36x what V4-Flash does on input and 89x on output. A tenfold hike takes about ninety percent of that away. At 36x, price picks the model. At 3.6x, the model does.

Further down the market it reverses. Against Luna at $0.20/$1.20, a tenfold-hiked V4-Flash costs seven times more on input and more than twice as much on output. Against Gemini 3.6 Flash at $1.50/$7.50 it’s roughly a wash on input. Even Gemini 3.1 Pro at $2/$12 for prompts at or under 200k tokens (above that it goes to $4/$18) sits within 1.4x on input (4.3x on output). Run the stress test and the frontier ends up priced below the discounter, not for the flagship but for the tier built for exactly the work I said DeepSeek would take.

The Case Against

Three things complicate this reading.

DeepSeek’s prices track chip supply, not just strategy. The company cited “constraints in high-end compute capacity” when it priced V4-Pro in April 2026, a constraint widely linked to US export controls on Nvidia H20 chips, though DeepSeek didn’t specify. In late May it made a 75% V4-Pro price cut permanent without saying why, on timing that lines up with easing Huawei Ascend 950 supply. The August notice gives no reason at all, though SCMP’s reporting points at demand for a model released the week before. I can’t tell a capacity bottleneck from a strategic retreat from outside the company.

The rationing happened at the consumer level. Cursor replaced flat request-based Pro billing with usage-based credits pegged to API cost in June 2025, then ran a refund program from June 16 to July 4 after users got painful bills. GitHub Copilot moved from flat Premium Request Units to token-metered AI Credits on June 1, 2026, at unchanged sticker prices, with the code-review multiplier rising to 13x for legacy annual-plan holders. Anthropic added weekly caps on top of its 5-hour caps in August 2025, citing round-the-clock usage and account resale, and estimated at announcement that they would “apply to less than 5% of subscribers based on current usage.” Model-lab sticker prices held. The metering moved to heroin layer.

The efficiency explanation may be the whole explanation. Serving costs have fallen steeply, and Anthropic’s gross margin has reportedly climbed off a deeply negative base, roughly -94% in 2024. The Information reported in January 2026 that Anthropic had trimmed its own projection to about 40% for 2025, still a steep climb off that base. If cost per token falls faster than price per token, generous Max plans need no dependency on volume to explain them. My reading rests on the 20/80 split between Terra and Luna, and that’s one data point on one day from one vendor.

What Would Prove Me Wrong Again

The June 2025 piece got the $200 line right, which was the easy part. What I got wrong was which end of the market was fragile. Any of these would tell me I’m getting it wrong a second time.

• DeepSeek publishes numbers and the increase is under 2x on V4-Flash, leaving it under $0.30 input. That would be a capacity adjustment — the floor is where I thought it was.

• OpenAI raises Luna back toward $1 within two quarters. If that happens, July 30 was pass-through of a real engineering result, and I read a price war into it.

• Anthropic or Google restores throttling, or cuts 5-hour allowances at unchanged prices, before the end of 2026. That would mean the generosity was a promotional window, and June 2025 was early rather than wrong.

• The tool layer keeps metering while the model labs keep expanding: the pricing pressure was sitting at the tool layer the whole time, and both of my previous pieces were aimed at the wrong tier.

• DeepSeek’s hike lands and its API volume holds anyway — which would mean price wasn’t what price-sensitive buyers were choosing on.

If you’re budgeting against a Chinese-model price floor for 2027, price in the possibility that the floor is now a frontier lab’s customer-acquisition tier.

Bob Matsuoka is CTO of Duetto, a hospitality revenue-management platform, and writes about AI-augmented engineering practice.

Related reading:

• The Other Shoe Will Drop — The June 2025 prediction this piece corrects.

• The Other Shoe Has Dropped — Why per-token price cuts stopped reaching the invoice.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

GPT-5.6 Sol scores 80 on the Artificial Analysis Coding Agent Index against 77 for Claude Fable 5, at a lower cost per task (about $1.04). That post went up on July 9.

I called model parity back in April, in a piece with a section headed “GPT-5.4 Caught Up.” What I missed was everything around the model: that OpenAI would close the product gap, and buy a decade of compute while doing it.

Over the last few months I’ve been using ChatGPT more and more for work-like tasks. Not Duetto work, because we don’t have an enterprise plan and Duetto material stays out of it. Work-like things. Both the capabilities and the UX have improved to the point where I’d put the product at least on par with claude.ai, to my surprise. There are still gaps. It’s still good.

TL;DR

• GPT-5.6 Sol leads the Artificial Analysis Coding Agent Index 80 to 77 over Claude Fable 5 (July 9) and Terminal-Bench 2.1 85.77% to 84.64% over Claude Opus 5 (July 22), the second one with a methodology caveat that widens the gap.

• Claude Opus 5 still leads the broader Artificial Analysis Intelligence Index at 60.7 against GPT-5.6 Sol’s 58.9 (July 29). Anthropic’s remaining model lead is general capability, not agentic coding.

• Anthropic leads on revenue ($47B run-rate, May 28, 2026) and valuation ($965B), and leads enterprise API share 40% to 27% (Menlo, December 2025). OpenAI closed the capability gap and most of the product gap while trailing commercially.

• OpenAI is far ahead on planned compute (Stargate at nearly 7GW toward a stated 10GW commitment, the Broadcom “Jalapeño” inference ASIC). In July it moved its usage limits three times in seventeen days, in both directions, around a near-global outage on the 25th. Anthropic has been raising its limits since May.

• No open-weight provider I found fields an app ecosystem within reach of ChatGPT or Claude Code, which keeps this a two-horse race even as the weights converge. Chinese domestic app numbers could complicate that.

Where the coding lead sits

Two current measures put GPT ahead on agentic coding. The Coding Agent Index lists GPT-5.6’s three effort tiers at Sol 80, Terra 77.4 and Luna 74.6, with Claude Fable 5 at 77.2 (Terra and Fable 5 land 0.2 apart). Sol’s per-task cost runs below both Fable 5 and Opus 4.8. On Terminal-Bench 2.1 (89 tasks, Terminus 2 harness, snapshot dated July 22), GPT-5.6 Sol leads Claude Opus 5 by about a point, 85.77% to 84.64%.

The Terminal-Bench result comes with a caveat from the publisher. Opus 5’s run used Claude Opus 4.8 as a refusal fallback. Count the nine affected passing results as failures instead and Opus 5 drops to 81.27%, which widens the GPT lead to roughly four and a half points. The lead is real. Its size depends on how you count.

Now the other direction. On the broader Artificial Analysis Intelligence Index, as of July 29, Claude Opus 5 sits first at 60.7 and Claude Fable 5 second at 59.9, with GPT-5.6 Sol third at 58.9. Anthropic holds the top two spots on general capability while losing the coding-agent tables. My “diminishing edge” framing was directionally right if imprecise. The edge moved. It didn’t disappear.

SWE-bench Pro, the number everybody reached for six months ago, has no usable current standing. Scale’s public-set leaderboard doesn’t list GPT-5.6, Claude Opus 5 or Claude Fable 5 at all, and the top of it reshuffled again this month. The aggregator sites quoting newer figures disagree with each other and cite at least one model name I can’t confirm exists. Skip it.

The product story is a two-way race now

This is the first half of what I missed. Codex spans CLI, IDE, web, and a hosted cloud mode for long-running tasks. The Codex CLI changelog for the last two weeks of July includes resumable sessions with paginated thread history, session naming and branching, configurable sub-agents, audio input, and an /import command that migrates project-scoped memories out of Cursor and Claude Code. That last one reads like a decision made by somebody thinking hard about switching costs. On July 9 OpenAI also folded the standalone Codex desktop app into a single ChatGPT desktop app with Chat, Work, and Codex modes. Existing Codex users were moved across automatically, and Codex remains a full mode inside the merged app.

What I notice in use isn’t a benchmark, it’s flow. Codex and GPT live in the same product, and when I go looking for something I worked on weeks ago, ChatGPT finds it wherever I left it. Claude’s Projects still behave like sealed folders for me. That isolation was an advantage once, back when context was scarce and a hard wall around what the model could see was the safer design. With current context budgets it mostly means I go hunting. GPT is also the far better image renderer, which makes for a short comparison, since Claude doesn’t ship a first-party image model at all.

Anthropic didn’t stand still while any of this happened. Claude Design shipped out of Anthropic Labs on April 17, and it’s excellent: you talk to it and get slides, wireframes, one-pagers and pitch decks, with export to PPTX or PDF, inline comments, adjustment sliders, and handoff into Claude Code. Codex has no equivalent that I’m aware of (and I’d bet real money they’re building one). Claude Cowork expanded to web and mobile on July 7. Both labs shipped serious B2B product work inside the same four months.

Capacity: a much bigger future, a strained present

The second half is compute. OpenAI is buying a much bigger future than Anthropic is, and is visibly straining in the present.

On committed buildout it isn’t close. OpenAI, Oracle and SoftBank put combined planned Stargate capacity at nearly 7 gigawatts across the Abilene flagship plus five more sites, with over $400B invested and the full commitment still stated as $500B and 10GW. Tomasz Tunguz’s aggregation of the announced vendor deals puts OpenAI’s 2025–2035 infrastructure commitment at roughly $1.15 trillion across seven suppliers, which is derived rather than OpenAI-confirmed. On June 24, OpenAI and Broadcom unveiled Jalapeño, OpenAI’s first custom inference ASIC, designed to tape-out in about nine months, with engineering samples already running Codex workloads in the lab and first production deployment targeted at gigawatt scale in late 2026 (CNBC’s coverage has the same details).

Anthropic’s disclosed commitments are significant but much smaller: up to 5GW with AWS announced April 20 (with nearly 1GW of Trainium online by year end and $100B+ committed over ten years), well over 1GW of Google TPU capacity in 2026 with the Broadcom-built expansion arriving from 2027, and more than 300MW from SpaceX’s Colossus 1. Its custom silicon is at the conversation stage, reportedly early talks with Samsung on a 2nm accelerator with nothing shipping before late 2027.

The strain shows up in the usage limits, which OpenAI moved three times in seventeen days, in both directions. Sol’s launch week doubled traffic inside 48 hours, so on July 12 and 13 it lifted the five-hour cap on Plus, Pro and Business tiers to absorb the load. On July 25 came a near-global outage, 9:17 to 11:08 AM ET, elevated errors across ChatGPT, the API and Codex, resolved the same morning. On July 29 it reset banked limits for ChatGPT Work and Codex users, whose quota Sol was burning faster than the math anticipated, then put the five-hour cap back the next day. Anthropic has been moving the other way since spring. On May 6 it permanently doubled Claude Code’s five-hour limits for Pro, Max, Team and seat-Enterprise users and dropped peak-hour throttling for Pro and Max, on the back of that SpaceX capacity.

Where Anthropic still leads

Anthropic’s remaining, potentially durable, advantages are enterprise adoption and commercial scale. Anthropic is ahead on total revenue and on valuation, and well ahead on enterprise API share. Its Series H, a $65B round closed May 28, 2026, disclosed a $47B run-rate and a $965B post-money valuation. OpenAI’s most recent confirmed figures are roughly $25B annualized (about $2B a month) at the March 31, 2026 close of its $122B round, at an $852B post-money valuation. Menlo Ventures’ December 2025 enterprise report put Anthropic at 40% of enterprise LLM API usage against OpenAI’s 27%, and at 54% in AI coding specifically. No 2026 Menlo report exists yet, so December is the current number.

So OpenAI has closed the capability gap and most of the product gap while trailing on money and on enterprise accounts. That’s the actual shape of the comeback. The lead Anthropic still holds on the Intelligence Index is general capability, and general capability is the harder thing to put in front of a CTO who’s buying a coding agent this quarter.

Apple versus Microsoft, again?

I reached for that analogy myself in May 2025, when OpenAI spent close to $10 billion in three weeks on Jony Ive’s io Products and on Windsurf, and I called it OpenAI’s Apple moment: control the stack from silicon to screen, consumer-first, design-led. Anthropic in that mapping is Microsoft, enterprise and developer-led, winning the accounts while nobody writes headlines about it.

I don’t fully trust it. Apple versus Microsoft was never settled by who had the better quarter. It ran on which company owned the layer everybody else had to build on top of, and on switching costs measured in years. Nobody owns that layer here. Both companies rent it, from Amazon, Google, Microsoft, Nvidia, Broadcom and now SpaceX. For a developer, changing frontier models is a config change and an eval run. What costs real time is changing the tool you work in, which is a much smaller lock than owning the platform. The Apple/Microsoft dynamic assumed you couldn’t leave.

The mapping also keeps slipping. Anthropic is the enterprise player in it, which is right, but it’s also the one with the bigger revenue base and the higher valuation, which is not the role the analogy assigns it.

Can either of them make money

Neither is profitable and both are burning billions, so anything past that is projection.

OpenAI’s advertising business is on pace to miss its own five-year forecast by about 90%, OpenAI projected $2.5B in ad revenue this year, scaling to $100B by 2030. eMarketer puts the entire US chatbot-ad market, not just OpenAI, under $1B this year and around $5.4B by 2030, per 24/7 Wall St. on July 21. The widely circulated 2026 cash-burn estimates in the $25B range are analyst syntheses rather than disclosures, because OpenAI is private and doesn’t publish the figures that would settle it. Same caution applies to the gross-margin numbers people quote for both companies.

Anthropic’s topline looks better but is contested. Ed Zitron argues in ”Anthropic’s ‘Profitability’ Swindle” that the near-term EBITDA profitability claim is a one-quarter accounting artifact of temporarily discounted SpaceX compute during exactly the months profitability was claimed, and that costs still rise linearly with revenue. He also flags CFO Krishna Rao’s March 9 sworn filing citing cumulative revenue “exceeding $5 billion to date” against the $19B run-rate announced six days earlier. That second point is weaker than it reads, since cumulative revenue and annualized run-rate aren’t the same measure. The first point is the one I’d want answered, and it hasn’t been.

Hardware doesn’t resolve it. Chris Lehane said at Davos in January that OpenAI’s first consumer device would debut in the ”latter part” of 2026, which is an unveiling and explicitly not an on-sale date. MacRumors reported in February that the thing is a smart speaker with a camera launching in 2027. Everything else circulating about it (screenless, voice-first, 360-degree camera, Foxconn in Vietnam) is unconfirmed. As of today nothing has shipped and no date is confirmed, so I’d file the device as a 2027 question and stop considering it this year.

Open weights are a side argument

The open-weight families are close to the frontier on raw capability. Kimi K3, the highest-scoring open model on the Artificial Analysis Intelligence Index, sits at 57, about four points behind Claude Opus 5’s 60.7 and under two behind GPT-5.6 Sol’s 58.9, the same index cited above. On LMArena the best open-weight entry, Kimi K3-max at 1491, trails Claude Fable 5 at the top by 17 points.

What none of them have is the app ecosystem. No open-weight provider fields anything within reach of ChatGPT or Claude Code on integration depth or developer reach, at least none I found, though I didn’t dig into DeepSeek’s or Qwen’s domestic app numbers in China, which could complicate that. Weights converging matters much less than it sounds like it should when the surface people work in belongs to two companies.

Which is where I end up. The model tables are the smallest part of it. OpenAI put Codex and ChatGPT in one app with an import command pointed straight at Claude Code’s users, and it has nearly 7 gigawatts of planned capacity standing behind that. Claude Opus 5 still holds the top of the Intelligence Index at 60.7, and Anthropic still held 40% of enterprise API spend as of last December. OpenAI is knocking on the door. A year ago I’d have told you that door was closed.

A coda. Could we imagine a world in which Anthropic and OpenAI run products on other models? Seems very unlikely now. But the cost of developing new models is astronomical, the cost of derived models much less (even though both companies are fighting distillation tooth and nail). So there is a world in which they use the model building work they’ve done as an audience and tool building exercise, and focus on expanding that share by expanding options, let the models fight for their own justification. Farfetched, as I mentioned, but if they start losing to application clones that use open weight models, they’re essentially inviting someone to compete. The existing assumption that the app ecosystem was just to drive captured inference falls apart if that inference is cost prohibitive. We shall see.

Bob Matsuoka is CTO of Duetto and also writes about AI business at AI Power Ranking.

Related reading:

• OpenAI’s ‘Apple Moment’: Building a Walled-Garden AI Stack — Where I first made the Apple analogy, three weeks and $10 billion into OpenAI’s acquisition run.

• It’s the Harness, Stupid — The April piece where I already conceded model parity, under a section header that says so. Everything I got wrong after that is in this article.

• I Switched to Claude.AI from ChatGPT As My Main AI Assistant — The May 2025 call I’m revisiting here, with the context-management and stability reasons that drove it.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

I made the first commit to my project, called claude-mpm, on July 24, 2025. It was a multi-agent project manager built on top of Claude Code: a Python package that gave you specialist agents, a ticket workflow, a thin memory layer, and a way to route work between them. Building the agents was most of the work, because at that time Claude Code had no notion of a subagent. You wrote your agents as Markdown, loaded them yourself, and orchestrated the handoffs by hand.

Custom subagents shipped in Claude Code on July 25, 2025, the day after that first commit.

I’m not telling this story because of that coincidence. I’m telling it because it marks a moment. In July 2025, multi-agent orchestration was something novel. A year later it’s commonplace. And that single move (capability migrating out of the code you write and into the tool you run) is a line connecting the past twelve months in agentic coding, measurable in two of my own repositories.

TL;DR

• Same author, same subscription, two eras. claude-mpm (Python) took roughly twelve months and 4,552 commits, with memory and search either hand-rolled or bolted on from outside. trusty-tools, a 25-crate Rust monorepo with first-class memory, semantic search, worktree orchestration, and PR review, came together in about two months.

• The budget held. The developer improved, but the harness and the models leapt. I spent the year getting better at driving a team of agents. Even so, most of the difference sits with the tooling, not with me. Both projects ran on the same Claude Max subscription. What changed underneath was the frontier model and everything Claude Code learned to do on its own.

• A year ago you hand-built the PM layer. Agents-as-Markdown, an external vector-search dependency, a memory subsystem you maintained yourself. Working in tickets felt like an edge.

• Now the harness carries it. Subagents nest and run in the background, worktrees are a native flag, skills and memory and search are first-class. Ticket-driven development is table stakes. Running many worktrees against one repo is my working model now.

• The safe extrapolation: The observed path is tickets → worktrees → many concurrent sessions per repo. If the next year rhymes with the last, the harness manages more parallelism than a person can hold in their head.

A year ago: you built the orchestration yourself

claude-mpm was shaped by what the harness couldn’t do at that time.

The frontier models in late July 2025 were Claude Opus 4 and Sonnet 4, which had reached general availability on May 22, 2025. Claude Code itself was about two months into GA, capable but young. Subagents didn’t exist until the day after I started. Agent Skills wouldn’t launch until October 2025. There was no native worktree support. If you wanted isolated parallel work, you ran git worktree add yourself and wired it up by hand. MCP was maybe eight months old. Memory and semantic search were not primitives the harness handed you.

So we (claude-mpm and me) built all of it. The agents were Markdown templates the package loaded and orchestrated. The ticket workflow lived in the CLI. Memory was thin by necessity, a couple of files under src/claude_mpm/memory/, and even that was on its way out. The changelog shows the memory hooks being removed and handed off to an external successor rather than maintained in-tree. Semantic search wasn’t native either. It came in as an outside dependency, mcp-vector-search, referenced across dozens of files. Worktree awareness existed at the level of a consumer that knew the concept, not a subsystem that owned it.

That was the state of the art then, and it worked. Over about twelve months claude-mpm accumulated 4,552 commits (roughly 380 a month) and grew into a real system: multiple MCP channel servers built into the Python package, a plugin path exposing 56-odd skills, agent templates for a spread of specialist roles. Ticket-driven development, routing discrete units of work through a queue instead of narrating one long conversation, felt like an advance at the time. You had to construct the scaffolding to get there, and the scaffolding was the hard part of the project.

Now: the harness carries it

trusty-tools took its first commit on May 19, 2026. It was still under active development the day I pulled these numbers. In roughly two months it reached 1,726 commits on main, about 860 a month. Same author, same Claude Max subscription, a different era.

That first commit wasn’t a blank slate. It already carried claude-mpm’s PM scaffolding, and one absorbed component holds claude-mpm session logs dated May 11, a week before the new repo existed. The Python predecessor was building its Rust successor. Then the successor began building itself: on July 6 the commit attribution switched to “generated with trusty-mpm,” in a commit that was fixing trusty-mpm’s own guard for its own subagents. Three days later the instructions moved out of CLAUDE.md into trusty-mpm’s own convention. About seven weeks were built by its predecessor before it took over its own development.

A lot shipped in that window. The frontier moved to Claude Opus 4.8 (late May 2026) and Claude Sonnet 5 (end of June 2026), with a Mythos-class model, Fable 5, arriving in June at a million tokens of context. The million-token context window had gone GA at standard pricing in early 2026. Inside Claude Code, subagents now nest several deep and run in the background by default. /fork and /subtask landed in mid-2026, and a native --worktree flag had arrived in 2026. The harness I was building on top of in mid-2026 was a different animal from the one I started claude-mpm against.

And trusty-tools reflects that, because it didn’t have to build the parts the harness now provides. It could spend that effort building capabilities further out. The result is a 25-crate workspace consisting of about 600K lines of Rust. The pieces claude-mpm hand-rolled or imported are now first-class crates of their own:

• Memory is trusty-memory, a dedicated crate with knowledge-graph operations, “dream” consolidation that compacts and reorganizes stored facts, multiple namespaced memory “palaces,” and chat-session persistence. claude-mpm had no equivalent. Its two-file memory layer was being handed off precisely because maintaining that by hand no longer made sense.

• Search is a first-class crate (semantic, lexical, and knowledge-graph search, call-chain lookup, typeahead, indexing) rather than an external MCP dependency referenced across the codebase.

• Worktree orchestration is heavy and native to the design: EnterWorktree/ExitWorktree as real operations, and fifteen-plus simultaneous live worktrees as the ordinary way of working, not a party trick.

• Ticketing is a dedicated subsystem spanning GitHub issues and JIRA, not an example command.

• And then the crates with no claude-mpm analogue at all: PR and diff review, git analytics, a code intelligence layer, a TUI, an embedding daemon.

• It also has an original (not meta) harness called trusty-code (still a work in progress but early indications are that it will perform similarly to open-code), and a personal agents harness called trusty-agents. Both leverage many of the same orchestration tools that trusty-mpm uses, which is why I’m including them in the package.

On top of that sits a catalog of 37 specialist agents over five foundation layers, and a live skill catalog surfacing more than 190 skill names, triple claude-mpm’s 56. The prompting style changed too. A year ago you spent your prompt budget teaching the model how to be an agent. Now you spend it telling a competent agent what you want, because the harness supplies the how (in the form of memory, search, specs, and tickets).

Speaking of, ticket-driven development, the edge a year ago, is now the assumed baseline. The frontier moved up a level: many worktrees against a single repo or monorepo, several sessions of work in flight at once.

The measured contrast

Two projects, one author, one subscription. Here’s the comparison. Effort and wall-clock framing are estimates. Commit counts and dates are exact. The productivity story they imply is inference.

Time to build a comparable system: claude-mpm ~12 months versus trusty-tools ~2 months, roughly a sixth of the wall-clock time.

A more capable system (25 crates with first-class memory, search, worktree orchestration, PR review, and git analytics) came together in about a sixth of the calendar time.

Commit velocity: claude-mpm ~380/month versus trusty-tools ~860/month, roughly 2.3x, though squash-merges across many worktrees likely undercount trusty-tools’ true activity.

Velocity roughly 2.3x per month. A year of tech-lead work sharpened the exact skills this way of working rewards, driving a team, now a team of agents, and holding SDLC discipline as the branches multiply. And it shows in the git record, not just in my own say-so. Three signals I can actually measure. Commit messages that name a driving issue or decision rose from roughly one commit in ten to about nine in ten. The code now logs why, not only what. The eight near-identical agent files I copy-pasted early in claude-mpm collapsed into one composed base definition, a fix I started mid-project and carried further into trusty-tools. And architecture decision records went from essentially none to eighteen numbered ADRs plus a per-crate decisions taxonomy, a habit that matured across both projects rather than one trusty-tools invented. Developer growth and harness capability compound. They push the same direction. But even with that, a person going from good to better doesn’t buy you a sixth of the calendar time. The impressive part is still the tooling.

Capability checklist across three columns, a year ago, now, and a speculative year from now, for orchestration, memory, search, worktrees, skills, ticketing, and PR review.

Every row that read “you build this” a year ago reads “the harness provides this” now. Multi-agent orchestration: hand-built then, native flag now. Memory: thin and hand-maintained then, a knowledge-graph crate now. Search: external dependency then, first-class now. Worktrees: DIY shell commands then, a --worktree flag and fifteen live trees now.

The harness now enforces the workflow, not just supplies the parts. Spec-linked documentation was a prompt hint in claude-mpm, off by default. In trusty-tools it’s a build-blocking lint gate (trusty-sld-lint) wired into CI and pre-commit. Documentation that fails the build, not documentation you’re reminded to write. Ticket discipline hardened the same way: that rise in issue-referenced commits now sits inside a codified chain (spec → issue → PR-linked-to-issue → review gate → squash-merge), process-enforced, not yet a hard check that rejects an unlinked PR. And claude-mpm’s main branch required zero approvals and no passing checks, protected in name only. trusty-tools’ main requires a review approval and six passing CI checks, with an LLM review pass (trusty-review) as a named gate. A year ago a disciplined developer chose these. Now the harness refuses to merge without a review and passing checks.

A word on the subscription plan

Claude Max was announced in April 2025 at $100/month (Max 5x) and $200/month (Max 20x), with usage shared across chat and Code. Those price points appear to have held from then through mid-2026. The most visible change over that whole span was the five-hour rate limits for Claude Code, which Max subscribers draw on, being doubled in mid-2026. More headroom, not a different product tier.

So the input that stayed roughly constant was the money and the person. The input that changed was the model quality and the harness capability. When you hold the developer and the budget still and the output grows by this much, the variable that moved most would be the model and the harness (mostly the model, though in my experience good memory and search make a huge difference), even granting the developer improved and the language changed.

A year from now

The trajectory has a clear shape: tickets → worktrees → multi-session parallelism. Working in tickets was novel in mid-2025 and is common sense now. Native worktrees arrived in early 2026 and, within months, running many of them at once became my working model rather than a demo. Each step took a workflow that used to live in the developer’s head (tracking the units of work, isolating the parallel branches) and moved it into the tool. There are no hard adoption statistics for this progression. I’m describing a tooling timeline and a direction, not a measured majority practice. The tooling timeline itself is real, though: worktree support arriving across editors and agents through late 2025 and into 2026 follows the same curve.

The next frontier isn’t hard to name. If tickets became common sense and worktrees became my working model, the thing after worktrees is many concurrent sessions against one repo or monorepo. Enough parallel work in flight so that no human is tracking all of it, and the harness keeps the branches, the memory, and the review gates coherent. The /fork and /subtask primitives that landed in mid-2026, and subagents running in the background by default, are early moves in exactly that direction. The developer’s job shifts further from writing the steps toward specifying the outcome and reviewing the merge.

That’s not a prediction of artificial general anything. It’s the same migration, run one more turn: complexity leaving the code you write by hand and entering the tool you run. A year ago the hard part of the project was the scaffolding. This year it’s the harness. Next year it’s the coordination of more parallel work than one person can follow. So that one person gets pushed further up into the spec and the design.

What a difference a year makes

I built claude-mpm, and I’m very proud of it. For its moment it was a good answer to a real constraint. That’s the ordinary fate of scaffolding once the platform grows the feature underneath it, the design working as intended.

The measure of the year isn’t that I got better, though I hope I did. It’s that the same person, on the same max plan, with the same working habits, could build a materially more capable system in a fraction of the time, because the models got sharper and the harness absorbed the work that used to be mine to do. Twelve months of hand-built PM layer on one side, two months of composing first-class parts on the other. Same author. Same subscription.

What a difference a year makes.

Bob Matsuoka is CTO of Duetto and also writes about AI business at AI Power Ranking.

Related reading:

• It’s the Harness, Stupid — Why orchestration, not raw model quality, drives the spread in outcomes — the mechanism underneath this whole comparison.

• What Is Harness Engineering? (And Do You Need to Learn It?) — The durable skill under the tooling: designing the loop, not just the scaffolding.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners.

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders.

An engineer at work asked me a good question last week. “What’s harness engineering, and do I actually need to learn it — or is it going to be obsolete by the time I do?” Fair question. The term is about five months old, half the people using it mean different things by it, and the people who build the most capable coding agents around keep going on record to say the thing you’d build will get absorbed into the next model.

So here is my answer, stated plainly, because I think most engineers are getting it wrong: harness engineering is the most important skill you can build right now beyond coding and architecture themselves. And the strongest evidence that it matters is that most engineers don’t yet believe they need it.

I’ve been writing harnesses for over a year, so treat that as a disclosed bias rather than a neutral survey. What follows argues against the smartest version of the other side — the case that harness work is disposable scaffolding the models will eat for breakfast — because that case is largely correct, and it still doesn’t touch the skill I’m talking about.

TL;DR

• Harness engineering is real but young. The phrase traces to Mitchell Hashimoto in February 2026 and an OpenAI Codex case study days later; Fowler and Böckeler formalized it as “Agent = Model + Harness.” Report it as an emerging frame, not a settled discipline — and no “harness engineer” job title exists yet.

• The labs are right that the crutch layer shrinks. Anthropic’s Cat Wu says “the models will eat your harness for breakfast”; Boris Cherny says scaffolding gets “pushed into the model itself.” No one at Anthropic said “don’t learn it.”

• The benchmark fight lives at the crutch layer. Same model, different scaffold moves scores by up to 28 points on GAIA and 18.6 points on Terminal-Bench 2.0 — but Agents’ Last Exam shows model choice drives roughly 3x the spread of harness choice. Scores were beside the point.

• The skill lives at a layer the benchmarks don’t measure. Not a better crutch — a different unit of work: research → spec → ticket → build → PR → review → merge → deploy, driven by the harness. OpenAI ran that loop with 3 engineers to ~1M lines and 1,500 PRs with zero human-written code.

• Harness engineering is not IDE engineering. If you treat the harness as an extension of your old editor workflow, you cap your ceiling. The durable move is letting it drive and jumping in when needed.

• Yes, you need to learn it. The specific syntax is throwaway. That’s exactly why the skill matters — you’re learning to operate a new unit of work, not one vendor’s config file.

The question, stated bluntly

Start with what “harness engineering” is even asking you to do, because the word carries two arguments at once and people talk past each other constantly.

I already made the case that orchestration beats model quality in It’s the Harness, Stupid back in April — same model, large spread in outcomes, the competitive edge moving from model superiority to ecosystem superiority. That piece defined what a harness is and showed that it dominates results. I’m not going to re-argue it. This is the follow-up question that piece left open: if the harness matters that much, is building one a skill worth learning — or a treadmill that resets every model release?

That distinction is the whole article. Because the answer the evidence points to is: parts of it reset every release, and the part that doesn’t is the part almost nobody is naming. Most of the public argument is being had about the parts that reset.

What a harness actually is

The cleanest definition comes from Martin Fowler and Birgitta Böckeler: “the harness” is everything in an AI agent except the model itself. Agent = Model + Harness. They split it into guides that push instructions forward and sensors that feed results back, and they frame the whole practice as a specific form of context engineering. Simon Willison puts it the same way from the other direction: a coding agent is software that acts as a harness for an LLM.

When I say “using a harness,” here’s the concrete inventory I mean:

• Agents — the loop that calls the model and routes its tool calls, plus any sub-agents you dispatch work to.

• Skills — reusable capabilities you can invoke by name instead of re-explaining every time.

• Hooks — deterministic gates that fire on events: run the tests, block a commit, reformat on save.

• Workflow — the orchestrated path from research to deploy, and who (or what) drives each step.

• Harness-specific instructions — how this harness should behave, kept distinct from project-specific instructions about this codebase. Conflating those two is one of the most common configuration mistakes I see.

• Memory and search — what persists across sessions, and how the agent retrieves it.

Internalize that inventory before you touch any tool, because every product arranges these pieces differently and calls them different things. Hugging Face is the one source I’ve found that formally separates the scaffolding (the behavior layer — prompts, tool descriptions, memory) from the harness proper (the execution layer that calls the model and decides when to stop), then notes that most products just call the whole bundle a harness. That ambiguity is real, not something to paper over: the term is contested, some practitioners call it an old idea in new packaging, and Latent Space literally ran a piece titled “Is Harness Engineering Real?”. I don’t want to oversell a five-month-old buzzword. I want to separate the durable part from the disposable part, and to do that I have to give the skeptics their strongest swing first.

“The models will eat your harness for breakfast”

Here’s the skeptical case in its own words, and it’s a good case.

Cat Wu, who heads product for Claude Code, has a line for it: the models will eat your harness for breakfast. Her team does a system-prompt audit on every new model and deletes the reminders the model no longer needs. Her example: a to-do enforcement tool built to stop Claude Code from overclaiming that a refactor was finished became dead weight once newer models completed multi-step refactors on their own.

Boris Cherny, who created Claude Code, says the same thing from the architecture side. In an Every.to interview, he described the tool as “the thinnest possible wrapper over the model” and said that as models advance, “stuff that used to be scaffolding... gets pushed into the model itself.” His team builds harness features they expect to delete: “we build most things... even if that means we’ll have to get rid of it in three months. If anything, we hope that we will get rid of it in three months.” Disposable on purpose. And at Sequoia’s AI Ascent this spring he extended it forward — prompt-injection defenses, static command verification, permission modes, human-in-the-loop gates would all become less critical, he argued, “because models will do the right thing themselves.”

This isn’t only an Anthropic view. It’s the bitter lesson applied to agents: building in how we think the work should be structured tends to lose, over time, to raw capability and scale. Han Lee makes the practitioner version bluntly: “Almost all of it is going to dissolve into the next generation of models... build each production harness like you mean to replace it.” Tool wrappers dissolve because models read OpenAPI specs directly now. Elaborate memory layers collapse into “plain text in progress.md plus git log.”

Two concessions I’ll make up front, because the fair version of this argument requires them. First: nobody at Anthropic said “don’t learn it.” The claim that they did is a paraphrase — a real cluster of “the harness shrinks” statements from Wu and Cherny, compressed by repetition into something stronger than anyone actually said. Second, and this is the one that stings: even the benchmark evidence for harnesses says model choice usually wins. On Agents’ Last Exam, swapping models with the harness fixed produced an 18-point pass-rate spread; swapping harnesses with the model fixed produced about 6. “The model accounts for about 3x the pass-rate spread of the harness.” If your goal is a higher number on the leaderboard, buy the better model before you tune the scaffold.

So the skeptics have a benchmark, a bitter lesson, and the people who build the reference implementation all pointing the same way. If I stopped here, the answer to “do you need to learn it” would be “not really — wait for the next model.” I don’t stop here, because all of that is arguing about a layer I don’t mean.

Why both are right — and why it doesn’t touch the real skill

The reconciliation is that “harness” names two different things, and the argument above is entirely about the first one.

The first layer is scaffolding-as-crutch. A hook that reminds the model to actually run the tests. A tool wrapper that translates an API the model can’t yet read. A permission gate that catches a mistake the model still makes. Anthropic’s own framing nails why this dissolves: “every component in a harness encodes an assumption about what the model can’t do on its own.” When the model can suddenly do that thing, the component becomes dead weight — exactly Wu’s deleted to-do tool. This layer is supposed to shrink. Anthropic builds it disposable on purpose. The benchmark gaps live here too: the 28-point GAIA swing and the 18.6-point Terminal-Bench spread measure how much a scaffold props up a fixed model’s score. Prop-up value falls as the model climbs. That’s the whole skeptical case, and it’s correct.

The second layer is workflow orchestration. Letting the harness drive the entire loop — research → spec → ticket → build → iterate → PR → review → merge → deploy — as one continuous operation instead of a sequence of prompts you babysit. This layer does not dissolve into a better model, because a better model doesn’t decide what’s safe to run unattended, what the blast radius of an autonomous change is, or where a human judgment call has to sit. Better models make the loop run better. They don’t make the loop design itself.

Blake Crosley draws the same line and I think it’s the sharpest version: harness syntax is ephemeral and gets absorbed, but verification judgment is durable — knowing what’s safe to run without watching, what the acceptable failure modes are, where the loop needs a gate. The config file you write today is throwaway. The judgment about how to structure autonomous work is not.

The killer piece of evidence sits in the phrase’s own origin story. When OpenAI published its harness-engineering case study, the headline number was three engineers producing roughly a million lines of code across 1,500 pull requests, with zero human-written code, by engineering the harness around Codex. Read that carefully. That is not a better crutch bolted onto a fixed workflow. It’s a different unit of work — the engineers stopped writing lines and started operating a loop. No model upgrade alone produces that shape of output, because the shape is a workflow-design decision, not a capability. Ryan Lopopolo’s summary of what changed is the tell: the only scarce resource left was synchronous human attention. That’s an orchestration problem, and no amount of model progress makes it go away.

This is why I can concede the entire benchmark argument without losing anything. Model choice beats harness choice on scores — sure, roughly 3x on Agents’ Last Exam. But the fight over scores is being had at the crutch layer, and the skill I mean lives at the orchestration layer, which those benchmarks don’t even measure. Even the strongest model still needs someone who knows how to hand it a whole workflow instead of a single task.

Harness engineering vs. IDE engineering

Here’s the crux, and it’s where I think most engineers cap their own ceiling without noticing.

The biggest difference between harness engineering and IDE engineering is what the unit of work is. In the editor era — including the AI-autocomplete-in-your-editor era — the unit is a change you make, assisted. You’re still driving. The tool suggests, you accept, you commit. A good harness inverts that. The unit becomes an outcome you delegate: research through deploy, handled by the harness, with you supervising the loop rather than typing inside it.

If you approach a harness as an extension of your existing editor workflow — a faster autocomplete, a smarter pair — you’ll get some lift and you’ll hit a ceiling fast, because you’re still the bottleneck on every step. The results I’ve gotten that actually surprised me came from letting the harness drive the whole loop and jumping in only where my judgment was needed: at the spec, at the review, at the “is this safe to merge” gate. That maps exactly onto Crosley’s durable skill. You’re not writing less carefully. You’re spending your attention on the decisions that don’t delegate, and letting the loop own the ones that do.

This is a materially different workflow from anything I did before agents, and I say that as someone who’s lived through several supposed paradigm shifts that turned out to be the same job with new keybindings. This one isn’t. The muscle you build isn’t “prompt the model well.” It’s “decompose an outcome into a loop a machine can run mostly unattended, and know precisely where to stand in it.” Harrison Chase, who runs LangChain, frames harness engineering as an extension of context engineering, and that lineage is right — context engineering is about a year old and settled, harness engineering is the newer, contested layer on top. But the operative verb changed. You’re not composing a context window. You’re operating a workflow.

Do you need to learn it? Yes — here’s how

Yes. The fact that it still feels optional is the problem, not a reason to wait.

Here’s the path I’d suggest, and it’s roughly the one I took.

Start by understanding what using a harness means — the inventory from earlier: agents, skills, hooks, workflow, harness-specific versus project-specific instructions, memory, search. Not as vocabulary. As the actual pieces you’ll arrange. If those seven words don’t map to concrete settings you can change, start there before you touch a workflow.

Try several, and configure them well. Don’t judge the category from one tool on defaults. Learn to tune Claude Code yourself until it performs, rather than running it out of the box and concluding the harness “doesn’t matter.” Try Codex, Gemini, Auggie, OpenCode. I built claude-mpm, so weight my enthusiasm for the multi-agent approach accordingly — the point isn’t which one wins, it’s that you can’t feel the shape of the skill from a single vendor’s config.

Lean into the differences instead of smoothing them over. The instinct is to find the tool that feels most like your old editor and stop. The results live in the opposite direction — in the workflows that feel least familiar, where the harness drives and you supervise. Best results come from leaning into what’s different, not translating it back into what you already knew.

Let it drive, and know where to stand. This is the whole skill in one sentence. Hand the loop the outcome, supervise at the gates your judgment actually owns, jump in when the blast radius or the ambiguity demands it. That standing-in-the-right-place instinct is what transfers across every tool and survives every model release.

And that’s the reframe I’ll close on. Everything about the specific harness you learn this quarter is throwaway. The config syntax, the exact hooks, the tool wrappers — Han Lee is right, the next model eats away at it. But that’s precisely why the skill is worth building, not a reason to skip it. You’re not learning one vendor’s settings file. You’re learning to operate a new unit of work — an autonomous loop from research to deploy — and that competence is the thing the model upgrades keep raising the value of, not erasing. The syntax is disposable. The judgment about how to run the loop is what compounds.

Most engineers will figure this out eventually, when the workflow shift is obvious in hindsight. The ones who figure it out now get a head start measured in the gap between “my editor got smarter” and “my unit of work changed.” I’d rather be early on that one.

One layer up: loop engineering

There’s a move past the harness, and it picked up a name while I was writing this.

The stack is starting to read like a ladder: prompt engineering, then context engineering, then harness engineering — and now loop engineering on top. Each rung stops being where you spend your attention once the rung below it gets good enough to trust. You quit hand-tuning prompts when context engineering settled into a roughly year-old, mostly-solved practice. The bet underneath loop engineering is the same shape one level up: once your harness is solid, you stop prompting the agent and start designing the loops that prompt it for you.

The term isn’t mine. Addy Osmani formalized it in June, and his definition is the one I’d hand someone first: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” He also collected two lines that land the shift faster than I can. Peter Steinberger’s version: you should be designing the loops that prompt your agents. And Boris Cherny — the same Cherny from the “eat your harness for breakfast” section — put it flatly: “I don’t prompt Claude anymore… my job is to write loops.” LangChain picked it up a week later, and their framing is the practical one: you don’t build a loop, you stack them — an agent loop inside a verification loop inside an event-driven loop inside a hill-climbing loop, each one checking the one below it.

Here’s the seam between the two layers, drawn plainly. Harness engineering is the discipline of building the scaffolding — the agents, hooks, skills, gates, and workflow from the inventory up top. Loop engineering is what you do once that scaffolding is good enough that you stop typing prompts and start directing repeatable cycles. The harness is what you build. The loop is what you run on it, again and again, with your attention moved up to which loops to run and when to trust them unattended. That’s the same “let it drive, know where to stand” instinct from a few paragraphs back, pushed one rung higher: now you’re not standing inside the loop at all — you’re choosing which loops get to run.

I’m not planting a flag here. The people already naming it are out ahead of me, and that’s the reason to point at it — this is where the harness work goes next, not a term I’m coining. If harness engineering closes the gap between “my editor got smarter” and “my unit of work changed,” loop engineering is what shows up on the far side of that gap, once the unit of work is a cycle you supervise instead of a task you run. I’m watching that one closely. And I’d start learning it before it feels obvious.

Bob Matsuoka is CTO of Duetto and also writes about AI business at AI Power Ranking.

Related reading:

• It’s the Harness, Stupid — The predecessor to this piece: same model, wide spread in outcomes, and why the competitive edge moved from model quality to orchestration. It defined what a harness is; this piece argues that building one is a skill worth learning.

• HyperDev’s Three Golden Rules — The working rules I keep coming back to for professional AI work, and the discipline that keeps a driven-by-the-harness loop from running off the rails.

• Claude Sonnet 5 Takes the Default Driver Slot — A concrete example of the crutch layer shrinking: adaptive thinking folds interleaved reasoning into the model, removing work harness authors used to do by hand.

• Loop Engineering — Addy Osmani’s June 2026 piece that named the layer above the harness: once the scaffolding holds, you stop prompting the agent and design the loops that prompt it. The forward edge of the arc this article traces.

• The Art of Loop Engineering — LangChain’s treatment of loop engineering as stacked loops — agent, verification, event-driven, hill-climbing — each one checking the one beneath. The practitioner’s map of where harness work heads next.

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners, including the coding-agent leaderboards this piece leans on.

In 2019, comedian Gary Gulman released an HBO special called The Great Depresh. The title puns on the 1930s collapse, but the special is about Gulman’s own clinical depression — the hospitalization, the electroconvulsive therapy, the long climb back. He calls it “depresh” throughout. The diminutive is the point: “depression” was too heavy to say out loud for years, so he found a smaller word that let him talk about it at all. The special ends on a line he delivers like a weather report: “My depresh is in remish.”

Something adjacent is moving through the developer community, and most people don’t have a name for it yet. It isn’t burnout, and it isn’t fear of replacement, though that gets blamed for it. It’s a specific malaise in senior engineers who, by outward measures, are doing fine — shipping more, faster, with tools that work. They feel worse anyway. Call it the Coding Depresh.

The Depresh is real, it’s documented, and there’s a path out that doesn’t require pretending the loss isn’t a loss. I write from an unusual position. I spent eight years as CTO of TripAdvisor managing more than 560 engineers, mostly not writing code, and I missed it. I came back to hands-on coding in March 2025, entirely through AI tools — my re-entry and AI-assisted development are inseparable. I never had to grieve a pre-AI coding identity, because I didn’t have one to defend. That gives me a strange vantage point on the engineers who did.

TL;DR

• The Coding Depresh is identity disconfirmation, not job-loss fear: when the thing you built your professional self around gets automated, “who am I as a developer?” stops having an easy answer.

• It’s documented. A 15-year veteran describes shipping an AI-built pipeline and feeling grief “for an identity.” Stack Overflow’s 2025 survey shows distrust in AI accuracy (46%) outrunning trust (33%) for the first time, even as usage climbed to 84%.

• The most-cited evidence that AI slows experienced developers — METR’s 2025 trial showing them ~19% slower — has been retired by the same researchers, whose redesigned data now points the other way. Even the skeptics’ own number moved.

• A different camp — the Energesh — reports feeling more capable, not less. The fault line isn’t seniority or skill. It’s your answer to “who are you as a developer.”

• The most useful question I’ve seen comes from an Anthropic engineer: “I thought that I really enjoyed writing code, and I think instead I actually just enjoy what I get out of writing code.” Where you land tells you where you live.

• For engineers in the Depresh, and the CTOs managing them: the craft instinct that makes the tools feel wrong is the most valuable thing you own. It doesn’t have to die for you to adopt the tools.

The Depresh is real, and it’s documented

Start with the most precise account I’ve found. George Violaris, a developer with fifteen years’ experience, wrote in March 2026 about shipping a data pipeline with AI assistance in an afternoon — work that would have taken him three days by hand. He expected pride. He got this instead:

“That evening, I felt something I can only describe as grief. Not for a person. For an identity.”

He goes on: “Three years ago, writing code wasn’t just what I did. It was who I was.” Then: “The ego death was real. ‘I am a person who writes excellent code’ had to die.”

This is not a man worried about his next paycheck. He shipped the thing. The pipeline is in production. What broke wasn’t his employment; it was the relationship between his sense of self and the work. Most of the public conversation treats developer anxiety as a labor-market story — real, severe for junior developers, but separate, and not the one I’m writing about.

The Depresh I’m describing hits a different person: the experienced developer whose answer to “who are you?” was “I am the person who writes excellent code.” For that person, the tools don’t threaten the job first. They threaten the identity first.

The numbers underneath the mood are strange. Stack Overflow’s 2025 Developer Survey, the largest census of working developers we have, shows two lines crossing. Favorable sentiment toward AI tools fell from 77% in 2023 to 60% in 2025, while usage or intent to use rose from 70% to 84%. People are adopting tools they feel worse about. Trust in AI accuracy dropped to 33% against 46% who distrust it — the first year distrust outran trust — and the top frustration, cited by 66%, was “AI solutions that are almost right, but not quite.” The most experienced developers are the most skeptical: only 2.5% “highly trust” the output, and use it all day anyway. Working with something you don’t trust, that demands verification you can’t delegate — that’s the exhaustion of vigilance without resolution.

Then there’s the METR study — less for the number most people quoted than for what happened to it. In 2025 the nonprofit METR ran a controlled trial with experienced open-source developers and found them 19% slower with AI assistants while they believed they’d been roughly 20% faster. That became the most-cited evidence that the tools don’t pay off. Then in February 2026 the same team retired it, writing that the original no longer reflects “the current impact of AI models on open-source developer productivity”; their redesigned measurement runs the other way, an estimated 18% speedup for the same returning developers. The intervals are wide, so the magnitude is soft — but the direction reversed, and why it had to be rebuilt is the tell: 30 to 50% of developers refused to submit tasks they expected AI to speed up, and many refused to work without AI at all. The measurement broke down because people won’t give up the tools. I read the original not as “the tools are bad” but as disorientation: when your instincts and the stopwatch disagree, then a year later the stopwatch reverses, your competence comes unmoored.

There is another camp, and it’s also documented

Here is what keeps the Depresh from being the whole story. A different group of engineers is having close to the opposite experience, and they’re not naive optimists or vendors.

Andrej Karpathy named the moment in February 2025: “a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He was describing a feeling, not a methodology. Simon Willison later coined “vibe engineering” for the responsible professional version — engineers using these tools deliberately to accelerate real work.

The output side is loud. Pieter Levels built a browser flight simulator with no game-development background and reached around $1M in annualized revenue in 17 days. Boris Cherny, who leads Claude Code at Anthropic, runs five parallel instances and ships 20 to 30 pull requests a day: “once there is a good plan, it will one-shot the implementation almost every time.”

This is where my own story sits. When I came back, the mechanics of typing code line by line weren’t part of my working identity — I’d been away from the keyboard for years. What I found waiting was the part I’d missed: building things, deciding what should exist, watching it take shape, fixing what’s wrong with it. The joy of building and the mechanics of writing code were never the same thing.

I can be concrete, because I’ve done it in the open. Since March 2025 I’ve shipped real, full-cycle software through these tools — not snippets, complete projects. The flagship is claude-mpm, a multi-agent orchestration platform for Claude with a real user base. Most of 2025 was Python; then in 2026 I taught myself Rust to build the trusty-* ecosystem — code search, memory, PR review, orchestration — something I wouldn’t have attempted by hand while running an org. Architecture, review, releases, the full loop, at a volume I couldn’t reach typing every line. Most of it is public on GitHub under bobmatnyc, so the claim is checkable. I’m not theorizing about the Energesh. I’m living in it.

What actually separates the two camps

Not seniority. Not raw skill. Not the domain you work in, though each shades the experience. The fault line is the answer you’d have given, before any of this started, to a single question: who are you as a developer? There’s an older version of the same split.

In the early nineteenth century the canuts were the silk weavers of Lyon, clustered in the Croix-Rousse district, working intricate patterns by hand. It was master-craft work, identity-defining — the skill lived in the fingers. Then Joseph Marie Jacquard demonstrated a loom that wove those same complex patterns automatically, driven by punched cards, doing in a single pass what had taken the weaver and an assistant by hand. The canut whose sense of self lived in the act of weaving, in the tight and skilled handwork itself, was displaced at the identity layer. The canut whose relationship was with the silk itself, the finished cloth, still had somewhere to stand. The fabric still got made. More of it, in fact. If your identity comes from the tight weaving rather than from seeing the cloth made, you are a Canut.

Coding has the same shape. If your answer to “who are you” was inseparable from “I am the person who writes the code” — the line-by-line authorship, the mechanical understanding of every decision, the craft of it — then AI arrives at the identity layer, not the job layer. Violaris’s grief is the correct, proportional response; it scales with how much of himself he invested. If your answer was closer to “I am the person who builds the thing that exists at the end,” the same tools feel like a gain. You were always pointed at the cloth, not the weave. The result just got cheaper to make.

There’s a quiet irony in the comparison. Jacquard’s punched cards are a direct ancestor of the computer — they ran on into Babbage’s Analytical Engine and later Hollerith’s tabulators and the IBM punch card. The mechanism that displaced the weaver became the machine the coder works on, now automating a layer of the coder’s craft too. Same lineage, one more turn.

The cleanest articulation comes from an Anthropic engineer, quoted in Anthropic’s own internal research on AI-assisted work:

“I thought that I really enjoyed writing code, and I think instead I actually just enjoy what I get out of writing code.”

That is the skeleton key. Most developers in the Depresh believe they love writing code, and they’re not wrong, exactly — but the two halves of that sentence always came bundled. You couldn’t get the output without the authorship. AI unbundles them. Do you love the writing, or what the writing gets you? Where you land tells you which camp you’re in, and it’s not always where you assumed.

Kent Beck’s vocabulary dissolves a false worry. He distinguishes augmented coding from vibe coding. In vibe coding you don’t care about the code, only the behavior. In augmented coding you care deeply about the code, its complexity, its tests — “it’s just that I don’t type much of that code.” The Energesh isn’t about lowering your standards: the taste and architectural judgment that took decades to build are still doing the real work.

David Heinemeier Hansson gives the sharpest version of the craft objection. DHH spent most of 2025 resisting agent-first coding, and his reason was a craft reason. On Lex Fridman’s podcast he said the joy is to type the code himself; he keeps AI in a separate window because letting it drive made him “feel competence draining out of [his] fingers.” He has since switched to an agent-first workflow, on the logic that the tools finally met his standard, not that his standard moved. His values stayed put; what changed was his assessment of whether the tools honored them. That’s the template: the resister and the convert are the same man with the same principles.

Which is why the craft instinct deserves defending, not demolishing. The tools feel wrong partly because you’re judging them against that instinct, not just against output. Its firing isn’t a malfunction — it’s the sharpest instrument you own, calibrated over years, telling you when something is almost right but not quite, the same complaint 66% named in the Stack Overflow data. The mistake is concluding it has to be put down for the tools to be picked up. It doesn’t.

The path from Depresh to Energesh

This part is for the reader sitting in the Depresh right now. It isn’t a pep talk, and I’m not going to tell you the feeling is irrational, because it isn’t.

Grieve first. The ego death Violaris describes is real, and you’re allowed to mourn it. The craft identity you spent years building had value — it shipped real systems and earned you a career. Skipping the grief doesn’t work. The developers I’ve watched leap straight to enthusiasm tend to adopt the tools resentfully and use them badly, half-hoping they’ll fail. Let the loss be a loss before you look for what’s on the other side.

Then ask the real question. The Anthropic engineer’s version: do I love writing code, or what I get from writing code? You’ve probably never had to answer it, because the two were never separable before. They are now. The answer isn’t a verdict on your worth as an engineer. It’s a map of where you actually live, and either answer is fine — but you can’t find the path until you know which is true for you.

Learn harness engineering. The on-ramp for a senior engineer goes up a level, not down. Vibe coding pulls you toward the model’s altitude; this pulls you above it. The harness is the tooling layer around the model — orchestration, context management, verification scaffolding, the agent configuration that decides what the model sees and whether you can trust what comes back. Engineering that layer rewards the judgment you spent years building: systems thinking, architecture, the discipline of making an unreliable component dependable. My own claude-mpm and trusty-* tools are harness engineering and nothing else. So skip the vibe-coded toy app. Pick something real, build the harness that drives it, and watch how it feels — whether you feel more like yourself, or less.

Reframe from author of code to author of outcomes. Your craft instinct — what good architecture looks like, what breaks at scale, when a design is quietly wrong — isn’t going away, and the model doesn’t have it. The model is fast, capable, judgment-free. You are slow by comparison and you have taste. The job becomes directing the thing and knowing whether what came back is right. Not a demotion from engineer to button-pusher. It’s the part of the work that was always hardest to teach, now occupying most of your day.

A word for the CTOs reading this: you have a version of this problem you may not have named. The Depresh shows up in your metrics before your one-on-ones: review cycles stretching out, code-quality variance widening, your most experienced engineers going quiet in design reviews. The path for them is the path for an individual — don’t push adoption before you’ve made room for the grief. And understand who you’re dealing with: the engineers who feel the Depresh most sharply are frequently your best ones, who invested most in the craft. Their standards are the feature, not the bug. Burn that instinct down to force faster adoption and you’ll get the adoption and lose the standards.

Where this leaves you

Gulman didn’t end his special by announcing he was cured. He said his depresh was in remish — smaller word, smaller claim, a thing managed rather than defeated. That’s about the right register for where the industry is.

The craft you built was real, and so is the grief if you’re feeling it. But the thing you actually loved — if it turns out to be the building, the deciding, the watching something work that didn’t exist this morning — that part never depended on you typing every character yourself. The canut whose love was the cloth still had cloth to make. You can find out which one you are. Most developers go a whole career without having to ask. You get to.

Your depresh can be in remish. The energesh is on the other side of one unsparing question, and you already know how to ask those. You’ve been debugging your own assumptions for years.

Bob Matsuoka is CTO of Duetto and writes about AI business trends at AI Power Ranking.

Related reading:

• The Tide Has Turned: Senior Developers Are Finally Adopting AI Tools — Why the holdouts changed their minds, and what shifted to make it happen

• The Era of the Leader/Practitioner — How AI tools made the hybrid leader-who-builds role viable again

• We’ve Turned a Corner — On the shift from skepticism to working practice

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

The Math Doesn’t Work (Yet): Inside the AI Profitability Problem

OpenAI’s own projections show losses getting bigger as revenue gets bigger. Leaked investor documents reported across WSJ, Fortune, and The Information put the company at roughly $74 billion in operating losses in 2028 — on roughly $100 billion in projected revenue. That pairing is the headline. Not a smaller loss as scale arrives. A loss that grows faster than the top line.

That single relationship is the whole story. We tend to model AI companies as software businesses that will eventually grow into their cost structure the way SaaS companies did before them. The numbers say otherwise. These are capital-intensive infrastructure plays wearing software-company clothing, and the unit economics underneath them run in the opposite direction from the SaaS playbook most of us internalized over the last fifteen years.

A caveat before the numbers, because it matters for what’s below: neither OpenAI nor Anthropic publishes audited financials. Most figures here come from leaked investor decks, run-rate annualizations the companies announce in funding rounds, or SEC filings made by their cloud partners. The uncertainty is part of the analysis, not a footnote to it. When a specific timeline or quarterly figure couldn’t survive cross-checking against primary sources, I left it out.

TL;DR

• OpenAI’s leaked projections show operating losses widening as revenue grows — roughly $74B in losses on ~$100B revenue projected for 2028, with cumulative cash burn near $115B through 2029.

• In 2025 OpenAI spent about $1.69 for every dollar of revenue (~$9B net loss on ~$13B revenue), per leaked documents confirmed by multiple outlets.

• Anthropic’s revenue trajectory is steep — roughly $1B annualized at the end of 2024 to a figure announced in the tens of billions by mid-2026 — with Claude Code alone reported at $2.5B annualized by February 2026.

• Inference token prices fell about 75% in a year. Selling more AI makes the per-unit economics cheaper, which makes revenue growth harder, not easier.

• AI-native gross margins sit near 45% versus 75–85% for mature SaaS — a structural gap of 23–33 points no company has yet closed.

• No company has a verified path to profitability. Every specific breakeven-by-year claim I tried to confirm fell apart under scrutiny.

Two Companies, Two Shapes

OpenAI ended 2025 at roughly $20 billion in annualized revenue, a figure CFO Sarah Friar has stated directly. That is a large business by any normal measure. It is also a business that, in the same year, spent about $1.69 for every dollar it took in — somewhere around a $9 billion net loss on roughly $13 billion in recognized revenue, according to leaked documents that WSJ, Fortune, and The Information each reported. The company is majority funded by Microsoft, runs its compute primarily on Azure, and its strategy is scale-first: build the largest models, capture the most usage, and trust that revenue follows the curve.

Anthropic’s shape is different. Its revenue trajectory is steeper and more concentrated. The company grew from roughly $1 billion annualized at the end of 2024 to a figure it announced in the tens of billions by mid-2026 — the number it cited in its Series H materials. I’m deliberately not pinning an exact figure to a month here, because the company has grown several-fold inside a single five-month window and any precise number is stale by the time you read it. What’s verifiable is the slope, and the slope is steep.

The more interesting detail is the concentration of value. Claude Code, one product, was reported at roughly $2.5 billion annualized by February 2026. A single coding tool driving that much of a company’s run rate tells you something about where the margin-bearing demand actually lives. Anthropic is backed by Amazon (over $8 billion invested) and Google (over $2 billion), and it has committed to spend more than $100 billion on AWS over ten years, with roughly 1 GW of Trainium capacity targeted by the end of 2026. Two large companies funding it; one of them also selling it the silicon it runs on.

Why Compute Is the Problem

What separates these companies from every SaaS business you’ve evaluated: they don’t own their infrastructure. They rent it, at hyperscaler rates, from the same companies that fund them.

OpenAI’s Azure spend reportedly ran around $3.7 billion in 2024 and roughly $8.7 billion across the first three quarters of 2025. Treat those numbers as medium-confidence — they come from leaked documents, and Microsoft pushed back that the figures “aren’t quite right.” But the direction is consistent with everything else: compute cost is the dominant line item, it’s largely fixed, and it grows with usage.

Anthropic’s arrangement produced one of the stranger details in modern enterprise finance I’ve read in some time. The company signed a deal for compute from Colossus 1 — Elon Musk’s Memphis data center, operated by xAI — at roughly $1.25 billion per month for 300 MW of capacity, running through May 2029. That’s not from a leak. It surfaced in SpaceX’s S-1 SEC filing and was confirmed by CNBC, Axios, and Data Center Dynamics, with a potential total value above $40 billion. There’s a 90-day mutual cancellation clause, so the headline total overstates the firm commitment. Still: Anthropic — funded by Google and Amazon — is paying Elon Musk’s company more than a billion dollars a month for compute. The AI capital world is stranger from the inside than the press releases suggest.

Zoom out and the renter problem gets sharper. Hyperscaler capex for 2026 is projected at $660–690 billion. Against that, OpenAI’s $20 billion ARR is roughly 3% of a single year’s data-center buildout by its suppliers. The companies selling AI applications are small tenants in an infrastructure market they don’t control and can’t currently price against.

The Unit Economics Trap

This story inverts an instinct most of us trust.

In normal software, even in the Cloud, scale is your friend. Marginal cost trends toward zero, gross margin climbs as you grow, and a mature SaaS business lands at 75–85% gross margin because serving the millionth customer costs almost nothing. Volume is the cure.

Inference doesn’t behave that way. Every token generated costs compute — real, metered, non-zero compute — so the marginal cost of serving usage stays stubbornly positive. And the price you can charge for that token is collapsing. Enterprise transaction data from Ramp shows inference prices falling roughly 75% in a single year, from around $10 per million tokens to around $2.50. Capability per dollar is improving fast, which is good for buyers and brutal for sellers, because it means the revenue you booked at last year’s prices reprices downward while your compute bill does not.

Put the two forces together and you get a squeeze that worsens with success. The better you are at selling inference, the more usage you drive; the more usage you drive, the more the per-unit price falls; the more it falls, the harder it is to grow revenue against a compute bill that scales with that same usage. Volume isn’t the cure here. Under these dynamics it’s part of the disease.

The survey data puts a number on how far this world sits from SaaS. ICONIQ Capital polled about 300 software executives and pegged AI-native gross margins at 41% in 2024, 45% in 2025, and a projected 52% in 2026. Improving — but starting from a base 30-plus points below mature SaaS, and closing the distance slowly. A 52% gross margin is a respectable hardware business. It is a structurally difficult software business, especially one still spending heavily to grow.

Two Different Bets

OpenAI and Anthropic are running different experiments on how you eventually close that gap. Neither has been validated.

OpenAI’s bet is scale and breadth. Build the broadest platform, capture consumer and enterprise and API demand simultaneously, and assume that at sufficient scale you gain pricing power over compute, model-efficiency gains compound, and the revenue base grows fast enough to absorb the fixed cost. The leaked projections embody the risk in this bet: they show losses widening through 2028 even as revenue approaches $100 billion, with cumulative cash burn near $115 billion through 2029. The theory requires the curve to bend after the window we can currently see.

Anthropic’s bet is narrower and more product-led. Find a wedge where the work is valuable enough that buyers tolerate real prices, prove the margin there, and expand outward. Claude Code is that wedge made concrete — $2.5 billion annualized from developers who pay because the output is worth more than the inference under it. Coding, agents, and enterprise automation are higher-value work than chat, and higher-value work supports prices that don’t immediately erode under token deflation. The risk: revenue concentration in a single product line, and an infrastructure bill — AWS commitments plus the xAI deal — that’s enormous relative to a company still proving the model.

Two theories of the same problem. Scale your way past the margin gap, or find work valuable enough that the gap doesn’t bind. We don’t yet have the data to say either works.

What Would It Actually Take

I’ll skip the timeline speculation — every specific breakeven-by-year claim I tried to verify died on contact with the sources. The structural requirements are clearer than the dates.

Three things have to move. First, gross margins have to climb from the mid-40s toward something defensible — call it 60-plus — and stay there while volume grows. That means model-efficiency gains (cheaper inference per unit of capability) have to outrun price deflation, rather than getting passed straight through to buyers as lower prices.

Second, these companies need pricing power over compute, which today they don’t have. At current scale they’re tenants. The open question is at what ARR a vendor becomes large enough to negotiate compute like a partner instead of a customer — or to build its own. Anthropic’s Trainium commitment and OpenAI’s various infrastructure moves are bets that vertical integration eventually changes the cost equation. That’s unproven, and it’s expensive in the interim.

Third, the product mix has to keep shifting toward work that resists deflation — enterprise agents, coding tools, automation that’s measured against labor cost rather than against the falling price of a token. Claude Code is the cleanest evidence that this category exists and that buyers will pay. Whether it’s a large enough share of total volume to lift blended margins across a company is the question that decides the whole thing.

The Open Questions

What we don’t know outweighs what we do.

We don’t know the actual, current gross margins at either company — only the AI-native sector estimate of roughly 45%. Neither company publishes the number that would settle the argument. We don’t know whether Anthropic’s stack of compute commitments, the decade-long AWS deal alongside the month-by-month xAI arrangement, creates structural tension or healthy redundancy. A company hedging across three infrastructure providers is either diversifying supply or revealing that no single supplier can meet its demand. We don’t know the ARR threshold at which compute pricing becomes negotiable, which is the hinge the entire margin story turns on.

And there’s the strategic risk that has no clean precedent: your infrastructure supplier is also your competitor. Microsoft ships Copilot. Amazon and Google both build models that compete with Anthropic’s. xAI builds Grok. Every dollar these companies pay for compute partly funds a rival’s model program. In normal software you don’t hand your gross margin to the company trying to beat you. Here it’s the default arrangement.

So the real question isn’t whether the AI labs are growing. They obviously are, faster than almost any companies in history. The question is whether revenue growth and margin improvement are the same trend or opposing ones. The SaaS era trained a generation of operators to believe that scale fixes economics. The leaked numbers describe a business where scale, so far, makes the loss bigger. Until one of these companies publishes a gross margin that shows the curve bending, that’s the math we have. And the math doesn’t work yet.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• The First 70% Era — Where agentic AI delivers value and where it stops, and why the higher-value work resists token deflation

• AI and the Rise of the Hyperdev — Why developers pay real money for AI tooling, the demand side of the margin story

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

Most of the best ideas in software engineering aren’t new. They’ve been written up in books, argued over at conferences, taught in every “best practices” deck since the late 1990s. And most teams quietly don’t do them.

Not because anyone thinks they’re wrong. Test-driven development, design by contract, architecture decision records, mutation testing — ask a room of senior engineers whether these are good ideas and you’ll get nods. Ask the same room who practices them consistently under deadline pressure and the hands stay down. I’ve been in that room for twenty-five years, on both sides of the question. I’ve also been the engineering leader who let those practices slip because shipping the feature mattered more this quarter.

There’s a single economic reason these practices lose. The upfront cost is high, the payoff is real but distant, and human attention is the binding constraint. Write the test before the code, document the decision, specify the invariant — every one of those is a tax you pay now against a benefit you collect later, maybe, if the project lives long enough. Under deadline pressure, that’s a losing trade for a human. So we skip it, ship, and pay the interest later in bugs and confusion. Call it the impatience tax.

Agents don’t pay that tax. They have infinite patience for upfront rigor and roughly zero marginal cost for the tedious work that rigor demands. Writing a thorough test suite for code that doesn’t exist yet is psychologically brutal for a person and completely fine for a model. That single shift — the cost of patience going to zero — quietly inverts the economics of a whole list of practices we knew were right and gave up on anyway.

This isn’t a piece about what AI makes possible. Lots of things are possible. It’s about a narrower, more useful question: which disciplines did we already agree were correct, fight about for decades, and abandon for reasons that no longer hold?

Here are nine.

TL;DR

• These nine practices share one structure: high upfront cost, distant payoff. Human attention is the constraint that kills them under deadline pressure.

• AI removes the constraint. A failing test is the clearest prompt you can hand an agent; a spec is its input; an ADR is its context. The discipline becomes the interface.

• TDD, design by contract, and property-based testing turn from “things we should do” into the most effective way to constrain agent behavior and prevent hallucinated correctness.

• Documentation, ADRs, and living docs get a bilateral ROI: agents generate them from code, and they make agents far more effective in your codebase.

• The catch is real. A 2025 METR randomized trial found experienced developers were about 19% slower with AI assistance. These practices pay off only when AI is used with discipline, not as autocomplete.

1. Test-Driven Development

Start with the practice most teams abandoned first.

Writing tests before code was always the theoretically superior move. It forces you to define the interface before you build behind it, catches bugs at the moment of definition instead of during integration, and leaves behind a living specification of what the code is supposed to do. Kent Beck made the case decades ago and the case held up.

Almost nobody did it consistently. The reason is psychological, not technical. Writing detailed tests for code that doesn’t exist yet, while a deadline breathes on your neck, feels like building scaffolding for a house you haven’t designed. Your brain screams at you to just write the function. So you write the function, promise yourself you’ll add tests after, and — well. You know how that goes.

Now flip the perspective. To an agent, a failing test isn’t scaffolding. It’s the clearest possible specification of intent you can provide. “Make this pass, don’t break anything else” is an unambiguous, machine-checkable instruction, which is exactly what a probabilistic system needs to stay honest. The test suite becomes a guardrail that prevents the most dangerous failure mode in AI-assisted coding: confident, plausible, wrong. Hallucinated correctness dies against a red bar.

TDD went from the discipline most teams couldn’t sustain to one of the best tools we have for bounding what an agent is allowed to claim it did. Same practice. Opposite economics.

2. Spec-Driven Development and Design by Contract

Bertrand Meyer formalized design by contract in the 1980s and built it into the Eiffel language: specify preconditions, postconditions, and invariants, then let the implementation follow from the contract.

The idea was sound and the adoption was thin, for one stubborn economic reason: the contract only pays off if someone else writes the implementation from it. If you’re writing both the spec and the code, the spec is overhead — you already know what you meant. The contract’s value lives in the handoff, and for most of software history there was no cheap handoff to hand it to.

Now there is. You write the contract; the agent writes the implementation from it. Spec-driven development stops being a documentation chore and becomes the actual control surface for delegation. The spec is the part requiring human judgment about what the system should do. The implementation — the part that used to eat the hours — is the part you delegate. Meyer’s economics finally close, forty years late, because the missing party in the transaction showed up.

3. Architecture Decision Records

Why does the codebase look like this? Why Postgres and not Dynamo, why this queue, why the weird module boundary that everyone trips over?

ADRs were the right answer to that question — a short dated record of each significant decision, the context, and the alternatives rejected. The discipline almost never held. Same shape as everything else here: the cost is immediate (stop, write the thing) and the value accrues slowly, mostly to some future engineer who isn’t in the room yet.

Two things flipped at once, which makes this one more interesting than the rest. First, agents can generate ADRs from an existing codebase — read the git history, the dependency choices, the structure, and reconstruct the decisions that produced them. The retroactive cost of documentation drops toward zero. Second, and this is the part people miss: existing ADRs dramatically improve what an agent can do in your codebase. An agent that can read why you chose eventual consistency won’t keep proposing changes that assume strong consistency.

So the ROI went bilateral. Agents help you write ADRs, and ADRs help agents help you. The practice that used to only cost now pays on both ends.

4. Continuous Code Review

“Catch issues early” has sat on every best-practices list since Extreme Programming put continuous review on the map. The advice was never controversial. The bottleneck was always the same: human reviewer attention is finite, expensive, and easily exhausted. So review collapsed into batch PR review — a tired engineer reading a 600-line diff on a Friday afternoon, approving most of it on faith.

AI review on every commit — not batched at the PR boundary, but running as code lands — is moving from aspirational toward baseline: increasingly the default on teams that have wired it in, though not yet universal. The marginal cost of a careful read went to nearly nothing, and the read happens while the context is still warm.

But this one comes with an emergent problem worth naming, because it bites teams that adopt the tooling without rethinking the model. PRs are getting larger and arriving faster under AI-assisted development. An agent can produce a 2,000-line change in an afternoon. If your review model still routes everything through a human approver at the end, that human is now the rate limiter, drowning in volume they didn’t generate and can’t realistically read. AI review on every commit is part of the answer. The harder part is restructuring what the human reviews — architecture, intent, the decisions a model shouldn’t make alone — and letting the machine handle line-level correctness continuously. Adopt the tool without rethinking the workflow and you’ve just built a faster way to overwhelm your best reviewer.

5. Pair Programming

Pairing always looked expensive in the most obvious way: two engineers, one task, double the salary against a single unit of output. That intuition was wrong on the numbers — the measured overhead from the pair-programming studies was closer to 15%, often recovered through fewer defects — but the 2× gut feeling is what drove the decisions. The benefits were real — knowledge transfer, real-time review, fewer dumb mistakes — but the perceived math meant most teams reserved it for critical paths, gnarly bugs, or onboarding a new hire. A luxury, rationed.

The pair is now a human and an agent, and it’s available to every engineer continuously, not rationed to the critical path. The knowledge-transfer benefit generalizes — the agent can explain unfamiliar parts of the codebase on demand. The real-time-review benefit generalizes — a second set of eyes on every line, every time, without scheduling two calendars. The economics that made pairing a rationed luxury simply don’t apply when one half of the pair has near-zero marginal cost.

Worth a caveat: agent-as-pair is genuinely good at the review and explanation half of pairing, and weaker at the part where a human partner pushes back on a bad design before you’ve written a line. You still need humans pairing with humans for that. But the day-to-day, line-by-line version of pairing just became free, and that’s most of what pairing was for.

6. Mutation Testing

Coverage numbers lie, and most engineers know it. Eighty percent line coverage tells you eighty percent of your lines got executed by a test — not that any of those tests would notice if the behavior broke. Mutation testing is the honest measure: it deliberately introduces bugs (flip a comparison, drop a line, change a constant) and checks whether your test suite catches them. If a mutant survives, you have a test that runs code without actually validating it.

Mutation testing was always the gold standard and almost never run continuously, for one reason: it’s computationally expensive. You’re effectively running your whole suite many times over, once per mutation. On a real codebase that’s brutal. So it lived in research papers and the occasional heroic CI job that someone eventually disabled for being too slow.

That constraint is mostly gone — compute is cheap and parallel, and we got more comfortable spending it. And the practice arrived right when we suddenly need it most. AI-generated tests have a characteristic failure mode: they drift toward coverage metrics without meaningful assertions. The model writes a test that calls the function, exercises the path, and asserts almost nothing of substance — green checkmark, zero protection. Coverage looks great. Mutation testing is the thing that catches exactly that. It’s the verification layer for a verification layer, and it matters more now than when it was invented, because now a machine is writing the tests.

7. Living Documentation

Documentation was always supposed to be a first-class artifact. It almost never was, and the reason is by now familiar: writing docs is tedious, and the penalty for stale docs accrues slowly and lands on someone else. So docs rotted. Every team has a wiki that’s a graveyard of half-true pages from two reorgs ago.

AI changes both halves of the equation at once. It generates docs from code, so the writing cost drops. And it consumes docs as context, so the docs earn their keep immediately — a well-documented codebase is a measurably more useful codebase for an agent working in it. The ROI is immediate and bilateral, same structure as ADRs.

There’s a quiet shift hiding in there. Documentation used to be written for humans who’d mostly never read it. Now it’s also written for the agent that will read it on every task, which means stale docs don’t just confuse a future engineer — they actively degrade your tooling today. The feedback loop tightened from months to minutes. That’s the kind of change that actually moves behavior, because the cost of skipping it shows up now instead of later.

8. Runbook Generation from Incidents

On-call always leaned too hard on tribal knowledge. The person who knows why the payment service wedges at 3 a.m. is asleep, on vacation, or left the company last spring. Writing a runbook after each incident was obviously the right move and reliably the thing nobody did, because the incident was over and everyone wanted to go back to bed.

Incidents become runbooks automatically now. The agent has the incident timeline, the chat transcript, the commands that resolved it, the postmortem — and it can turn that into a structured runbook while the details are fresh, without asking an exhausted engineer to relive the night. The cost that used to fall right when motivation was lowest now falls on a system that doesn’t get tired or resentful.

I’d treat the generated runbook as a draft a human still signs off on, not gospel. But “imperfect draft, reviewed in five minutes” beats “blank page nobody ever fills in,” and that was always the real competition.

9. Property-Based Testing

Example-based tests check the cases you thought of. Property-based testing is stronger: you specify the invariants a system must always satisfy — reversing a list twice returns the original, a serialized-then-deserialized object equals the original, the account balance never goes negative — and the framework generates hundreds of adversarial inputs trying to break them. QuickCheck pioneered the approach; it finds the edge cases you’d never have written by hand.

It never went mainstream outside a few communities, and the bottleneck wasn’t tooling — good property-based libraries exist for most languages. The bottleneck was writing good property specifications. Identifying the right invariants requires deep domain reasoning: you have to understand the system well enough to state what must always be true, which is harder than writing a few example cases. Most engineers, under pressure, defaulted to the easier thing.

This is where AI helps in a way that’s less obvious than “it writes the code.” A model can generate property suites from a spec, and — more usefully — it can reason about what invariants a system should satisfy in the first place, surfacing properties you hadn’t articulated. That’s the expensive, judgment-heavy part it actually offloads. Combined with mutation testing to keep the generated properties honest, you get a testing approach that was always more powerful than example-based testing and was always too expensive in human reasoning to adopt widely.

The Catch

I’d be selling you something if I stopped there, and the data won’t let me.

In July 2025, METR ran a randomized controlled trial with experienced open-source developers working on real tasks in repositories they knew well. The developers expected AI assistance to speed them up. It slowed them down — by roughly 19%. METR’s February 2026 follow-up found that gap narrowing, and reversing on some measures, as the same kind of developers gained real experience with the tools — which is to say the 19% was a snapshot of the unfamiliar, undisciplined path, and it closes precisely as people pick up the habits this piece is about.

That finding is real and it isn’t a contradiction of everything above. It’s the missing condition. Every practice in this piece works because it imposes structure on the agent — TDD as a guardrail, the spec as input, the ADR as context, mutation testing as the check on the check. Used that way, with discipline, AI is constrained toward correctness. Used the other way — as autocomplete, as a vibe-coding partner you don’t supervise — you get more code, faster, with less correctness and a slower path to done once you account for the cleanup. The METR developers, working in code they already understood deeply, may well have been paying exactly that tax: accepting plausible suggestions that took longer to vet and fix than writing it themselves would have.

So the inversion isn’t automatic. The cost of patience dropped to zero, which makes the rigorous path finally affordable. It does not make the undisciplined path good. If anything it makes discipline more important, because a tool that produces plausible output at high volume is precisely the tool that most needs a guardrail you can’t talk your way past. A red test bar doesn’t care how confident the model sounds.

What To Do With This

The interesting question was never “what does AI make possible.” That list is enormous, mostly speculative, and not very actionable. The better question is the one this whole piece is built on: which practices did we already know were right, argue about for decades, and quietly give up on?

That list is short, specific, and yours to write. Go pull your own team’s “we should really do this but we don’t” backlog — the standing items in retros that everyone agrees with and nobody owns. I’d bet most of them have the same economic shape: high upfront cost, distant payoff, killed by human impatience under deadline. Test coverage on the legacy module. The runbooks. The ADRs for the three decisions everyone keeps re-litigating. The integration tests that would’ve caught last quarter’s outage.

Run each one through a single question: was this abandoned because it was wrong, or because it was expensive in human patience? The wrong ones, leave abandoned. The expensive-in-patience ones just got cheap. Those are the ones to pick back up first.

The impatience tax got repealed. The disciplines it used to make unaffordable are sitting right there, mostly unchanged, waiting for someone to notice the price changed.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• The Other Shoe Has Dropped — Why enterprise AI bills don’t match the per-token price collapse

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

Something shifted in the last year, and it took me a while to name it.

A growing number of people are running organizations while still doing real hands-on technical work. Not as a hobby, not on weekends, not as a vanity exercise to keep their commit graph green. They are building things their teams depend on — and they are doing it as a deliberate part of the job, not in the cracks between meetings. The work has a specific shape. It is rarely a production feature. It is the layer underneath: developer productivity tooling, internal services, agentic harnesses, MCP connectors, the infrastructure that unblocks everyone else.

For most of my career this combination didn’t really hold together. You could code or you could lead, and the moment you tried to do both seriously, one of them rotted. I’ve watched plenty of technical executives keep a foot in the codebase and slowly become the bottleneck everyone routed around politely. The pattern was familiar enough to be a warning.

What changed is not that leaders suddenly got more disciplined. It’s that the time cost of meaningful technical contribution collapsed. Agentic coding made a hybrid role viable that wasn’t viable before — and the more I look at it, the more I think this isn’t a new invention at all. It’s the recovery of a very old idea that modern specialization interrupted.

I’m writing this as someone living in the middle of it. I spend roughly 30% of my time coding. And when I say coding, I mean directing a team of agents — much closer to that than hands-on work, which is probably the whole point. That’s not a full-time IC’s week, and it isn’t meant to be. It’s enough to stay close to the work that matters and to build the enabling infrastructure I think is worth my own hands on the keyboard.

TL;DR

• A distinct role is emerging: leaders who run organizations and still do deep technical work — specifically enabling/institutional work (tooling, harnesses, internal services), not critical-path product features.

• This satisfies Charity Majors’ actual advice. Her line was never “stop coding.” It was “stop writing code in the critical path.” Enabling work fits that exactly.

• The integration of strategist and practitioner has deep cross-cultural precedent — Japan’s bunbu-ryōdō, Rome’s Marcus Aurelius, China’s wen-wu, the Renaissance polymath, Mattis’s “warrior monk.” The modern role is a recovery, not a novelty.

• Agentic coding is what makes it newly viable: focused sessions now deliver output that once required sustained, uninterrupted immersion. The Anthropic 2026 data shows ~27% of AI-assisted work is work that “wouldn’t have been done otherwise.”

• Directing agents feels like delegation — the same skill leaders already use with human reports. Which is why experienced leaders adapt to it more naturally than juniors do.

The pattern, named

The difficulty with the coding executive was never philosophical. It was attentional.

Charity Majors mapped this years ago in The Engineer/Manager Pendulum, and the piece holds up because she was precise about the mechanism. Management is interruptive by design — your job is to be available, to unblock, to absorb the chaos so your team doesn’t have to. Serious engineering is the opposite. It requires blocking interruptions for long enough to hold a complex system in your head. Two incompatible attention modes. Try to run both at once and you do neither well.

But here is the part people skip when they quote her. Majors never said managers should stop coding. Her actual advice was sharper: don’t write code in the critical path. Don’t be the person others are waiting on. Stay technical, stay sharp, just don’t make yourself a dependency that blocks shipping. “The best frontline eng managers in the world,” she wrote, “are the ones that are never more than 2-3 years removed from hands-on work.”

That distinction carries the whole argument. Because there is a category of technical work that is consequential without being critical-path, and it turns out to be exactly the work senior people are best positioned to do.

Call it enabling work. Internal tooling. Developer productivity infrastructure. Agentic harnesses. MCP services that other teams plug into. Architectural prototypes that prove a direction before anyone commits to it. None of this is what blocks a release on Thursday. All of it multiplies whoever comes after. It tolerates interruption — you can pick it up Tuesday afternoon and put it down when a real fire starts — precisely because nobody is standing at your desk waiting for it.

This is also where the industry is putting its money. Gartner named platform engineering a top strategic trend for two years running and projects that 80% of large engineering organizations will run dedicated platform teams by 2026. The structural reason a leader can work here without becoming the bottleneck is built into the definition of the domain: its output unblocks others rather than blocking them.

Will Larson’s Staff Engineer archetypes circle the same territory without quite landing on it. His “Architect” sits in a permanent argument — some organizations demand the Architect stay deep in the code, others forbid it. The leader/practitioner resolves that argument by relocating it: deep in the enabling and infrastructure work, absent from production product code. Not the pendulum, not the staff IC. A real hybrid, and a newly coherent one.

This is not new

Here is where I want to slow down, because the most interesting thing about this role is how old it is.

The idea that a leader should be both a strategist and a practitioner — not separate modes to alternate between but a single integrated way of operating — shows up independently across at least five civilizations. That kind of convergence usually means a culture has found a durable answer to a real problem.

Japan gave it a name: bunbu-ryōdō (文武両道), the way of both the literary and the martial. Bun is letters, cultivation, strategy. Bu is the martial, the active, the practitioner’s hand. Ryōdō means both ways, together — not balanced, not traded off, but held at once. By the mid-fourteenth century the dual-talented warrior was already established as the model leader, and during the Edo period the Tokugawa shogunate made it official policy for the samurai class. The phrase that survives captures the stakes: culture without power is ineffective, and power without culture is barbarous.

The archetype is Miyamoto Musashi. Undefeated in more than sixty duels, often fighting with a wooden sword against live steel. He founded a two-sword school, and in the last months of his life he wrote The Book of Five Rings in a cave. He was also a recognized master of ink painting and calligraphy — his Shrike on a Withered Branch survives as a designated Important Cultural Property of Japan. The same hands that won sixty duels produced fine art a nation still protects. He didn’t oscillate between the sword and the brush. He held both, and each sharpened the other. “When I apply the principle of strategy to the ways of different arts and crafts,” he wrote, “I no longer have need for a teacher in any domain.” Mastery in one discipline illuminating all the others.

Rome had Marcus Aurelius, the philosopher-king made historical rather than theoretical. He ran the empire and commanded its armies on the Danube, and he wrote the Meditations in the war camps — fragmentary notes to himself, composed in the middle of campaigning and administration. That book was never published philosophy. It was a working journal, the most powerful man in the ancient world writing to stay grounded while doing the job.

China institutionalized the same ideal as wen and wu — civil cultivation and martial capability — and ran it for roughly thirteen centuries through the scholar-official class. Zeng Guofan is the canonical case: he rose through the imperial examinations to high Confucian office, then built and commanded an army of more than a hundred thousand, reportedly keeping a diary on Neo-Confucian ethics even as he directed the campaigns. The integration wasn’t left to personal taste. It was built into the examination and career structure.

And the archetype still lands today. James Mattis earned the nickname “Warrior Monk” — battlefield commander and devoted reader, a 7,000-book library, the Meditations carried into combat. The chain from Aurelius to Mattis is literal: the same book, eighteen centuries apart. That we still reach for “warrior monk” as a compliment for a leader tells you the integration never stopped resonating.

Across all of it, the answer is the same. The contemplative and the active were not specializations to assign to different people. They were a single discipline, each half informing the other. Modernity — with its org charts, its clean role boundaries, its professional specialization — interrupted that. The leader/practitioner is not a tech-industry novelty. It’s an old integration becoming feasible again.

Why now

So what actually changed? Not the wisdom. The economics.

The thing that made the coding executive a bad idea was the attention math. Serious technical work demanded long, unbroken stretches of focus — the exact resource a leadership schedule cannot reliably provide. You cannot design a system in the fifteen minutes between a board prep and a one-on-one. The pendulum was a real constraint, not a failure of will.

Agentic coding changes that math directly. The unit of work moved up a level. Instead of holding every implementation detail in working memory across a four-hour session, you specify intent, direct an agent, review what comes back, correct course, and direct again. A focused 30-minute session now produces what used to require an afternoon of immersion — not because the thinking got easier, but because the implementation cost collapsed.

The Anthropic 2026 Agentic Coding Trends Report puts numbers on the shift. Average session length has climbed to 23 minutes in the agentic era, up from about 4 in the autocomplete era — the work got denser, not just faster. 78% of Claude Code sessions now involve multi-file edits, up from 34% a year earlier. Teams running multi-agent workflows report 2–4x faster delivery from task creation to deployment. And the figure that matters most for this argument: roughly 27% of AI-assisted work consists of tasks that “wouldn’t have been done otherwise” — the scaling projects, the nice-to-have tools, the exploratory infrastructure that was never quite worth the manual hours.

That 27% is the enabling work. It is the category that lives or dies on time cost, and it’s the category a leader/practitioner is best placed to take on.

The arithmetic is what makes 30% credible. I documented a 6–10x multiplier on focused technical sessions in The Irreducibles earlier this year — a project I estimated at 150–200 billable hours compressed into roughly 50–70 hours of wall-clock time, most of which wasn’t coding at all. If directed work runs several times faster than hand-coding, then a day and a half a week can produce what once consumed a full-time engineer’s week. That’s not a marginal gain. It’s a change in what’s structurally possible.

There’s another dimension that doesn’t show up in the productivity numbers: the work itself is unstable. Agentic coding patterns are still shaking out. There aren’t many experienced practitioners, the field is moving fast, and we don’t yet have good consensus on which patterns are load-bearing and which are fashion. A manager who’s only reading about it can’t make that distinction on behalf of a team. You have to be in it to know.

There’s a counterintuitive wrinkle worth naming: the people best positioned to exploit this are the senior ones. A University of Chicago working paper from late 2025 found experienced developers were 5–6% more likely to succeed with AI agents for every standard deviation of work experience, largely because they worked plan-first — laying out objectives, alternatives, and steps before invoking the tool. That’s the opposite of the assumption that AI flattens the seniority curve. Expertise improves your ability to delegate to a model for the same reason it improves your ability to delegate to a person. AI doesn’t change what senior engineering is. It reveals what it always was.

Directing agents is delegation

This is the part that interested me the most, and it’s the bridge between the leadership job and the technical one.

A year or so ago, working with Claude Code felt like coding. Now it feels like delegating. I wrote about that shift when it first became undeniable — the move from being a programmer who uses AI to being something closer to a technical project manager who directs it. Anthropic’s report uses the same vocabulary, describing engineers moving “from writing code to orchestrating the systems that write it.”

What I didn’t fully appreciate at the time is how directly that maps onto the muscle leaders already have. Delegating to an agent feels, in practice, just like delegating to a human engineer. You frame the problem, set the constraints, hand it off, and come back to assess the result. Give a directive, walk away, return to completed work. That loop is the daily reality of management. Leaders developed it because they had to, and it transfers to agents almost without friction.

So the leader/practitioner doesn’t have to become a coder again in the old sense. The skill in demand is judgment plus delegation, and that’s the skill leadership has been building all along. The hands-on knowledge tells you what to ask for and whether the answer is any good. The delegation instinct does the rest.

This is why the enabling work and the agentic tools fit together so cleanly. Enabling work tends to be well-defined, non-user-facing, and long-horizon — exactly the profile agents handle well and exactly the profile that tolerates a leader’s interrupted schedule. The hands-on contribution mostly takes the form of specifying constraints and patterns, which is what I’ve called pattern mastery: when you write the pattern down, you’ve written the spec, and the spec multiplies everyone else’s output.

What it actually looks like

Let me ground this without turning it into a war story.

The concrete examples from my own work are the kind of thing I mean. I built an agentic harness — the orchestration layer I argued is the real determinant of AI coding outcomes, where the same model can swing more than a quality point depending on the scaffolding around it. I built MCP services, the org-specific connectors that replaced a handful of standalone tools in a few hours of directed work each. None of that was a production feature. All of it was infrastructure other people now depend on.

Here’s a detail that may make the point. I now have an “AI architect” on my leadership team helping maintain the very infrastructure I originally built — not just the harness, but our inference relationships, our training program, office hours, the real human work I no longer have the time, or the right, to be doing myself. And I expect to hand off more over time. The enabling work I do today partly becomes the system that does tomorrow’s enabling work. That handoff is the role in miniature: you build the thing that multiplies the team, then you put someone in place to build the next version.

The proportion matters. Around 30% hands-on keeps judgment fresh without putting me in the critical path. Even full-time senior ICs aren’t full-time coders — Bain’s Jue Wang, quoted in MIT Technology Review last December, put developer coding time at 20–40%, with the rest going to analysis, strategy, and the surrounding work. A leader at 30% isn’t doing something exotic. They’re spending their technical budget on the layer where it compounds.

The decision is not “how do I find time to code.” It’s “what enabling work is worth my own hands?” Those are different questions. The first leads to the bottleneck I watched so many executives become. The second leads somewhere useful.

The choice

I’ll resist overselling this, because it isn’t for everyone and it isn’t automatic.

This is a deliberate role, not a default. Staying technically current costs ongoing investment, and the work is often invisible — enabling infrastructure rarely shows up in a quarterly review the way a shipped feature does. The role is easy to misread, too. From the outside, a CTO who codes can look like a CTO who hasn’t let go. The defense against that reading is the discipline Majors named: stay out of the critical path. Build the multipliers, not the blockers.

The returns are real, though. Fresh judgment — the kind that lets you evaluate not just what and why but how. Trust from engineers who see you in the work rather than above it. And institutional infrastructure that makes the whole team faster, built by the person with both the technical depth and the positional authority to prioritize it.

There’s a closing note in the history worth keeping. Bunbu-ryōdō wasn’t only a personal aspiration. The Tokugawa shogunate institutionalized it — built career and class structures around the assumption that a leader should be both. China did the same with its examination system. We’re not there yet. For now, the leader/practitioner is an individual choice, made one person at a time, made viable by tools that finally collapsed the cost of staying hands-on.

But the precedent suggests where this could go. When a way of working proves durable, organizations eventually build structures around it. The era of the leader/practitioner is early. It is also, I’d argue, a return — to an integration we knew was valuable long before we had the means to make it practical again.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• From Coding with AI to Managing AI — When agentic coding starts to feel like delegation

• It’s The Harness, Stupid! — Why orchestration quality dominates AI coding outcomes

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

Two stories from the last two weeks. Uber burned through its entire 2026 AI budget in four months on Claude Code, with COO Andrew Macdonald telling the Rapid Response podcast that the link between that spend and shipped consumer features “is not there yet.” The Information had the underlying numbers a few weeks earlier: engineer adoption from 32% to 84% between December and March, heavy users running $500–$2,000/month in tokens, and CTO Praveen Neppalli Naga torching $1,200 in a two-hour demo. Same week, Microsoft told thousands of engineers in its Experiences + Devices division that their Claude Code access is going away. Windows Central, summarizing The Verge’s Notepad scoop, has the cutoff at June 30 — end of fiscal year — with cost as the actual driver even though EVP Rajesh Jha framed it publicly as convergence on Copilot CLI.

Two of the most AI-forward enterprises on the planet, same tool, same week. The “AI is failing” takes were live within hours.

I don’t buy that framing.

The headlines are getting it wrong. Uber didn’t cancel anything — adoption ran ahead of the budget and the company blew its annual spend keeping up. That’s a planning failure, not a verdict on the tool. Microsoft didn’t divorce Anthropic either; they’re still consuming Claude through Azure Foundry and M365 Copilot. What they cancelled is a specific license — Claude Code at the engineer-seat level — because engineers preferred it over GitHub Copilot CLI and the division was paying for that preference.

What both stories show: AI is a new tool and we haven’t learned to use it well yet. The teams over budget pointed it at problems it wasn’t the cheapest way to solve, then let it decide for itself how much work to do per task.

I’ve made the cloud parallel here before. Early cloud was expensive and misused. Lift-and-shift workloads routinely ran two or three times their on-prem cost — I watched that play out across teams I ran, and it took years to correct through architecture. Then the industry learned: right-sizing, reserved instances, autoscaling, serverless where it fit, on-prem where it didn’t. The bills came down. Not because compute got dramatically cheaper, but because we got more careful about what we asked the cloud to do. AI is in the same phase. Cheap per-token, expensive per-task, and the gap is architectural.

A few weeks ago I ran controlled head-to-head tests on Opus 4.6 and Opus 4.7 against identical coding tasks. Both models passed every test. Opus 4.7 cost 3.6× more to do it. Same outcomes, same rate card, dramatically more tokens.

Finout’s analysis of production deployments tells the same story at scale: up to a 35% cost increase overnight, driven by tokenizer changes that don’t show up on the per-token rate card. Not one team’s bad luck — the shape of the bill across the enterprise AI buyer base right now. The second of two shoes on AI economics.

I wrote about that version-to-version cost drift in detail. Providers can collapse per-token prices in public while the per-task bill drifts upward in private. The first shoe was the per-token price collapse that made everyone optimistic. The second is the behavioral and architectural cost overhang now landing on quarterly P&Ls.

TL;DR

• Per-token costs at GPT-3.5-equivalent performance are down roughly 280× since late 2022, per Stanford’s AI Index 2025. Vendor revenue tells the opposite story: Anthropic’s annualized revenue went from $1B in January 2025 to $30B by April 2026 — a 30× move in 15 months, coming from enterprise inference, not consumer subscriptions.

• Gartner’s April 2026 survey: just 28% of AI use cases fully meet ROI expectations, 78% of IT leaders report material AI charges that didn’t show up in any procurement model.

• Gartner estimates agentic workflows consume 5–30× more tokens than equivalent chatbot interactions; Stanford’s Digital Economy Lab puts the upper bound for coding agents at 1,000×. The cost driver isn’t the model — it’s the workflow architecture wrapped around it.

• Two patterns hold the line in production. Search-first architectures put inference at the end of a deterministic pipeline. Consolidated single-shot designs replace multi-call chains.

• Inference is a power tool, not a default. Use it with specific ROI goals per call, apply it to code solutions rather than to directly solve problems, and bound it with deterministic structure on both ends.

Why the Per-Token Savings Didn’t Reach the Invoice

Per-token economics of frontier models have been collapsing for two years. Stanford’s AI Index 2025 puts the decline at roughly 280× from a late-2022 baseline at GPT-3.5-equivalent performance. Most enterprise budget conversations in 2024 started from that headline. The implicit assumption: bills should be going down.

They’re not. The clearest read comes from the vendor side. Anthropic’s annualized revenue went from $1B in January 2025 to $30B by April 2026, with roughly 80% from enterprise and API usage rather than consumer subscriptions. Anthropic now discloses 1,000+ customers spending more than $1M per year — a cohort that doubled in under two months — alongside roughly 300,000 business customers. The mid-tier ($100K–$1M/year) grew 7× year over year.

Menlo Ventures’ 2025 State of Generative AI report cross-checks at the market level: enterprise GenAI spend tripled to $37B in 2025, with LLM API consumption alone at $8.4B by mid-year. The high tier shows up in named deals: Snowflake’s $200M multi-year partnership implies a $50–70M annual run rate from one customer, and Deloitte is deploying Claude across 470,000 employees.

For a typical enterprise running multiple production AI workloads, $500K–$2M per year is now the realistic floor. Fortune 100 is running $10M–$50M+, the most AI-intensive past $100M. The Gartner numbers point the same direction: just 28% of AI use cases fully meet ROI expectations and 20% fail outright, and 78% of IT leaders report material AI charges that didn’t show up in any procurement model.

The per-token chart is real. The invoice is also real. What closes the gap is behavior. Three behaviors specifically.

Models do more work per task. Reasoning models reason. Agentic loops loop. The prompt that used to consume 4K tokens now consumes 40K because the assistant explores, plans, second-guesses, and verifies. Some of that is valuable. Much of it is the model performing thoroughness in a way that costs you money. The Opus 4.6-to-4.7 jump I documented earlier: same task, same outcome, 2.9× more output tokens and 4.8× more cache reads.

Workflows fan out. A “single” task in a modern agentic system might trigger a planner, researcher, coder, reviewer, and summarizer. Each makes its own LLM calls over overlapping context. Gartner’s March 2026 analysis puts agentic workflows at 5–30× the token consumption of an equivalent chatbot ask. Stanford Digital Economy Lab’s April 2026 arXiv paper goes further: coding agents can consume 1,000× more tokens than equivalent chat completions. The agent isn’t more expensive because it’s smarter. It’s more expensive because it’s louder.

Context windows fill themselves. Long context is a feature in marketing and a bill in practice. In our own enterprise Claude.AI usage — 82,852 messages from 329 employees over 3.5 months, audited via the Anthropic Compliance API — the average request carried 366,000 input tokens, mostly from 10-turn conversations dragging accumulated history forward into every new turn. Most production systems I’ve audited show the same fingerprint: pipelines paying for context they aren’t actually using.

None of this is fraud and none of it is mysterious. It’s the natural consequence of letting probabilistic systems decide how much work to do on every call. The savings from cheaper tokens were real. They just got consumed by an order of magnitude more tokens per task.

What I’ve Found Shipping These Systems

The teams handling this well aren’t the ones cutting AI usage. They’re changing the shape of how they use it.

The pattern I keep coming back to: treat inference as the expensive step at the end of a mostly deterministic pipeline. Do the cheap, structured work in code. Reserve the model call for the part that actually requires judgment. Then bound the call hard — context budget, output budget, quality gate on whether the call even runs.

Two examples from systems I’ve been building illustrate this from different angles.

Example 1: Code-Intelligence — Search-First Architecture

The naive version of a code review tool is obvious: dump the changed files into Claude, ask for a review. That works. It also costs roughly $0.03 per operation, scales linearly with repo size, and produces a lot of review output you didn’t need. Claude.AI offers a code review service — it ended up costing us thousands a month for just a few repos. Augment Code offers a well-regarded one as a GitHub app, but charges a platform fee (a meaningful fraction of our Anthropic spend) just to connect.

So we built our own. It leverages a multimodal search/RAG/KG engine I’d already built, so this wasn’t from scratch.

The version I actually ship uses a multi-tier search pipeline with the LLM call at the very end:

Stage 1: Vector Search    (~$0.0002 per query, semantic similarity)
Stage 2: BM25 Reranking   (~$0.0001 per query, lexical relevance)
Stage 3: Static Analysis  (~$0.0001 per query, AST + symbol resolution)
Stage 4: Quality Gate     (free, deterministic threshold check)
Stage 5: Single LLM Call  (~$0.03 per call, only if Stages 1-4 passed)

The first four stages cost about $0.0004 combined. They do the bulk of the work: deciding what code is actually relevant, ranking it, pulling structural relationships, and deciding whether the result is even worth asking an LLM about.

Hard budget controls run through the whole pipeline:

# Budget enforcement, not aspiration
MAX_CONTEXT_FILES = 6          # cap on what we send to the model
MAX_REVIEW_WORDS = 500         # cap on what the model returns
RELEVANCE_FLOOR = 0.005        # quality gate before calling the model

if combined_relevance_score < RELEVANCE_FLOOR:
    # no point spending $0.03 to get a review of weakly-related code
    return SkipReason("below relevance floor")

context = select_top_n(ranked_results, MAX_CONTEXT_FILES)
review = llm.review(context, max_output_tokens=MAX_REVIEW_WORDS * 1.4)

The RELEVANCE_FLOOR check is the part to underline. A meaningful percentage of review requests in real codebases don’t justify an LLM call at all — the changes are mechanical, the related code trivial, or the search signal weak enough that whatever the model says will be hallucinated context. Refusing to spend $0.03 on those cases is where most of the savings come from.

Rough economics across a quarter of usage:

Approach Cost per operation LLM calls per 1K operations Direct “review the diff” ~$0.030 1,000 Search-first with gates ~$0.0034 average ~430

About 80% of the workflow logic ends up deterministic: search, ranking, static analysis, gating. The model handles the last 20% — judgment on curated context. Same outcome from the user’s perspective, roughly an order of magnitude cheaper, with more predictable failure modes because most of the pipeline is debuggable code rather than prompt behavior.

The limitation: this is more work than wiring up a single LLM call, and the gates are only as good as your search infrastructure. The payoff is on the cost and determinism side, not on speed of initial implementation.

Example 2: duetto-intelligence — Context Injection Instead of Replacement

The second pattern comes from duetto-intelligence, internal tooling I’ve been building against that same enterprise Claude.AI usage — 82,852 real employee messages over 3.5 months, not a thought experiment. The problem here isn’t “should we call the LLM at all.” It’s: given that our people are already routing structured-data questions through a $0.274-per-request multi-turn Sonnet conversation, what’s a cheaper path that doesn’t degrade the answer?

The audit data made the gap concrete. Average request: 366K input tokens, ten-turn conversation, $0.274 to Anthropic. The same query answered through a Haiku single-pass against deterministically-retrieved internal data: $0.0009. A 300:1 cost ratio on the slice of traffic about structured product knowledge, CRM/account prep, JIRA, people and org lookups.

Not all traffic. Somewhere in the 35–40% range based on classified samples. About half of remaining queries genuinely need full Sonnet or Opus reasoning — writing, debugging, free-form analysis — and shouldn’t be intercepted at all.

The framing matters, because it’s easy to mis-read this as “replace Claude with a smaller model.” It isn’t. duetto-intelligence acts as a context injection layer in front of the user-facing model. When a query has structured-data intent, we route a sub-query to DI, get back a bounded structured result, and inject that into the prompt the larger model sees. The expensive model still does the reasoning — it just stops being responsible for the deterministic data retrieval it’s bad at and expensive for.

The naive design for the routing layer looks like this:

1. Classify the user's intent             → LLM call (~150 tokens)
2. Plan which subsystems to query         → LLM call (~250 tokens)
3. Call subsystem A, summarize response   → LLM call (~300 tokens)
4. Call subsystem B, summarize response   → LLM call (~300 tokens)
5. Synthesize a final answer              → LLM call (~250 tokens)
                                          Total: ~1,250 tokens, 5 calls

Each call is plausible on its own. Together they’re a tax on every user interaction. Latency stacks linearly with calls, and any one of the five can hallucinate in a way that corrupts the rest of the chain.

The consolidated design replaces three steps with deterministic code:

1. Classify intent                  → LLM call  (~80 tokens, tight tagger prompt)
2. Fan-out to subsystems            → code      (0 tokens, intent → call map)
3. Consolidated synthesis           → LLM call  (~200 tokens, structured input)
                                       Total: ~280 tokens, 2 calls

The trick is the intent classifier. It produces a tag from a fixed vocabulary of 87 tags — revenue.query.ytd, forecast.compare.year_over_year, account.lookup.contact, and so on. Each tag maps deterministically to a set of downstream calls in plain Python. No LLM in the routing step. The model isn’t asked “what should we do?” It’s asked “what is the user asking about?” — a much smaller, bounded question.

We validated against a 50-query test corpus drawn directly from the compliance data — real questions people had asked the model in production. After tuning, 100% of those queries land on the fast path with no LLM call required for routing. That’s the proof the deterministic-discipline part holds at the boundary; the routing isn’t quietly falling back to a second model call to bail itself out.

Budget enforcement is explicit in every prompt template:

SOURCE_CHAR_BUDGET = 600    # per data source pulled into context
OUTPUT_TOKEN_BUDGET = 200   # cap on synthesis response
INTENT_TAG_VOCAB = load_intent_taxonomy()  # 87 tags, versioned

def synthesize(intent_tag: str, sources: list[Source]) -> str:
    trimmed = [s.truncate(SOURCE_CHAR_BUDGET) for s in sources]
    return llm.complete(
        prompt=template(intent_tag, trimmed),
        max_tokens=OUTPUT_TOKEN_BUDGET,
    )

The economics, against measured baselines rather than estimates: current Claude.AI Chat spend across the 329-user population runs $15,264 over 3.5 months. Roughly $4,360/month, driven by that $0.274-per-request multi-turn average. If DI intercepts the 35–40% of traffic that’s structured-retrieval underneath, projected savings come in around $1,500–1,700/month, or $18–20K/year on this single user population. The leverage isn’t from picking a cheaper model. It’s from refusing to pay Sonnet rates to answer questions a deterministic system already has the data for.

The intent vocabulary is the contract. New capability means a new tag, a new downstream mapping, a new prompt template. The model never has to invent structure on the fly. This is what people mean by “use the LLM to code solutions, not to solve problems directly” — the routing logic lives in code, the tagger is a thin call, the synthesis is bounded.

The source-character budget matters more than the output budget. The compliance audit confirmed it: production overspend is on the input side. 366K input tokens against a few hundred output. Models will happily consume whatever context you hand them. Trimming at the source — 600 characters per source, no exceptions — is how you keep per-call cost from drifting upward as the system gets more capable.

The limitation: this only works on the routable slice. The pattern isn’t “eliminate inference.” It’s “stop spending $0.274 to answer questions that have a structured answer at $0.0009.”

Why “Just Use a Cheaper Model” Doesn’t Save You

A reasonable objection: aren’t the cheaper, smaller models supposed to handle this? Why not route everything to Haiku or an open model and call it solved?

The pricing math seems to support it. The behavioral math doesn’t.

Two things go wrong when you swap a cheaper model into an unstructured workflow. Cheaper models are usually less efficient per task — more turns to converge, more exploration, more hallucination, which means more retries and verification calls. A model 5× cheaper per token can run 1.5–2× more expensive per completed task if your workflow lets it spin.

And the workflow itself is where most of the cost lives. The 5–30× multiplier is structural, not modal — it exists regardless of which model you point at it. Switching from Sonnet to Haiku inside an unbounded agent loop changes the per-token cost. It doesn’t change the loop.

Model choice is a 2–5× lever. Architecture choice is closer to an order-of-magnitude lever in the systems I’ve shipped — consistently larger than what model swaps deliver. Most teams are over-tuning the model selection and under-tuning the structure around it.

The default assumption — including from vendors with strong incentives to sell you more tokens — is that the answer to AI cost is buying inference more cleverly. The actual answer is using inference less, more deliberately, with hard bounds on what each call is allowed to do.

How I Think About Inference Now

Inference is a power tool. Not a default. You don’t reach for it when a search query, a regex, or a switch statement would do. You reach for it when you need probabilistic judgment over unstructured input. Every call you don’t make is the cheapest call.

Use it to code solutions, not to solve problems. The highest-leverage use of LLMs in my workflow is generating the deterministic code that then handles the workflow without further LLM calls. A model that writes you a 50-line classifier is more valuable than a model that acts as the classifier on every request forever. The first costs tokens once. The second costs tokens every transaction for the life of the system.

Wrap every call in a budget. Context budget on the input, token budget on the output, quality gate on whether the call runs at all. Treat the LLM call as you’d treat a paid API with rate limits and SLA penalties. Because it is.

Set specific ROI targets per call. “AI-assisted code review” is too coarse to optimize. “Reviewing files with relevance score > 0.005, capped at 6 files, returning 500 words” is something you can measure cost-per-outcome on. Even loose ROI math at the call level surfaces where you’re paying for theater.

Treat behavioral cost as the primary risk. Model rate cards will keep coming down. They are not your problem. Your problem is what your pipeline asks of the model and what the model decides to do once asked. That’s the line item that grew while the unit cost dropped 280×. That’s the shoe that just dropped.

What This Means If You’re Running an AI Budget

Three things to look at, in order of how much they’ll move the line item.

Audit the call graph, not the rate card. Pull a representative day of production traffic and trace the actual LLM calls per user task. Count them. Most teams find a handful of workflows producing the majority of cost, and most of those have 2–4 LLM calls that could be replaced by deterministic code. That’s the consolidated-design pattern from the duetto-intelligence example. 50–80% reductions are common when you actually look.

Put quality gates in front of inference. For any workflow where the LLM call is expensive and the input quality is variable, add a deterministic check that decides whether the call is worth making. That’s the search-first pattern from the code-intelligence example. The savings come from the calls you don’t make, which never show up on the invoice.

Set hard context budgets and enforce them in code. Per-source character limits, per-call token caps, no “just in case” context stuffing. The output budget gets attention because it’s visible. The input budget is usually where the actual money goes.

None of this requires changing models, switching providers, or making bets on the next frontier release. It’s architectural work inside the pipeline you already have — work the per-token price chart has been letting people defer.

The teams that do it over the next two quarters will look like they got a 5–10× cost improvement from “AI getting cheaper.” The teams that don’t will look like AI got 3–4× more expensive while everyone else’s costs fell. Same providers, same models, same rate cards. Different shoe.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• Opus 4.6 vs 4.7: The Real Cost of Incremental AI Improvements — The first shoe, on per-task cost drift between model versions

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders

My Duetto colleague Jake Becker is sharp. He’s been ahead of AI adoption on our team — experimenting early, pushing for new tools, staying current. Last week he messaged me on Slack: “I wish I had my own CTO Assistant. Like what you have.”

I paused.

I have one. I’ve had several, in different forms, going back months. But I hadn’t said anything about it publicly.

That gap — between an AI-forward person who knows the tools and a practitioner who actually has the thing — is what this piece is about.

TL;DR

• Off-the-shelf AI tools are capable but contextually blind. You still have to leave your domain to get help.

• Serious knowledge workers — writers, researchers, historians — have always built their own knowledge systems. Never trusted a vendor to hold their material.

• Coding is shifting toward what writing has always been: directing, curating, maintaining a living body of knowledge.

• Building your own AI memory and search layer is the new rite of passage. The tool you build IS the skill being developed.

• The latest versions of my own stack: trusty-memory and trusty-search — both open source, both installable today.

Everyone Wants One. Few Have One.

Jake’s comment revealed something I’d been taking for granted.

The major vendors are actively working on this — memory features, RAG pipelines, personalization layers. But those solutions are optimized for breadth, not for one person’s actual work across functions.

ChatGPT, Claude, Copilot — these are all capable. They’re also still contextually blind to you. You have to leave your environment, paste in context, explain your situation from scratch, then interpret the output back into your actual work. Vendors are working on it. But the solutions remain generic, and every session still starts from zero.

I wrote about this in March — Everyone Blamed Clawd Bot’s Execution. The Concept Was the Problem. The structural flaw of universal assistants isn’t fixable. They require you to leave your context to get help. What actually works is the opposite: your tools get assistant capabilities, and assistance comes to where your context lives.

Off-the-shelf tools haven’t solved this. They’ve gotten more powerful — better reasoning, longer context, faster inference — but they still don’t know your codebase, your decisions, your institutional history, your current sprint. They know a lot about the world, and very little about you.

Jake wanted my assistant. But what he actually wants is his assistant. The one that knows what he knows.

That’s a different problem entirely.

The job changed first.

Coding Is Becoming Writing

Practitioners feel it before analysts name it.

A few years ago, being a strong engineer meant writing a lot of code quickly and correctly. Today, with agentic AI coders at their disposal, the best engineers I watch spend their time directing, reviewing, specifying, and curating. The unit of work has moved up a level. Implementation is increasingly delegated. Judgment — about architecture, trade-offs, what to build and why — is the differentiator.

This is not what happens when automation replaces a skill. It’s what happens when a new discipline appears.

Writers have always worked this way. A novelist doesn’t produce words per minute as a primary metric. They produce decisions — what to say, in what order, with what emphasis. The words are the output of the decisions, not the work itself. What makes a writer productive over a career isn’t typing speed. It’s having a system: notes, research, accumulated material, patterns of thought that compound over years.

Some (typically senior) engineers are arriving at the same realization. Your value isn’t the code. It’s the judgment, the accumulated context, the knowledge of what was tried and why it failed. The question is whether that accumulates in your head alone — which doesn’t scale, and doesn’t survive a context switch — or whether it lives in a system.

Good engineers who learn to use their AI tools effectively generate better code — the stack amplifies judgment and accumulated knowledge. The gap isn’t between skilled and unskilled engineers in isolation; it’s between engineers who’ve wired their knowledge into their tools and those who haven’t. The knowledge is real in both cases. Only in one case does it compound.

The writers I’ve observed who sustain serious output over decades all have the same property: they know where things are. Their research is retrievable. Their earlier thinking is available to their current thinking. The system makes the person bigger than their working memory.

That’s the gap.

Writers Don’t Trust Vendors With Their Material

Niklas Luhmann, a German sociologist working in the 1950s, produced 70 books and nearly 400 articles over his career. I haven’t written a book yet — but I have published over 200 articles at HyperDev. Worth naming the parallel. He credits his output to his Zettelkasten — a slip-box system of 90,000 interconnected index cards, each with a unique identifier linking it to related thoughts. Not a filing cabinet. A network of ideas that got richer with every addition.

And it’s worth asking: is that so different from what an AI knowledge system does today? The Zettelkasten was an analog precursor to what trusty-memory and trusty-search do programmatically — indexing ideas, linking related thoughts, surfacing connections that wouldn’t otherwise be visible. Luhmann was doing manually what these tools do automatically. Same architecture. New substrate.

He didn’t use a vendor product. He built a system that reflected how he thought. The architecture of his Zettelkasten was itself an expression of his intellectual method.

This isn’t a historical quirk. It’s a pattern. Serious knowledge workers have always built their own systems — commonplace books, research archives, private wikis. The reason is structural: the schema you design reflects how you think. That’s not something a product gives you. A product gives everyone the same schema.

Andrej Karpathy pointed at something similar last month with his LLM Wiki gist. His framing: use LLMs not just to write code, but to build and maintain a personal knowledge base. “Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase.” Three folders, structured Markdown, a large context window. He concluded: “I think there is room here for an incredible new product.”

He’s right there’s room. I wrote about his framing in What’s In Your Second Brain? The product comment is where I’d push back. You can build tooling around the pattern. You can’t productize the schema. The schema is the moat — because it reflects how you think, not how a product manager thinks you think. The ones who get it aren’t waiting for a product.

The Lightsaber Rite of Passage

In Star Wars canon, a Padawan doesn’t receive a lightsaber. They build one.

The ritual is called the Gathering. Initiates travel alone to the Crystal Caves of Ilum. They have to find their kyber crystal — the crystal that’s attuned to them through the Force. The caves are shaped by the initiate’s own fears and insecurities. The crystal doesn’t go to the strongest or the fastest. It bonds with the person who confronts what’s in the way.

Then they build it themselves, guided by Professor Huyang.

You can’t buy this. You can’t inherit it. The construction is the training. The tool reflects the builder.

I’m not the first to reach for this metaphor in tech. But I think it lands differently now. Building your own AI memory and search layer isn’t just useful. It’s diagnostic. You can’t do it without confronting what you actually know, how you actually think, what deserves to persist and what doesn’t. The schema you design for your knowledge base is a statement about your mind.

The engineers I know who are operating at the highest level right now — CTOs, senior architects, tech leads at places moving fast — they all quietly roll their own. They don’t announce it. They just have it.

My Own Lineage

I’ve been building versions of this for months.

trusty-izzie was the first — a simple wrapper. Then ai-commander, a more structured approach to context management. Then open-mpm and claude-mpm, which was where I started thinking seriously about multi-agent orchestration. Then kuzu-memory, a graph-backed memory layer. Then mcp-vector-search, semantic search over my entire codebase.

Each iteration taught me something about what I actually needed. Not what I thought I needed. What the practice revealed.

This piece was drafted with a configured writing assistant — claude-mpm loaded with my publication style guide, my voice patterns, my article archive. That’s a saber too. Not a generic chat interface. A tool shaped around how I think and write, producing work I can actually publish rather than work I have to fix. The saber list keeps growing.

The latest two are the most capable tools I’ve built.

The Latest Sabers

trusty-memory is a machine-wide AI memory daemon written in Rust. It uses what I call the Memory Palace architecture — multiple named palaces, each for a different domain. Sub-5ms baseline retrieval on Apple Silicon. It runs as an MCP server for Claude Code, which means my assistant stores and retrieves memories automatically, across sessions, without me managing any of it explicitly.

cargo install trusty-memory

Available at crates.io/crates/trusty-memory.

trusty-search is a machine-wide hybrid code search daemon, also in Rust. Always-on, one install per machine. It combines BM25 lexical search with HNSW vector search (all-MiniLM-L6-v2 INT8) and a Knowledge Graph with 1-2 hop expansion, fused via Reciprocal Rank Fusion. It exposes an MCP server with 11 tools. Stdio and HTTP/SSE transports drop straight into Claude Code.

cargo install trusty-search

Available at crates.io/crates/trusty-search.

These tools, along a set of custom reporting pythons apps along with a custom Slack Bot I use to access the data remotely, comprise my digital brain.

These aren’t products I bought. These are tools I built, iterated, and use daily. They know my codebase the way a Zettelkasten knows a scholar’s intellectual territory — not because a vendor configured them, but because I did.

To be precise: trusty-memory and trusty-search are infrastructure utilities — the memory layer and the search layer. Building the actual assistant that uses them is a separate act of customization. That’s where the lightsaber metaphor completes: the kyber crystal is only part of it. The construction — what you build with the crystal — is the saber.

When Jake said he wished he had a CTO Assistant, this is what he was gesturing at. Not a prompt template. Not a workflow. A living knowledge layer that compounds.

The Right Question

Jake asked: “Can I get a CTO Assistant?”

That’s the wrong question. It assumes the thing is available off the shelf, and the task is finding and configuring it.

The right question is: “What would it take to build one that knows what I know?”

That question is harder. It requires confronting the shape of your knowledge, what’s worth persisting, how to structure retrieval. It’s uncomfortable in the same way the Crystal Caves are uncomfortable — not because the work is technically difficult, but because you have to be honest about what you actually have.

Not everyone needs to write Rust. The specific technology isn’t the point. The point is that the engineers asking the right question are already operating differently. They’re working like writers — maintaining a living body of knowledge, building systems that compound, treating their accumulated context as an asset rather than a liability.

Writers’ discipline has been creeping into engineering for a while. AI made it urgent.

If you’re waiting for a product to hand you the thing, you’re waiting for someone to build your lightsaber. It won’t be yours.

Bob Matsuoka is CTO of Duetto and writes about AI-powered engineering at HyperDev.

Related reading:

• What’s In Your Second Brain? — Karpathy’s LLM Wiki and the case for a compounding knowledge layer

• Everyone Blamed Clawd Bot’s Execution. The Concept Was the Problem. — Why universal assistants are architecturally broken

• AI Power Ranking — Tool comparisons and benchmarks for AI practitioners

• LinkedIn Newsletter — Strategic AI insights for CTOs and engineering leaders