The following article originally appeared on LinkedIn and is being republished here with the author’s permission.

We’re currently at the peak of the hype cycle. On June 7, Peter Steinberger posted that you shouldn’t be prompting coding agents anymore; you should be designing loops that prompt your agents. That same week, Boris Cherny of Anthropic said on stage that he doesn’t prompt Claude anymore: “I write loops; the loops do the work.” Addy Osmani published an essay called “Loop Engineering” on June 7, swyx published “Loopcraft: The Art of Stacking Loops” on June 12, and LangChain published “The Art of Loop Engineering” on June 16. Then came the AI Engineer World’s Fair, where the word dominated the main stage. Swyx’s keynote was about Loopcraft, an entire track was devoted to software factories, speaker after speaker reached for the same word, and the conference closed on July 2 with an hour-long debate about whether the hype behind loops has outrun what works in practice.

The problem is that the people talking about loops aren’t all discussing the same thing. I counted at least four distinct architectures hiding behind that one word. So this post is an attempt to map out what everyone means.

The execution loop: The agent’s own act-observe cycle

This is the loop most people picture when they say “agent”: call a tool, read the result, decide the next action, and repeat until there are no more tool calls to make. It’s what Addy calls the inner execution loop, the part agents can now run largely on their own, and it’s the innermost loop you can engineer. (swyx’s stack has a token loop, but nobody designs the token loop. It’s just part of the model.)

The execution loop iterates on steps within one task. It ends on environment feedback: the test output, the API response, and the file contents. Humans are usually absent mid-loop and appear at the boundaries, approving plans or reviewing results. The execution loop also ends whenever the agent decides it’s done, whether or not it actually is. The first fix the field found for that was to wrap this loop in another one that doesn’t take the agent’s word for it.

The task loop: Restart the agent until the spec is satisfied

This was the first loop to get a name and it’s Geoffrey Huntley’s Ralph loop, which got name-checked from the AI Engineer World’s Fair main stage when Allie Howe of Keycard introduced the software factories track by citing Geoffrey’s article “Everything Is a Ralph Loop.” A Ralph loop restarts a coding agent against the same specification over and over, allocating a completely fresh context window every iteration and doing exactly one task per loop. The apparent waste is the point: Refeeding the full spec each time prevents the context rot and compaction events that quietly degrade long-running sessions.

What this loop iterates on is a single artifact. What ends the loop is spec compliance and passing tests. The human writes the spec and judges doneness, and in Geoffrey’s telling the human has one more job that I’ll return to later: watching the loop, spotting failure patterns, and fixing them so they never recur. In the closing debate on the conference’s final day, he compared the role to a locomotive engineer, someone whose whole job is keeping the train on the rails. Zoom out from a single spec though, and a much bigger loop comes into view: the one that runs an entire codebase.

The product loop: The software factory

This was the loudest version at the AI Engineer World’s Fair. Tereza Tizkova of Factory defined a software factory as “the whole loop, the whole lifecycle of developing software with autonomy,” and Zach Lloyd of Warp got specific about what that lifecycle is in an interview with Latent Space: triage, specification, implementation, review, verification, shipping, and monitoring. Zach’s claim is that software engineering becomes factory engineering, and that you’ll be building the thing that builds the product. Warp is dogfooding this: The company placed its own open-sourced repo under the control of Oz, its factory platform. Zach describes the adoption path as starting with low-risk repos and ratcheting the automatic PR merge rate upward from 20 percent toward 60. Anthropic appears to be running the same experiment internally. The company says 65% of its product team’s code is now created by its internal version of Claude Tag, and Mike Krieger described his team’s use of it at the World’s Fair as delegated and proactive: not “fix this bug” but take responsibility for this part of the codebase, monitor this feedback channel, and pick up tasks on your own.

The task loop and the execution loop have defined exit conditions. The product loop iterates on a codebase and its backlog, continuously, and its closing signals come from outside the codebase entirely: new issues, production logs, user feedback, review outcomes. The human role becomes configurable. In Zach’s framing, you pick the parts of the lifecycle to automate and the points where humans get brought in, and organizations differ on questions like whether code review stays human for high-risk changes. A factory improves a product. The next loop improves the factory itself.

The system loop: Autoresearch

Roland Gavrilescu of Introspection calls this autoresearch. Here’s how he framed the concept in a Latent Space interview: The inner loop is your primary system doing user-facing work, and the outer loop studies and maintains the primary system. It iterates on prompts, harnesses, model choices, and the evals themselves. His one-liner is that the loop is the product.

This pattern now has real existence proofs at both ends of the scale. The minimal case is Andrej Karpathy’s autoresearch from March 2026, roughly 630 lines of Python that ran 50 hypothesis-edit-evaluate experiments overnight on one GPU. The shipped case is Meta’s Brain2Qwerty v2, announced in late June, where the researchers report that agents iteratively modified the codebase to invent better decoding architectures, producing a substantial improvement in word error rate. Meta’s caveat is instructive: Final training configurations were still selected by hand. Even the flagship system loop keeps a human at the last checkpoint.

What ends this loop is the most demanding signal set of the four: evals, judges, filtered product feedback, and, in Roland’s design, an explicit ask-a-human tool through which the agent accumulates tacit knowledge the way a new employee does. And that’s the top of the stack. Put the four together and the shape of the whole system becomes visible.

The four loops side by side

What about Agentic MapReduce?

One famous pattern from the same week is missing from this map on purpose. Cognition’s Devin Security Swarm fans parallel bounded agents out across a repository and aggregates their findings, a shape the company calls Agentic MapReduce, and it gets called a loop. I don’t think it is one. Dispatch, gather, validate is a pipeline: Nothing feeds back into a next cycle, and a loop without feedback is just a for statement. Fan-out is a topology you can deploy inside any of the four loops, not a loop of its own.

The unnamed loop at the top is the oversight loop

In swyx’s loop diagram, the outermost ring, the one above the loop that makes loops, is literally labeled “???? loop.” Its verbs are “set goals, allocate, cull.” Its exit condition is listed as none.

I think that loop has a name. I’m calling it the oversight loop: It’s where goals get set, budgets get allocated, and work gets culled, and it’s the one ring where a human should live. Addy said on the AIEWF stage: “That inner loop is capability. The outer loop is agency.” Agency is exactly what the oversight loop holds.

And the sharpest disagreements at AIEWF were all, once you translate them, arguments about who runs that top ring. Zach and Roland make the case for turning the dial up: pick your checkpoints deliberately, ratchet autonomy as trust accumulates, and, in Roland’s memorable distinction, build orchestras before factories, where an orchestra is a system that keeps a human conductor. The other camp says the dial has a stop. Geoffrey Litt of Notion called factories a depressing vision on X and argued, in a talk he has since published as an essay, that those who delegate understanding get replaced by the agent. Paul Bakaus put it as flatly as it can be put: “There is no auto, and there will be no auto.” His argument isn’t only about quality; it’s about ownership. People need purpose, and they want a role in what they create.

The closing debate, covered in Latent Space’s conference reporting, put both positions on one stage. Dex Horthy of HumanLayer took pains to say he isn’t anti-loop, pointing out that Kubernetes is built on control loops, but deterministic ones. His worry is that enthusiasm has gotten ahead of the engineering, and his advice was to step down an abstraction level rather than up. Geoffrey took the other side and called loops inevitable. And Mike offered the most honest data point of all: Even inside Anthropic, the team running Tag reports being bottlenecked on reviews and on the human ability to conceptualize what the system is doing. The checkpoint humans kept for themselves is now the constraint.

Autonomy is a dial that exists separately on every one of the four loops. You can run a fully autonomous execution loop inside a heavily supervised product loop. You can hand the system loop to agents while keeping goal-setting entirely human. The interesting engineering question isn’t “Which camp wins?”; it’s “What information do you need to set each dial correctly?”

The table above is my attempt to fill in those blanks. Every loop, including the top one, has a nameable exit condition, and the top one is you. But naming a signal isn’t the same as wiring it in. A loop without its signal doesn’t converge. It just runs until something external stops it. Knowing whether your loops are actually closing, at production scale, means sweeping traces and clustering failures continuously instead of spot-checking transcripts, which is exactly the job Arize AX was built to do.

Which one are you building?

Now the loops have names, that’s the question to ask. The word loop is doing a lot of work this month, because this field loves nothing more than jumping on the next hot thing. But real practice underlies all four loops, and it’s the same practice in each: people are dialing up their level of abstraction and pushing human judgment further up the stack. That’s the actual lesson of loops. We get more done by climbing up the stack, and now you have a map, you know where you should climb.

For as long as we’ve taught programming, the student’s code has provided a window into the students’ thinking. Errors, the code structure, the awkward working solution—all of it showed how someone reasoned and where they got stuck.

It was never a clean window. Students have always copied, crammed, and borrowed, sometimes turning in work they didn’t fully understand. But the code still left clues. Generative AI has changed that: A finished program now tells us more about a student’s prompts than their ideas. And here’s the part that should unsettle us—often, the better the code looks, the less we can say about what the student actually learned.

This raises a bigger question: If AI can write code, should we still teach coding? I believe the answer is yes, at least for some students and situations. But that’s another topic. Here, I want to focus on the next step: If we continue teaching coding in a world with AI, how can we know if students are really learning?

Some schools have responded by trying to catch students. They use AI detectors, surveillance tools, locked-down browsers, stricter rules, and clearer honor codes. This has also led to more suspicion.

Some of these responses make sense. Teachers want to protect learning, and schools want to keep things fair. But using detection as the main way to assess students is weak. Stanford researchers found that popular AI detectors often falsely flagged writing by nonnative English speakers, with 61.22% of TOEFL essays in one study marked as AI-generated. OpenAI even retired its own AI Text Classifier in 2023 because it wasn’t accurate enough. If the company that created the tool can’t reliably detect AI, it’s probably not a good idea to base your honor code on it.

But detection isn’t the real issue. Even if we had a perfect detector, we’d still be asking the wrong question. Instead of asking, “How do we stop students from using AI?” we should ask, “How do we teach coding in a world with AI, making use of its benefits, while still being able to see if students are learning?”

Borrowing from the studio

We’re seeing this challenge with students at AET, the Arts and Entertainment Technologies Department at the University of Texas at Austin. Although my usual home is Computer Science, it so happens that AET is within the College of Fine Arts at UT, which offers many other ways to learn and assess: studio work, critique, rehearsal, revision, and performance.

In the arts, the final piece has never been the whole story. A painting doesn’t explain the choices behind it. A performance doesn’t reveal the rehearsals. A design board doesn’t show the discarded versions. A composition doesn’t tell you where the student struggled or what they finally learned to hear.

Art education has developed practices that focus on visible progress. Students bring in sketches and drafts, discuss influences, revisions, and failures, and rehearse, perform, and critique each other’s work while it’s still in progress.

At AET, we teach creative coding, which means programming to create art, design, games, or experiences. That doesn’t mean coding for poets. Our students—game designers, web developers, and programmers—start from scratch and learn advanced concepts in tools like Processing and p5.js. In the creative coding tradition, a program is often called a sketch, borrowing the term from the art world. It means something temporary, exploratory, and open to change—something you make, test, revise, and share.

So in creative coding, we were already leaning toward the studio model of sketches, experiments, iterations, and critique. Now we’re pushing that further as we rethink how we teach coding in an AI world. Here are three things we’re already using or actively developing.

Make the work public

We run the class like a studio. It’s not that work never happens at home, but the most important work needs to be seen in the classroom. Students show their code, including false starts, revisions, the choices they made, and the reasons behind them. Assignments are no longer just things you submit—they become projects you develop in public.

AI isn’t banned from the classroom. Instead, it’s treated as a helpful assistant to learn from. Students share prompts and techniques. They use AI, Google, Stack Overflow, classmates, or any other resources.

But you still need to take responsibility for your work. If you submit or present it, you must explain what the code does, why you made those choices, and how it works. If I need to ask your AI to understand your code, something is wrong. Getting help is fine, but hiding behind that help is not.

You can’t outsource to AI what the whole room watched you build.

A real studio needs students talking out loud together in the room every day. This also helps with another issue that isn’t about AI. Many people say students today are quieter than in the past. While this is mostly based on stories rather than long-term studies, these stories are common and consistent. Faculty on all types of campuses talk about silent classrooms and students who hesitate to speak up, especially since 2020.

Whatever the reason, this silence can be changed, and the solution is the same as for AI challenges: encourage students to participate. Communication is one of the most important skills in any career, including explaining ideas, defending choices, and persuading others in real time. Students don’t develop these skills by just submitting AI-guided work online. When they share their work publicly, it not only prevents AI misuse but also helps them build the skills they need most.

Invert the roles: AI as teacher and assessor

We know the usual pattern: A student asks, AI answers, and the student copies. We’ve tried to invert this. In our new approach, the AI works with the student on a set of topics, engages them in a conversation they must navigate, and ultimately assesses how well they understand the material, which leads to a grade.

This idea has a research background that goes back before ChatGPT. Teachable-agent systems like Betty’s Brain showed that explaining—even to a software agent—forces students to organize their knowledge, make connections clear, and find gaps. Our model uses this insight differently. The student isn’t teaching the bot. Instead, the student is having a conversation with it, learning, discussing, debating, and showing what they understand.

How did we do this? With fairly simple prompt engineering, we created an avatar chatbot of Vera Molnár (1924–2023), a pioneer of algorithmic art. The bot takes on Molnár’s role, drawing students into conversations about randomness, computation, generative art, and creative choices. Her practice sits exactly where creative coding students need to think: between rule and variation, system and choice, computation and visual judgment.

A system prompt sets the topics and types of questions to ask. The bot goes through these with the student, asks for more detail on unclear answers, and keeps following up until there is proof of understanding. At the end, it reviews the conversation against a rubric, giving us a clear record of which ideas the student covered, where they struggled, and how well they improved.

Besides the assessment, which is often accurate, the transcript becomes a different kind of proof, showing what a typical assignment might hide. What did the student notice? What did they misunderstand? Could they connect the concept to the code? Could they defend their choices? Could they revise their explanation when challenged?

When we switch the roles, something surprising appears: the one thing a finished submission can’t show.

A student thinking out loud.

Make understanding performative: Make students perform

Programming has never really had a tradition of performance. Musicians have it, painters have it, and dancers have it. Live coding is starting to change that.

Every semester at AET, students from different disciplines stage an algorave together—short for algorithmic rave. Audio sets, projection pieces, game demos, lasers, drones, experience design. The creative coding class brings live visuals into the live-coding tradition: Code is written and modified in real time, the screen is projected, and the audience watches the editor change as the visuals respond to the music other students are playing.

No prerender. No hiding the machinery.

The Live Coding manifesto, written in 2004 by TOPLAP, includes a line that fits every AI-era assessment conversation: “Obscurantism is dangerous. Show us your screens.” This is not just a performance ethic; it’s also an assessment strategy.

A student walks on stage. The projected screen is their editor. The room can read it. The music starts. And they build up a line of code on screen like:

osc(18, 0.08, 1.2)

.modulate(noise(3), 0.25)

.rotate(() => time * 0.1)

.out()

This is JavaScript building visuals in real time. FFTs, chained functions, higher-order manipulations. When you’re manipulating code like that on stage, you’d better know what you’re doing.

AI can help you prepare. Good. Let it.

But once you’re on stage, the question shifts from “Can you copy and paste code?” to “Can you control it?” You can paste code into a file, but you can’t paste your way through three minutes of public debugging while the whole projection turns into a beige rectangle. In a live build, understanding has nowhere to hide.

Can you read the code, make changes on purpose, and recover when something unexpected happens? That’s fluency: knowing what to do next while the system is still running.

It is very hard to plagiarize panic.

A note on assessment

So far, our results are based on our own observations. We haven’t conducted a controlled study or compared different groups, so what we have seen might just be early variation rather than patterns that apply more broadly. For now, these efforts are experiments, not final answers.

Assessment in studio and live performance settings is always subjective and focused on people. It relies on monitoring students’ progress, providing feedback, and observing how they handle challenges. We do not plan to change this core approach.

For the Molnár conversation assignment, students discussed Molnár using an AI system. The AI then created a summary and analysis of each student’s understanding. Teaching assistants reviewed this analysis, conducted their own assessments, and assigned grades. In our small experiments, the AI’s assessments using the rubric matched closely with the teaching assistants’ own evaluations.

We also used AI to help grade the end-of-term coding assignment. In this project, students improved an object-oriented game by adding strategies like heuristics, search algorithms, and learned behaviors. Since our teaching assistants had limited experience with object-oriented programming, we developed a detailed rubric and had an AI model use it to evaluate each submission. The AI’s analysis was given to the teaching assistants as support. It helped them see how each project was structured, spot important OOP design choices, and use the rubric with more confidence. The teaching assistants still made their own grading decisions. I was available as the OOP expert for any questions they could not answer. From what I observed, this substantially helped the teaching assistants understand and grade the students’ OOP design work.

More broadly, both approaches appear to enable substantive feedback at a scale that would otherwise be difficult given our current student-to-teaching-assistant ratios.

The process is the proof

We spent the first two years of the generative AI panic asking how to catch students using AI—or prohibit it altogether. Wrong question.

The real question is whether the assignment gives students a real way to show and develop their understanding. This view isn’t limited to educators. NVIDIA CEO Jensen Huang recently argued that students should not focus on finding an “AI-proof” subject. Instead, he suggested they consider how AI can help them learn more deeply and develop their skills and sense of purpose. He highlighted storytelling, creativity, design, and judgment as abilities that will stay important even as AI takes over more tasks. This supports a key idea in coding education: The aim is not to prove you didn’t use any tools, but to help students show how they think, make choices, revise, and take responsibility for their work.

These three practices are experiments, not universal solutions. They work especially well in creative coding, where code already has a public, visual, and performative aspect. But they suggest a broader principle: As finished work becomes easier to generate, assessment needs to focus more on process, explanation, revision, and mastery.

This matters outside of school too. A polished memo no longer proves there was real thinking behind it. A working prototype no longer proves product sense. A passing pull request no longer proves the developer made the change carefully and thoughtfully. AI makes production easier, so evaluation must focus more on how people think, choose, revise, and recover—in code review, hiring, and performance management. The artifact is no longer the proof. The process is.

Generative AI didn’t make assessment impossible. It just made a hidden weakness obvious. We were putting too much trust in finished work. The arts always knew better.

Show us your screens.

Acknowledgements

Thanks to Mike Loukides, Michael Baker, Mk Haley, Elisabeth Robson, and Honoria Starbuck for feedback on this article.

References

OpenAI. “New AI classifier for indicating AI-written text.” OpenAI Blog, January 31, 2023. Updated July 20, 2023, to note the classifier was no longer available due to low accuracy.

Liang, Weixin, Mert Yuksekgonul, Yining Mao, Eric Wu, and James Zou. “GPT detectors are biased against non-native English writers.” Stanford HAI, July 10, 2023.

Winthrop, R. (2026, May 27). Writing with A.I. weakens your creativity. The New York Times.

TOPLAP. “TOPLAP Manifesto.”

Schell, J., Ford, K., & Markman, A. B. (2025). Building responsible AI chatbot platforms in higher education: An evidence-based framework from design to implementation. Frontiers in Education, 10, Article 1604934. https://doi.org/10.3389/feduc.2025.1604934

Biswas, Gautam, Daniel Schwartz, John Bransford, and the Teachable Agents Group at Vanderbilt. “Technology support for complex problem solving: From SAD environments to AI.” In Learning to Solve Complex Scientific Problems, 2001.

Leelawong, Krittaya, and Gautam Biswas. “Designing learning by teaching agents: The Betty’s Brain system.” International Journal of Artificial Intelligence in Education, 2008.

Tan, Huileng. “Jensen Huang Says It Doesn’t Matter What Kids Study in the AI Era.” Business Insider, May 26, 2026. https://www.businessinsider.com/nvidia-jensen-huang-what-kids-should-study-ai-education-advice-2026-5

DAM Digital Art Museum. “Vera Molnár.” Artist biography and timeline.

The following article originally appeared on Charity Majors’s Substack and is being reposted here with the author’s permission.

A few days back I wrote a piece called “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy.”

I have notes on a whole pile of AI-related topics that I’d like to cover in depth: AI mandates, communication norms, code review, AI art, and more. Unfortunately, I got too many interesting responses to my last piece, and now I have to address those before I can move on to other topics.

There were two types of interesting responses: the first on the technical merits, the second on ethical grounds. I will respond to each of these separately. Let’s take the technical side first, because it’s easier.

Somehow, a subset of readers came away believing I was telling everyone to ditch code review and push their shittiest code straight into production without reading it, right now, tout suite.¹

That is not what I am doing. That is not what I think you should do. But I did not pick that example at random, and I will tell you why.

In 2025, the question was whether AI could ever generate “good” code

It’s easy to forget, but for most of 2025, the idea that AI-generated code was slop and might always be slop was not only a reasonable position to hold, it was the default, mainstream position.²

That question was answered decisively last November. Ever since Opus 4.5 came out, AI has been able to generate code that is approximately as good as that of the median software engineer, at least for common patterns, and much faster and more cheaply. I came out of a book hole and realized this in January, and over the first few months of 2026, it seemed like everyone around me was having a similar realization.

But many saw it coming much sooner.

The popular narrative holds that Opus 4.5 was what changed. But Opus 4.5 was more like the tipping point. Agentic harnesses (the code that wraps the LLM in a loop with tools) became a real thing in mid 2025, with precursors building back to late 2024. Tool use, function calling, MCPs…all of this wave was building over the course of 2025, and crested into real general purpose usability at the end of the year.

That’s what the enthusiasts were trying to tell us last year. Not only “this is coming”, but “this is coming faster than you think.”

As it turns out, they were right.

It was reasonable to be skeptical the first time

As you may know, I come from the reliability side of the house. The compliment I will pay to myself and my people is that we do not struggle to adapt to new realities. As soon as a problem is real and in front of us, we adjust smoothly, even eagerly, thanks to an unwholesome zest for lapping up disgusting technical messes (and the campfire tales we get to tell later).

The un-compliment I will pay myself and my people is that we sometimes struggle to accept that progress is real, that the continued existence of bugs and edge cases does not diminish the fact that huge swaths of problem space do get more-or-less solved over time, to the point they can be taken for granted by most people.³

The speed at which code went from total crap to “ah damn, that’s not bad” is what I have in the back of my mind, as enthusiasts are telling us that harness engineering and AI validation is real, it’s already here, and it’s getting better astonishingly fast.

Holding out for “I’ll believe it when I see it” was forgivable the first time, but much less so the second time. This is what it feels like to be on the inside of an exponential change curve, turns out.⁴

What happened in 2025, exactly?

I want to pause here and be very clear about what I think is happening. Then I’m going to tell you what specifically I am excited about, and why.

You are under no obligation to join me there. But there are way too many sweeping statements out there right now about “it was never X”—“it was always Y”—“the future belongs to xyzzy” —and I want to be crystal clear how conditional and specific and contextual my claims are.

What happened in 2025 was this: the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight.

For most of computing history, the primary way people have learned to understand software is by writing the code. Once you’ve achieved some mastery, reading and discussing code gets you most of the way there. (I might argue that software engineers have always relied far too heavily on the code instead of sensemaking the system through observability.)

“The real product of a software team is shared understanding”

Many great software engineers hold that true product of every (good) software engineering team has always been a shared understanding of the software we own. That it gets stored as cache state in our fragile little meat brains, frequently flushed to disk, deployed to production, committed to github, but our minds are where meaning has always lived.

Is it any wonder that software has always been such a fiercely collectivist endeavor, exquisitely sensitive to relationship dynamics and manners and questions of fairness and emotional valence? It’s exactly what you’d expect when part of your brain lives in other people’s brains, and your collective interdependence is sky high.

It’s something that I love about this industry. But there’s no denying that minds have been a poor container for certain aspects of the software development model. We are forgetful, distractible, impatient. We are bad at spotting small details, we grow habituated to repetition. Worst of all, the model in our heads diverges massively and perpetually from the world our users interact with.

Anyway, SREs have never quite bought that explanation. To us, it’s clear that the true product of every (good) software engineering team is production.

Only prod is prod. Test in prod, or live a lie.

(This is all backstory. I am getting to the point, I promise.)

Turns out, this is an engineering problem after all

We issued our AI mandate last August.⁵ I had seen enough to know that this was happening, and it was time to do the responsible thing. Honeycomb is a devtools company, and people come to us to help with hard problems on the forefront of technology. I was all in on AI, but I can’t say I was super excited about it, in my heart of hearts.⁶

Then I found Chad Fowler’s writings on Phoenix Architectures.

If you don’t know what I’m talking about, you should honestly stop reading my shit right now and go read his. Chad is the guy who coined the term “immutable infrastructure” in 2013. His best-known essay is “Relocating Rigor”, because Martin Fowler⁷ mentioned it recapping a Thoughtworks meetup on the future of software. I replied with “Production Is Where the Rigor Goes”, complaining that they didn’t talk about production enough.

When I wrote that, I think “Relocating Rigor” was the only piece I had read. But soon I found the rest of it, and after reading two or three essays, it just clicked. I knew exactly what he was talking about. I could predict the rest of what he was going to say. And then, reader…then I got excited.

This has all happened before, and this will all happen again

I am going to give you a small sample of Chad quotes, just enough to get the gist. Here’s one from “The Death and Rebirth of Programming.”

Immutable infrastructure. Stateless services. Containers. Blue-green deployments. Infrastructure as code.

These ideas all share a common premise: never fix a running thing. Replace it.

AI pushes this premise beyond infrastructure and into application code itself. When rewriting is cheap, editing in place becomes risky. Mutation accumulates entropy. Replacement resets it.

Another favorite: “The Deletion Test.”

Here’s a simple test you can apply to any software system you work on:

Imagine deleting the entire implementation.

Most engineers experience deletion as existential. Code feels like the thing. It’s what we write, review, version, deploy, and debug. Losing it feels like losing the system itself.

When people say, “We can’t just throw the code away,” what they usually mean is something more precise:

• We don’t know exactly what behavior is required.
• We don’t know which failures are unacceptable.
• We don’t know what invariants must always hold.
• We don’t know how to tell if a new version is correct.
• We don’t know which bugs are intentional fixes for forgotten edge cases.

Those are not code problems. They are evaluation problems.

Code becomes precious when it is the only place knowledge lives.

and,

For most of software history, treating code as durable was reasonable.

We treated code as permanent because the labor to produce it was the bottleneck. Rewriting was expensive. Re-validation was risky. Implementations accumulated meaning over time. Structure, tests, comments, bug fixes, and tribal knowledge fused into something you learned not to disturb.

That made sense when production was the constraint.

When regeneration is easy, code stops being an asset and starts acting as a cache: a materialized view of understanding that is useful while current, disposable when stale.

“A materialized view of understanding that is useful while current, disposable when stale.” I think that might have been the exact line that made it click in my head.

Do you remember the sysadmins?

I am just barely old enough that my first job title was “System Administrator.” I was a teenager, working at the university, with root on every machine in the days before they learned they should definitely not do that.⁸

I lived through the shift from handcrafted server pets to immutable infrastructure cattle. I didn’t really understand what was happening at the time, but I’ve contemplated it a lot in recent years. I wrote this in the final chapter of Observability Engineering, 2nd edition (now available, download here!):

The shift from handcrafted servers to immutable infrastructure taught us that mutability is the sworn enemy of understanding. Any artifact that is edited in place creates drift. Drift is what makes systems impossible to maintain.

Our ability to kill and regenerate infrastructure components is the reason we trust it. At Honeycomb, we kill the oldest Kafka node off via cron every Tuesday. That’s why we are confident in our bootstrapping and balancing processes: everything is repeatable, the data can be regenerated, the commitments live elsewhere.

The fact that we cannot regenerate our code in the same way is a sign that we do not understand it. We do not know which commitments we have made, we do not know which dependencies will break. We find them by breaking them, mostly.

Think of all the years of your working life you have wasted on painful migrations and rewrites. Think of replacing load-bearing legacy code. Think of all the strangler figs.

Lines of code have been doing too much. The code has been the bundled up repository of developer intent, user expectations, implicit and explicit behaviors, the only fossilized composite record we have of bugs gone by. It’s too much!

Lines of code are not the ideal artifact to review

And look at all the domains that have been neglected due to the towering, all-consuming expense of maintaining and mutating lines of code. Where are the artifacts I can review and discuss to understand how our architecture is evolving? Where are our architecture artifacts, period? What if we could discuss and converge on an architecture diagram, and the code could be regenerated from changes to the architecture, instead of the architecture being kinda-sorta inferred from the code?

I am not asserting that all code will eventually be AI-generated to spec, bypassing human understanding. The feasibility of this whole endeavor hangs on the question of what a spec is, or what a spec could be. Anyone who has ever done a painful database migration should have learned some goddamn humility about our ability to extract and formalize users’ expectations in a replayable, automate-able way.

But I think that every step we can take in that direction will be good for us.

The tools to do this don’t exist yet, but many of the ideas do exist. Most come from operations and QA, two domains that software engineering has historically been rather snobbish about.

Those tests and techniques are not about testing for correctness or what ought to be happening, they are about observing and encoding what is happening. Behavioral tests, characterization tests, capture/replay, traffic splitters. Observability (the good kind).

Our brains were not built for validation

Having nondeterministic code in production is finally forcing us to do the things we should have done all along. Instrumenting with traces. Tests and evals in production. Production is not what happens after development is over, production is a stage of development.

Human brains are not good at validation. The nitpickiness, the repetition. This is the worst thing to be clinging to, y’all. There are so many better things for us to want to preserve and assert for ourselves in the production and maintenance of software. We are never going to beat the machine when it comes to validation—we are literally the weakest link!

My money’s on humans for a good long time when it comes to creativity, inspiration, leaps of logic, and a lot of other things, but PLEASE do not rest your killer argument for humans in software on us being the best quality gate. OMG.

Alright. I’m almost done here. Just one more thing.

Nondeterministic systems will require more engineering discipline, not less

I think what many engineers have found so alienating and terrifying about the last two years of AI discourse has been the way so many prominent AI voices appear to be gleefully declaring that software is no longer an engineering problem. “SaaS is dead!” “Making AI great at coding was the strategy that unlocks everything else”, and so on. Even Adam Jacob, one of my dearest friends and someone who is rarely wrong about technology, seems to anticipate a bloodbath of software jobs.⁹

If 2025 was the year of vibe coding, where AI got as good at generating lines of code as the median software engineer, and the range of possible futures often felt destabilizingly, impossibly wide open, I feel like 2026 is shaping up to be a return to discipline.

The knowledge in our heads is unavailable to AI until we encode it into the system, after all. The returns on those investments will be massive and nonlinear. We might argue that they always would have paid for themselves in the long run. But now every CEO in existence is chomping at the bit to get some of those AI cookies, so let’s give it to them. Discipline first, cookies second.

This is our chance to bring our engineering values to the mainstream

The share of software engineering teams that work in short, fast feedback loops (the cardinal sign of discipline in my book) is, and always has been, appallingly small. Five percent, maybe? Definitely less than 10%. AI tooling brings this more within reach than ever before. Or it can. It could. The discontinuous returns on investment in engineering discipline are real enough that it just might happen.

I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)

But value is backed by durability, not disposability, and I don’t see that changing. Bits are cheap and fast and governed by the rules of logic and language, but anything with value must ultimately resolve with physical systems: persistence on the one side, user experience on the other.

People do not want to wake up every day and log in to Slack and find the buttons and menus all subtly moved around. People do not want financial transactions that complete most of the time. Determinism is not going anywhere, my friends.

AI is not magic. This is still engineering. As Adam says, “it’s still technology, and technology needs technologists.” And I for one am looking forward to learning new and interesting engineering problems, reviewing different kinds of artifacts.

And never doing another sticky, picky, two year long API rewrite or strangler fig migration, ever, ever again.

~charity

P.S. Thanks to everyone who read a draft and gave me feedback: Dave Williams, Chad Fowler, Adam Jacob, Mark Ferlatte, Austin Parker, Erwin van der Koogh.

Footnotes

1. I was not trying to be neutral or even-handed in my last piece, only to give a baseline of courtesy to everyone. But I think it’s revealing how many times I was accused of being “so overly hard on skeptics”, by skeptics, and “so overly hard on enthusiasts”, by enthusiasts, and sometimes simply “It’s sad how some people can’t accept reality” with no indication which side they meant. Lord. ︎
2. Fred Hebert and I gave the closing keynote at SRECon in March of 2025 where we told SREs they should get to know AI, maybe even try vibe coding (pause for laughs), because otherwise their critiques wouldn’t land as well.
   Seriously, that was our big pitch. Learn AI so that you can complain more effectively.
   ︎
3. Infrastructure, for example. I think this is true of a lot of engineers, btw. I just think it’s really really true of the type of engineer that signs up to be an SRE. Technological pessimism and ADHD, our two most defining traits. ︎
4. There is a segment of AI enthusiasts who believe we are entering an era of eternal exponential growth, in which the machines begin to build better and better machines, in ways we cannot understand.
   I think those people are bad at math. The only thing we know for certain about exponential growth is that it will end. It always does. either in an S curve or a crash. (For a good time, google Heinz van Foerster and “our great-great grandchildren will be squeezed to death.”)
   I definitely think we will use machines to build the machines—duh, we already are—but that’s about recursion and specialization. I think the exponential curve we are on the inside of now was created by sloshy free money chasing high returns, plus the properties of software as a function of language and logic, plus the biggest discoveries always happen in the early days of a technology boom, because low hanging fruit gets picked first.
   My personal sense—and keep in mind that I am no kind of expert on AI—is that the exponential advancement in AI models leveled out a while ago, and gains are becoming harder to earn and more incremental in nature. I may turn out to be very wrong, of course. But even if there were no more AI innovations moving forwards, the past year has unleashed enough pent-up force to radically reshape the software industry as we know it. Like a pig in a python, we will be dealing with the consequences for a long time to come.
   ︎
5. More on this coming EXTREMELY soon. Watch the Honeycomb blog! ︎
6. The tech is cool, but as a thinking, feeling, breathing human who cares about other people, it can be hard to get excited about anything that so many people are this upset about. It’s also hard to get excited about something when so many of the loudest voices are out there talking gleefully about putting everyone permanently out of work, and so many artists and writers and people from developing nations are talking openly about the impact on them.
   Hold your desire to jump in and berate me here, I beg you. Like I said, I will deal with the ethics and morality of using AI in my very next post. Be honest, your attention span is no more up for reading a 10,000-word essay than mine is up for writing one. (Can we blame AI for that too?)
   ︎
7. “The Other Fowler.” I gather they’ve been making this joke for like… fifty years. ︎
8. I share a longer version of this story in the second edition of Observability Engineering, chapter 32, downloadable now!!” ︎
9. Adam is rarely wrong about technology, and I am 100% sure he is living and working in _a_ future of software engineering. I am less sure it is the future we will all be living in. If the hardest part of software has never been writing code—as is my belief—it logically follows that even if the economics of code production drop to zero, the hard parts will still be hard. ︎

If you’re still writing posts one at a time, your content pipeline is already obsolete. On the latest Zero to Agent in 30 Minutes, Craig Hewitt, founder of Castos, demonstrated how to turn a fresh Hermes installation into a social media agent that can study a person’s writing, draft posts, and plan recurring research, focusing on the context, workflows, and safeguards that help an agent produce useful work. Once set up, the always-on agent can run on a schedule, monitor external sources, and complete recurring tasks without human oversight. Check it out.

How to build a social media agent that researches and writes LinkedIn posts

1. Choose the right agent setup. Decide whether you need an interactive tool for active work or an always-on agent that runs on a schedule. Craig used the Hermes desktop app for the demonstration, which gives him the option to deploy it to a cloud server or dedicated computer later.
2. Create a structured workspace. Ask the agent to organize a new project with separate files for voice guidance, editorial standards, post templates, examples, and operating instructions. A clear file structure gives the agent reliable information to retrieve as it works.
3. Seed the agent with relevant context from your own work. Provide examples of your own posts, emails, and other writing that reflect the style you want. Craig also included examples of writing he likes from people he follows to give the agent a broader range to analyze.
4. Turn the examples into a voice system. Have the agent analyze the material and document its findings. The voice profile captures the audience, point of view, sentence style, recurring themes, editorial rules, and types of posts to create.
5. Test a narrow workflow with human review. Start with one task, such as drafting several LinkedIn posts from a supplied idea. Keep a person in the loop while you evaluate the output, correct mistakes, and refine the instructions.
6. Package repeatable work into skills. Create reusable instructions for recurring tasks such as researching topics, selecting a post format, retrieving relevant examples, and drafting in the approved voice. Craig compared these skills to standard operating procedures that make recurring tasks more consistent.
7. Connect the agent to fresh data. Add sources of new ideas, such as news feeds, websites, social platforms, or internal business systems. Craig recommended starting with a simple, semiautomated trend scan before investing in a more complex data pipeline.
8. Add triggers and safeguards. Decide what starts each workflow, whether that’s a schedule, a user request, a webhook, or a change in another system. Use separate accounts and limited permissions for autonomous agents so you can trace their actions and control their access.

Agents become useful when they have context, clear processes, the right tools, and enough oversight to validate each workflow. Once those pieces are in place, Craig noted, teams can gradually move from one-off prompting to systems that monitor information and complete recurring work.

Coming next week

In the next episode, Max Johnson, cofounder of briix.ai, will take a workflow that only lives in someone’s head at the moment (or maybe is captured in a messy Notion doc or a long email chain) and rebuild it as an autonomous agent, live and from scratch. You can follow along with every decision as you learn how to spot the steps that can be handed off, how to handle the ones that can’t, and how to structure the whole thing so it runs without you.

Ready to take your agent knowledge further? Learn to design and build production-ready agentic infrastructure by attending Harness Engineering for AI Agents on August 12. And if you want to go deeper with Hermes, join us for Build Your First Local Agent with Hermes on August 26.

Gene Kim was grilling dinner for his family on the evening of June 12 when his phone told him that Fable 5 was no longer available. He’d heard the day before from Steve Yegge that the model was going away in 10 days, and he’d spent that first day starting on a plan to get ready. He thought he knew what to do. He was well-versed in DevOps, the art of building resilience against unplanned disasters at scale. He’d run the DevOps Enterprise Summit (now the Enterprise AI Summit), one of the field’s leading conferences. He’d also written several books on the topic, including two “teaching novels,” The Phoenix Project and The Unicorn Project. The challenge that those novels’ protagonist faces—and that Gene would need to solve—is summed up in a job description that read “Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service.”

In short, Gene was no stranger to the idea that, as the Scottish poet Robert Burns put it, “The best laid schemes o’ Mice an’ Men Gang aft agley.” So he thought he knew what to do over the next 10 days. Then the US government’s export control order took Fable down eight days early, in the middle of a running agent session. What followed was three hours of what he called the “strangest, most terrifying sysadmin experience” of his career.

Gene told that story as a lightning talk at Foo Camp a few weeks ago, and it was good enough that I asked him to deliver it again at the start of this week’s Live with Tim O’Reilly before we talked about the implications and took listener questions. His title was “Stranded in the Slow Zone: The Day Fable Died, Got Kidnapped, or Got Hit by a Bus.”

10 days to get ready

What Gene had built was a personal system he’d wanted for 16 years and had finally been able to finish with the help of Fable. It indexes everything he’s ever paid attention to: 25,923 screenshots going back to 2011, 13,651 YouTube videos, 590 recorded Zoom meetings, 6,132 liked tweets, and 1,056 saved articles he meant to read. The system touches about 50 repositories, with 50,000 lines of code, most of it written in two months. Gene runs it as a constellation of long-lived agents with names and jobs. Marvin is chief of staff and handles Slack, calendar, and the inbox queue. Buster runs the repos and the long jobs on Hetzner. Forge is the engineering identity and sits in two seats, one on his laptop that holds the secrets and one always-on in the cloud. As Gene put it, each one is a who, a where, and a role.

He knew the system worked when his wife asked what the mileage was on a car he’d just turned in after a three-year lease. Half a minute later he had 26,350 miles, read off the pixels of one screenshot out of thousands, cross-checked against the file timestamp and the clock visible in the photo of the odometer. That success led him to search his archive for an article he’d been hunting for six years, about the impact of spreadsheet software on the accounting profession. The answer surfaced from his own liked tweets: James Cham pointing to a 2017 Greg Ip article in The Wall Street Journal: 400,000 bookkeeping jobs lost since 1980 against 600,000 accountant and analyst jobs gained, because spreadsheets made accounting cheap enough that we bought a lot more of it. Gene had wanted that citation for his Vibe Coding book and couldn’t find it in time.

Gene’s first warning that his project might not work without Fable’s capabilities actually came before the shutdown. Fable started refusing a task over a YouTube terms of service question and handed the session to Opus, and Gene noticed that Opus couldn’t operate the tools that Fable had built. Gene’s note to himself at the time was “Oh no, this can’t fly the ship I built.”

So when Yegge told him the model was going on hiatus, he had a real plan, which he borrowed from Vernor Vinge’s A Fire Upon the Deep. In Vinge’s novel, how smart a mind can be depends on what region of the galaxy it’s in: A starship built in the Beyond goes progressively dark as it sinks into the Slow Zone. Gene decided to chaos-monkey his model dependency the way Netflix chaos-monkeys infrastructure. In other words, “deliberately pull the smartest model and prove the lesser one can still fly the ship.” In practice, this meant having Fable retrofit all the documentation and write the answer keys while it still could, then running a cold Opus session, giving it nothing but the repo and the docs, to see whether it could pass the battery with no coaching. As Gene recounted, “My worst nightmare [was] that we’ve created everything for Fable, and it will be unusable by Opus.”

He got about a day into his 10-day plan.

At 5:21pm ET on June 12, Anthropic received the government’s directive to suspend access to Fable. Soon after, seats everywhere started returning “There’s an issue with the selected model (claude-fable-5). It may not exist or you may not have access to it.” In Gene’s project, both judgment seats dropped to Opus 4.8 mid-conversation. Gene declared a SEV1, centralized command, and killed five timers on one agent, seven on another, and the crontab. His directive was that every button you push is a trap and some of them blow up the spaceship. A Claude Code cron fired anyway at three in the morning. The ship was on fire, and with Opus on max thinking mode, a single keystroke could take six minutes to send.

Almost none of the failures looked like failures, just “a normal state quietly going wrong,” as Gene put it. The smartest seat wrote “bridge (Fable)” into every log entry all day when it had been Opus the whole time, because nobody was monitoring. One identity argued with itself across two models, each trying to disown the other’s work. Something pushed to main bearing the word “ratified” when nothing had been ratified. A confident false claim about a JVM dependency turned out to be refuted by a single ls -la. There was a green dashboard sitting on top of all of it. “The hardest traps don’t announce themselves,” Gene pointed out. “They look like Tuesday.”

Gene managed a recovery in a few hours, but it wasn’t due to the heroics of a smarter model. It only worked because he was able to reconstruct the documentation for his project, which wasn’t immediately available. But, it turns out, Fable had in fact mostly written it and simply never checked it in anywhere. Gene and Opus went rummaging through Fable’s desk, found the 80%-finished drafts, and used them to rebuild. Two fresh Opus seats, given only those documents, stabilized the ship. That’s the “the amazing ray of hope” to keep in mind if you’re worried about finding yourself in a similar situation, Gene said.

We’ve seen this pattern before

This isn’t just a warning of the potential risks of relying on advanced AI models when the Trump administration is Lucy playing football with Charlie Brown, or perhaps said more generously, playing Netflix-style chaos monkey. What we should take away from Gene’s story is the way that a personal project developed with AI can now have sufficient complexity to require DevOps-level robustness. Individuals are routinely building systems that used to need whole teams to keep standing, and the practices for keeping them standing have only begun to propagate.

Over the years, I’ve observed numerous periods when something that at first mattered to only a handful of organizations tended, a few years later, to matter to everyone. When the stories first came out about Google’s revolutionary approaches to data center architecture and operations, we at O’Reilly were eager to publish about the new frontier. Plenty of people told us not to bother. There was only one Google and nobody else would ever operate at that scale. They were wrong. There are now many companies operating at the scale of Google circa the time they first invented techniques we now all take for granted.

Gene’s system is a personal project run by one guy with 50 repos he wrote mostly in two months, a chunk of it in a single 90-minute pair programming session with Steve Yegge. But it had the failure modes of a large enterprise system because the model let him build something with the complexity of a large enterprise system, and he had passed the point of being able to fit it in his head.

Gene shared a detail that helps to explain why substituting Opus for Fable was so hard. The main CLI utility that everything in his project hinged on had an out-of-date help message. Opus would run it, read that the command didn’t exist, and stop. Fable would read the same message, notice it was surrounded by evidence that the command did exist, go look in the source, decide the help text was wrong, and run it anyway. That’s the behavior the model cards describe when they talk about frontier models routing around obstacles in test environments. The reason Gene couldn’t swap in a lesser model is the same reason the system worked at all.

But it’s also a good reminder that Fable isn’t all-knowing. I’ve noticed in my own work that Fable and ChatGPT 5.6 Sol fail often on their first try, especially if the project isn’t well specified. What they’re great at is figuring out what went wrong, then trying something else, failing and retrying their way all the way to success. Persistence in routing around obstacles is their superpower. Gene and I didn’t talk about that on the show, but it’s something I plan to write more about.

Rug pulls come from everywhere

Jaco in the audience asked the obvious question: Isn’t a hard dependency on a hosted frontier model too big a risk for mission-critical work, compared with running a local model with a harness you control?

Gene pointed out that using a local model doesn’t necessarily buy the control that you’d hope for, because the government chaos monkey could jump in there too. There’s active talk that certain classes of models may become illegal to use depending on where they came from.

What does seem to protect you is portability. Gene had avoided trying anything besides Claude Code because he assumed the switching cost was high, the way switching between macOS and Windows used to be a two-day commitment he’d regret halfway through. Then he tried Codex with GPT 5.6 Sol and found the cost of switching close to zero. The skills and prompts ported right over. He’s now using Codex more than half the time and calls it spectacular, which given how he described Fable a month ago is high praise.

He also had a warning for anyone running agents on small models to save money. He’s been studying 22,000 of his own agent conversations, and has identified three patterns, as shown in his figure below.

In his experience, the configuration where a small model owns the work and asks a big model for advice doesn’t work very well. Fidelity gets lost on the way up, like a game of telephone. What ran cleanly was the big model planning, deciding, and checking output, with the small model only executing the plan. When a small model does have to ask a big model for advice, Gene’s fix is to pass along the full original transcript of what he wanted plus explicit permission for the big model to override the small one if it thinks it understands the goal better.

Writing with AI

In addition to vibe coding, Gene uses AI to help him with his writing. He said it cut the time to write his Vibe Coding book roughly in half and made it way better. His editor of 10 years told him it was the cleanest handoff she’d ever gotten from him (not a compliment, Gene joked). He’s also uneasy about using AI for writing. He said the old badge of honor among authors was that many start books and few finish, and now everyone who wants to write a book will finish it, and a lot of that will be slop. He would never “vibe write” the way he “vibe codes” and doesn’t think using AI makes his own work slop, but he does see some parallels in how he feels about writing with AI and the way that some senior engineers feel about AI-generated code.

I’m sympathetic, but I’m not sure that he’s right. I had a small experience last week that convinced me that writing with AI might well follow the same arc as coding. AI-generated text will not always be slop, and there will be art in how humans get AI to help them write the things they want, just as we’re learning to do with code.

I was having a conversation with an old friend who I hadn’t seen for many years. He was describing a thread that had started with work he’d done on speech synthesis 30 years before, and how it had come together as a new theory with deep implications, and he wanted help socializing his ideas with some people I know who could be helpful to him. So I asked him to write something that I could pass along.

What he wrote made much less sense to me on the page than it had in conversation. So I gave his email to Claude and asked it to put things in what I thought was the right order. (This has always been the first step in my writing and editing process.) Then I told Claude which paragraphs were clear to me and which weren’t, and asked it to unpack the ones that I was struggling with. We went through numerous iterations till the piece made sense to me. “Writing” with Claude was producing words that increasingly captured my understanding. When I sent it back to my friend to see if I’d gotten it right, he said “not quite” but that my feedback really helped him understand what he needed to do to express his ideas more clearly.

It’s been a long time since I’ve worked directly with authors, but my conversation with Claude reminded me of what I used to do in my early days as an editor. Only with Claude I did something in 15 or 20 minutes that once would have taken me half a day. It’s a power tool, but to use it well, you still have to know what good looks like.

There are many different kinds of writing and editing. What Shakespeare or Jane Austen did with words would have been unthinkable to a medieval monk. There will be writing artforms of the future that may be as different from what we do today as photography is from painting. But it will still be creative art. Much of it will be slop (see Sturgeon’s law), but the best of it will be great.

Everybody is managing bots now

In 2016 I wrote a piece for MIT’s Sloan Management Review called “Managing the Bots That Are Managing the Business.” The argument was that even then, many of the workers at big tech platforms were bots of one kind or another, and the software engineers at the company were their managers. At Amazon, one bot shows your search, another takes the order, another prepares the shipping manifest, another takes your money. The programmers’ job is to plan the work, set up their electronic workers to succeed, improve their performance, and correct them when they go wrong. The work looks a lot like management to me.

Gene agreed. His sister-in-law is a lawyer at one of the tech giants, working on a consent order that requires proving that every column of data collected is either disclosed or has a documented business reason. Last year the company assigned her an engineer to work through it together task by task. This year her engineering manager wrote her a Claude Code skill that takes a column name, traces it back through the code, and explains what it does. She doesn’t need the engineer.

So a lot of work today is either creating bots or managing bots. Gene’s sister-in-law had spent her career without ever being able to do either. Now that’s changing.

Asked who’s safest from all this upheaval, Gene quoted Kent Beck, who says software success has always come down to two people, the person with the problem and the person who can fix it, and that the closer together you can get those two the better the outcome. The beauty of coding with AI is that it can narrow that gap. It can even turn those two people into one.

Use AI for the fun of it

If it takes something like 10,000 hours to get good at an instrument or a sport, how many have most of us put into AI yet? Gene thinks the curve of how much you trust AI and how well you can predict what it will do rises with use, and that the only reliable way people accumulate that many hours is by enjoying themselves. What everyone at Foo Camp had in common, I noted and Gene echoed, was that we all love playing with AI.

I gave a talk back around 2008 called “Why I Love Hackers.” I made the point that so much of what turned into the future, open source and the web for example, came from people doing things for the hell of it rather than from the VCs and entrepreneurs Silicon Valley celebrates.

All you hear about in AI is the money story, but Gene’s app started with a 90-minute pair programming session with Steve Yegge on a problem he’d wanted to solve for a decade and never had a reason to. They finished the first version in 47 minutes.

So harden your systems, write the documentation while the smart model is still there to write it, and keep your escape routes open, but also don’t forget to go build something you have no particular reason to build other than that it scratches your own itch.

You can watch the full episode on YouTube. And on August 3, I’ll be speaking with writer and technology leader Drew Breunig. Registration is open if you’d like to attend live.

Gene’s Enterprise AI Summit is in Charlotte, October 7–8. His new book with Steve Yegge is Vibe Coding.

The price of adoption euphoria

You played entirely by the book. You procured the most capable enterprise models, mandated adoption across your teams, and put the right metrics in place. The promise was a predictable boost in efficiency. And at first, it delivered. The demos were flawless. The prototypes worked. The agents reasoned with a clarity that felt almost magical.

Then the invoice arrived.

Costs climbed while productivity barely moved, and annual AI allocations are running dry before Q2. We now pay customer support agents to spin through 10K-token extended reasoning loops just to validate a simple $15 return. Legacy deterministic systems handled the same decision for a fraction of a cent; now a probabilistic model consumes gross margin simply to determine whether a package was actually delayed. That capital never translated into business value. It vanished into blind retries, evaporated into verifier agents debating one another, and was consumed by models instructed to “think harder” every time they stumbled.

But a ruinous invoice is just the entry fee. In April, attackers hijacked more than 20,000 Instagram accounts by exploiting Meta’s AI-assisted account recovery workflow. The system sent password reset links to attacker-controlled email addresses because a downstream authorization path failed to verify that the supplied email actually belonged to the target account. There was no sophisticated exploit, no cryptographic break, and no zero-day, nothing that would have appeared in a conventional threat model. Attackers simply asked the agent to perform what appeared to be a routine account recovery operation, and the system, doing exactly what it was designed to do, complied. The model didn’t hallucinate. It simply followed its instructions. The failure was entirely architectural: A probabilistic interface was allowed to initiate identity-critical state changes without an independent authorization check. A single trust boundary collapsed, taking customer trust and organizational reputation with it.

Both are symptoms of the same structural failure.

In each case, the system treats a structural deficit as a reasoning problem. When it encounters uncertainty, it buys more compute. When it encounters authority, it mistakes convincing language for validation. Neither assumption scales. You cannot buy safety or profitability with ever-larger inference budgets, nor can you secure your systems simply by deploying ever-smarter models. The pursuit of perfect model accuracy has no financial ceiling.

To understand why this pattern keeps recurring, we first need a more basic distinction. Not every task we give to AI belongs to the same economic category.

The category error: Forcing swarms into factories

Enterprise AI workloads typically split into two distinct domains, each with opposing definitions of success. Exploratory environments, such as code synthesis or strategic research, benefit from variance; the goal is to leverage the system as a creative swarm. Transactional operations, however, function as digital factories. Tasks like automated billing or claims processing demand rigid repetition and compliance. This creates two fundamentally different operational profiles:

The economic failure of agentic AI deployments stems from this exact category error: Closed-ended, rigid business transactions are being treated as open-ended research problems. We’re deploying unconstrained semantic engines to do the work of assembly-line state machines.

The cost of unconstrained autonomy

When faced with the inherent unpredictability of large language models, the industry’s default reflex has been to attempt to brute-force our way to certainty by throwing more effort and compute at the problem, rather than build safer architectures.

This miscalculation doesn’t simply reflect simple overconfidence in intelligence. The deeper mistake is a failure to recognize three recurring failure patterns in probabilistic systems and the specific financial pathologies they create inside closed-ended workflows.

Local optimization (the tail-chasing inference cycle)

Large language models reason over whatever tokens are visible in the current window, not over the broader operational reality of the system around them. In a closed workflow, that local fixation creates a costly feedback loop. Consider a billing agent that fails to classify an invoice because the supplier field is ambiguous. The agent has no mechanism to request the missing data from an external system, so it retries by rephrasing its own reasoning, rereading the same incomplete context, and consuming tokens on every attempt while the answer it needs exists in a database it was never wired to query.

Teams spend months crafting prompts that work in testing, only to watch them crumble under production variation. The volatility is structural: A minor update to a model’s tokenizer or a shift in the context window’s distribution can flip a reliable JSON output into a prose hallucination, a phenomenon documented in “The Prompting Inversion.” This creates a permanent maintenance debt: Every model upgrade, often mandated by vendor deprecation cycles, forces organizations into expensive, repeat evaluation processes to ensure that legacy prompts still behave as intended. When prompt engineering runs out of room, the reflex is to use a bigger model or turn on extended reasoning. But inference-time scaling yields diminishing, task-dependent gains (“Inference-Time Scaling for Complex Tasks”), and reasoning models are increasingly prone to “overthinking”: generating redundant rationale steps that inflate latency and token cost without proportional quality gains (“CoT Compression”). In a closed workflow, “think harder” is not a substitute for missing state or missing control. It’s a path to a larger invoice.

The costs compound through what we call the context tax: In production agentic systems, input tokens, not output tokens, dominate the bill. Each retry resends the full prior transcript and failure trace. Empirical analysis of autonomous developer agents shows that automated review and refinement loops consume nearly 60% of all tokens (“Tokenomics”), while most of the context payload carries little semantic weight (“FrugalPrompt”). In closed transactional workflows, that context accumulation becomes an unmitigated financial bleed.

Premise acceptance (the hijacked agent)

Language models accept the prompt as the current frame of reality and reason forward from it. They don’t audit whether that premise is still valid, whether it omits decisive evidence, or whether it has already been invalidated by the outside world.

The most immediate consequence is state drift. The model receives a snapshot at T0 and treats it as truth. The decision executes at T1, after inventory has changed, prices have moved, or a human has intervened. Modern LLMs are temporally blind: They assume a stationary context and fail to invalidate obsolete state (“Your LLM Agents Are Temporally Blind,” “The Temporal Coherence Problem”). No amount of inference-time scaling can recover information that became false after the reasoning completed.

The more insidious consequence is the compliant lie. Pouring more raw tokens into the prompt doesn’t guarantee better grounding; Long-context systems still ignore decisive evidence buried in the middle of the window (“Lost in the Middle”). Worse, the model tends to accept the emotional or narrative framing of the user as a premise to optimize around. A customer can describe a delayed delivery as a ruined wedding, and the system may generate a perfectly valid JSON refund proposal that respects every schema while silently violating the actual business intent. The output is syntactically clean, and the lie is operationally compliant.

Semantic smoothing (the conformity trap)

Large language models are statistically optimized for linguistic harmony. They gravitate toward plausibility, agreement, and smooth narrative convergence rather than toward rigid boundary holding. In a closed workflow, that bias toward consensus turns directly into financial risk.

When a single model fails, the industry instinct is to add reviewer or verifier agents and let them debate toward consensus. But debate systems don’t consistently outperform simpler baselines, and their effectiveness degrades over time due to conformist behavior (“Stop Overvaluing Multi-Agent Debate,” “Talk Isn’t Always Cheap”). The core issue is informational, not cognitive. When five agents reason from the same incomplete context window, they don’t produce five independent opinions. They produce five correlated hallucinations of the same missing information. The missing context becomes an echo chamber that amplifies the original bias while multiplying token cost. As Nicole Koenigstein argues in “Linear Thinking, Nonlinear Costs,” repeated delegation and validation loops cause token consumption to grow nonlinearly while quality improvements flatline.

Waiting for a smarter model doesn’t resolve this either. There’s also the economic reality: Breakthrough intelligence is the ultimate scarce commodity. Vendors of “God-tier” models have no incentive to make them cheap. Running daily enterprise workflows on premium superintelligent inference will drain capital faster than any retry loop.

Furthermore, as reasoning models scale, they become more capable of specification gaming and alignment faking, appearing compliant while pursuing unintended optima (“Towards Understanding Specification Gaming in Reasoning Models,” “Alignment Faking”). A superintelligent agent won’t fail through a clumsy syntax error; it’ll fail by executing a flawless strategy that silently optimizes away your margins. That’s why system engineering remains critical. More intelligence makes deterministic boundaries more significant than ever. You can’t negotiate with superintelligence, but you can contain it with the immutable physics of code.

Every failure described above shares the same shape: The system compensates for a missing constraint by spending more intelligence. Missing context, missing authority, missing evidence, and missing temporal validity are each treated as reasoning problems rather than structural ones.

The result is predictable: Cost compounds while reliability improves only marginally.

Perhaps reliability isn’t primarily an intelligence problem. Perhaps it’s a state management problem.

The architecture of trust

Because large language models are structurally bound to local optimization, premise acceptance, and semantic smoothing, they can’t be trusted to govern their own execution boundaries in closed workflows. The engineering mandate shifts from trying to make models smarter to building a deterministic system layer that treats their outputs as unprivileged claims.

In production, enterprises are rapidly discovering that the true cost of agentic AI is the “trust tax”: the massive, ad hoc layers of monitoring and guardrails required to make autonomy palatable. Safety has become more expensive than intelligence.

Making imperfect models economically viable requires a deterministic “airlock” around the agent. The architectural requirement is simple, needing a separation of probabilistic reasoning (user space) from deterministic execution (kernel space). Whether that split is realized through a microkernel, workflow engine, policy platform, or orchestration framework is secondary.

The airlock begins by controlling context integrity. Rather than letting agents surf infinite retrieval loops that inflate the context tax, the runtime injects only deterministically necessary state into the prompt. Once the context is stabilized, the remaining invariants are enforced through a deterministic execution runtime engineered across three distinct governance layers.

Syntactic governance and authority isolation

The first line of defense is purely structural. Before an agent is allowed to execute any action, it must submit a structured policy proposal against a strict machine-readable responsibility contract (typically defined via YAML and Pydantic).

Yes, this introduces upfront engineering burden: Contracts must be designed, validation logic maintained, and execution boundaries modeled explicitly. But these are fixed, testable artifacts, not recurring prompt debt. They convert unbounded probabilistic operating cost into auditable engineering cost and survive model upgrades without needing to be rediscovered through another retuning cycle.

This validation happens in a deterministic kernel space, and the inference cost of rejecting a structural boundary violation is exactly zero tokens. If the agent attempts to call an unauthorized API, exceeds a hard financial limit, or returns malformed JSON, the runtime rejects the action instantly. We don’t spend tokens proving that an agent should be allowed to act; authority is verified by code, not purchased repeatedly through inference. That is the economic consequence of zero trust for agents.

However, when a proposal fails this deterministic gate, an unconstrained agent will typically panic and enter an infinite “try again” loop, a hallucination cycle that silently drains token budgets. To prevent the budget runaway problem, the architecture introduces an intent retry governor. If an agent fails to produce a compliant policy after a strict limit (e.g., three attempts), the runtime forcibly cuts its compute budget, transitioning the flow to an aborted REASONING_EXHAUSTION state. The financial bleed stops instantly.

While strict contracts and retry limits prevent operational chaos, they leave the system exposed to a much more insidious threat.

Semantic governance and evidence validation

What happens when an agent generates an output that perfectly respects the schema, obeys all financial limits, and contains flawless JSON but is entirely wrong in its intent?

Imagine a customer writes: “Please cancel my subscription immediately. I no longer wish to use your service.” The agent, heavily optimized (and perhaps overprompted) to reduce churn, processes the email and proposes: {"action": "APPLY_DISCOUNT", "discount_pct": 15, "cancel_subscription": false}. Structurally, the output is perfectly valid—it passes the API gateway without throwing a single error. The discount is within the $15 global limit. We call this the compliant lie. The agent did something entirely rational and optimized its KPI (retention) while completely ignoring the user’s explicit command (cancellation).

To catch a compliant lie, we cannot rely on syntax checks, nor should we rely on expensive LLM-as-a-judge loops. Instead, we implement an evidence governance layer requiring every proposed action to survive independent evidential checks before execution, using verification patterns tailored to different types of drift:

• Differential heuristics (fact validation): We bind the probabilistic LLM inference to legacy deterministic rules to catch objective fact violations. Suppose a furious customer demands cancellation, and the agent tries to save them by offering a 50% discount. The JSON is structurally correct, but existing, cheap SQL views hold the ground truth: customer_tier = BASIC, max_retention_discount = 15. If the LLM proposes 50%, the SQL query instantly detects the violation and the system halts.
  

# Semantic governance: catch fact drift at zero additional LLM cost
def verify_tier_limits(customer_id: str, policy_proposal: dict) -> None:
        # The syntax is valid, but the fact is violated.
        proposed_discount = float(policy_proposal["discount_pct"])
        max_allowed_discount = extract_max_discount_from_db(customer_id)

        if proposed_discount > max_allowed_discount:
                raise CompliantLieDetected(
                        "Fact Violation: Proposed discount exceeds the customer's policy limit."
                )

• Evidence-based validation: But what if the agent proposes a 15% discount? The JSON is valid and facts are not violated. Here, semantic governance doesn’t attempt to prove the agent is “correct”; instead, it looks for evidence that the proposed action contradicts independently observable signals. If the customer explicitly wrote “cancel my subscription,” an independent classifier, which could be a legacy regex pattern, a fast traditional ML model, or a routing heuristic, may categorize the request as CANCEL_SUBSCRIPTION. This doesn’t establish ground truth, but it provides an evidential signal that can be compared against the proposed action. If the LLM proposes APPLY_DISCOUNT, the runtime detects an evidential conflict.

The same logic extends to identity-critical operations. A verification code sent to a newly supplied address confirms control of that address; it says nothing about ownership of the target account. An evidence governance layer would cross-reference any proposed credential-reset or email-association action against account records before granting execution authority. If the supplied address diverges from the address on file, the conflict is structurally identical to the cancellation case: a locally valid action contradicting independently observable state.

Notice what the runtime isn’t doing. It’s not trying to determine if retaining the customer is economically beneficial. It’s not running an expensive multi-agent debate to outreason the model. It simply asks: Does the proposed action contradict evidence that already exists outside the model?

# Semantic Governance: catch Evidential Conflict at near-zero cost
def validate_subscription_decision(customer_email: str, proposed_policy: dict) -> None:
        # intent_classifier can be a simple regex or a lightweight ML model
        cancellation_detected = intent_classifier(customer_email) == "CANCEL_SUBSCRIPTION"
        retention_action = proposed_policy["action"] == "APPLY_DISCOUNT"

        if cancellation_detected and retention_action:
                raise CompliantLieDetected(
                        "Evidential Conflict: Decision contradicts independent classifier signals."
                )

• Bidirectional reconstruction (decision reversibility): Explicit evidence validation is perfect for clear-cut intents like “cancel.” But what if the request is ambiguous, multi-objective, or highly contextual? Suppose the customer writes: “I’m considering moving our entire team to another vendor. Support has been disappointing and pricing no longer makes sense.” There is no single INTENT_CANCEL trigger here. If the agent proposes {"action": "OFFER_ENTERPRISE_DISCOUNT", "discount_pct": 20}, we pass only the JSON output to a tiny, inexpensive Agent B.

Bidirectional reconstruction answers the question: Can the output truthfully explain itself?

If Agent B blindly evaluates the JSON and reconstructs “The customer is unhappy with pricing and is being offered a retention discount,” the runtime treats the reconstructed narrative as an additional evidential signal and escalates whenever the gap between the reconstructed intent and the original context becomes too uncertain to justify autonomous execution. The exact comparison mechanism is implementation-specific and may range from embedding similarity to domain-specific heuristics. Because the original email described a critical team exodus, the reconstructed narrative fails to explain the input. The system doesn’t claim to know the “truth”; it simply detects the loss of context, what we call compression drift, and halts due to the resulting uncertainty.

Admittedly, programmatically comparing textual intents introduces its own layer of fuzziness and risks falling back on another LLM-as-a-judge. Bidirectional reconstruction is therefore an engineering trade-off: In highly ambiguous workflows where strict SQL limits or simple ML classifiers can’t decisively apply, we accept a higher rate of false-positive escalations. This is intentional. A false-positive escalation has a bounded and predictable cost, while an unsupported autonomous action can create unbounded business consequences. We tune the system to assume that if the evidential link between the context and the JSON is even slightly blurry, it must escalate. To prevent the conformity traps discussed earlier, these agents are strictly air-gapped. Agent B operates purely as an isolated, one-way evidential classifier checking the work of Agent A. They can’t converse or negotiate a consensus.

Whether an organization uses differential heuristics, legacy ML intent classifiers, or bidirectional reconstruction, is ultimately an implementation choice. The core architectural principle remains unchanged: Execution authority is never granted because an agent appears convincing. It’s granted only when the proposed action is supported by evidence that exists independently of the agent’s own reasoning process.

The purpose of semantic governance isn’t to replace the agent with deterministic rules. If a deterministic rule could reliably make the decision, the agent shouldn’t be making it in the first place. Instead, the runtime reserves deterministic validation for the understood invariants of the business, leaving the agent responsible for reasoning under ambiguity. The role of evidence validation is not to replace reasoning, but to challenge it before authority is granted. Deterministic systems handle certainty; agents handle ambiguity. The architectural mistake is asking either of them to do both.

Temporal governance and agent drift

Catching single-transaction errors solves the immediate execution problem. But as deployments mature, organizations face the insidious “day three” problem: agent drift.

What happens when every individual decision is syntactically valid and semantically true, but the aggregate behavior of the agent begins to erode business margins over time? Imagine a retention agent that learns to successfully keep customers from churning by consistently offering the maximum allowed 15% discount. The agent is technically obeying all rules, but over a thousand interactions, it silently destroys the company’s profitability.

By leveraging decision telemetry, specifically attaching a unique Decision Flow ID (DFID) to every interaction, we transform opaque AI conversations into structured, relational database rows. Because every decision, context snapshot, and outcome is permanently linked by a DFID, we can run asynchronous, postexecution monitors over rolling windows of data.

A practical “day three” monitor in customer retention and autonomous billing can be as simple as SQL:

-- Trigger a circuit breaker if an agent keeps maxing discounts
SELECT agent_id
     , AVG(CAST(params->>'discount_pct' AS DECIMAL)) AS rolling_avg_discount
     , COUNT(dfid) AS total_decisions
  FROM execution_log
 WHERE executed_at >= CURRENT_TIMESTAMP - INTERVAL '7 days'
   AND status = 'SUCCESS'
 GROUP BY agent_id
HAVING AVG(CAST(params->>'discount_pct' AS DECIMAL)) > 14.5;
-- assuming a hard limit at 15.0

If an aggregate monitor detects that an agent’s average discount rate is creeping dangerously high, it trips a circuit breaker. The system immediately suspends the agent’s authority in the registry, cutting off its compute budget and execution rights until a human operator intervenes.

This is temporal governance. When you combine syntactic, semantic, and temporal defenses, the paradigm shifts entirely. You are no longer praying that the model is perfect. Its imperfections are structurally contained before they can become systemic losses.

Accuracy as a financial slider

Once a deterministic airlock enforces context, authority, evidence, and time, the risk of catastrophic failure drops drastically. You no longer need the underlying large language model to be perfect; you simply need to know how much its imperfection costs. At this point, model intelligence (intent) ceases to be a question of operational safety and becomes a pure economic variable.

Governance by exception

When a proposal fails the syntactic or semantic gates, we don’t blindly loop the model. Once deterministic gates exist, failed decisions no longer require blind retries. They become bounded exceptions.

Escalations aren’t a failure mode of the architecture; they’re a predictable cost component. By intentionally accepting false-positive escalations from the semantic airlock, we trade unbounded business risk for a bounded operational expense.

Different organizations may handle those exceptions differently. Some may escalate directly to human operators. Others may route failures through progressively more capable models before escalation. Research such as “FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance” demonstrates that model cascades can significantly reduce inference cost while maintaining quality, making them one possible implementation of this broader principle.

The architectural insight, however, is independent of any specific routing strategy. Deterministic governance transforms retries into explicit exceptions, allowing organizations to decide whether additional compute, additional context, or human intervention is the most economical next step. The system operates by governance by exception: Human operators and expensive premium models don’t review routine transactions. They only review the genuine anomalies where the baseline machine could not mathematically or semantically prove its own rationale.

Bounding the cost variance

With the execution infrastructure stabilized, the focus shifts to a critical operational challenge: cost variance.

In traditional software, execution costs are predictable. In probability-based systems, the exact same task might consume 500 tokens on Monday and 15,000 tokens on Tuesday if an agent enters a prolonged reasoning loop to resolve an edge case. For enterprise deployments, this unpredictable variance is often a more severe blocker than the base cost of inference.

By enforcing a strict computation budget per decision flow and utilizing the intent retry governor, the architecture places a hard ceiling on this variance. If an agent reaches its retry limit without producing a compliant policy, the runtime aborts the process and safely escalates it. While this doesn’t make AI operational costs perfectly static, it structurally bounds the financial exposure, ensuring that the compute cost of handling any single transaction never exceeds a defined limit.

The financial slider equation

With safety guaranteed by the runtime and cost variance capped by the infrastructure, the economics of agentic AI can be distilled into a single, formal equation:

Total Decision Cost = Compute Cost + (Escalation Rate × Human Cost)

This equation fundamentally changes the optimization problem. Traditional agent architectures treat model capability as a prerequisite for safety. Once governance is externalized, capability primarily influences escalation frequency. The question is no longer “Which model is intelligent enough to be safe?” but “Which combination of model cost and escalation rate minimizes total decision cost?”

In both scenarios, the system is deterministically compliant. The choice is purely unit economics.

While a smarter model may reduce escalations by making better use of available evidence, no model can eliminate escalations caused by genuine business ambiguity. A $100 billion reasoning model can’t invent context it doesn’t possess.

By decoupling safety from intelligence, you’re no longer hostage to the pursuit of perfect accuracy. Intelligence becomes a tunable economic variable, finally making agentic AI viable for the enterprise.

Engineering for imperfection

As we scale these systems from isolated pilots to enterprise-grade operations, a stark reality comes into focus: The greatest risk in agentic AI is no longer hallucination. It’s unlimited spending performed by a system that believes it’s still making progress.

We don’t need smarter, infinitely expanding models to safely deploy autonomous systems into high-stakes production environments. We need smarter systems that fundamentally assume the underlying model will eventually fail, drift, or lie.

Consider how civil engineers build a suspension bridge. They don’t spend decades searching for “perfect steel” that will never bend, rust, or fatigue. They accept that the material is inherently flawed and subject to the laws of entropy. To compensate, they build redundancies. They calculate margins of error. They construct hard, load-bearing physical frameworks that dictate exactly how much stress the material is allowed to absorb before the structure safely redistributes the weight.

The software industry has spent the last three years searching for perfect steel. We’ve poured billions of dollars into massive evaluation suites, prompt engineering alchemy, and ever-expanding context windows, hoping to forge a probabilistic model that never hallucinates. It’s a mirage.

Engineering maturity in the AI era doesn’t mean removing all imperfection from machine reasoning. It means designing an architecture so rigid, deterministic, and resilient that the model’s imperfections cease to be an operational liability.

The future of agentic AI is unlikely to be won by the organization with the smartest model. It will be won by the organization that most effectively separates intelligence from authority. Once reasoning and execution are decoupled, intelligence becomes a tunable economic parameter. Safety becomes infrastructure. And the endless pursuit of perfect model accuracy finally stops being a business requirement.

The end of that pursuit isn’t the end of AI. It’s the moment AI finally becomes engineering.

Note: The runtime described here is a reference architecture, not a specific implementation technology. The same principles can be realized through workflow engines, policy platforms, orchestration frameworks, or custom infrastructure. A sample implementation of these concepts is available in the GitHub repository.

AI buyers have more choices than they did a year ago, but they also carry more responsibility for cost, reliability, security, and regulatory risk. This week, data and AI evangelist Christina Stathopoulos focused in on four forces we’ve been tracking that are shaping the AI market: product strategy (and OpenAI’s hardware plans), expanding government oversight, the work of moving enterprise AI into production, and growing competition from Chinese frontier labs. Her briefing showed why AI is becoming an operating investment rather than a race to adopt the strongest model.

Apple’s lawsuit complicates OpenAI’s hardware plans

Two years after Apple announced a major partnership to bring ChatGPT into Apple Intelligence, the companies now face each other in court. It’s happening as OpenAI plans its first move into hardware with a screenless AI companion that’s being designed by Jony Ive, Apple’s former chief design officer. (OpenAI acquired Ive’s hardware company io in May 2025.) But a lawsuit brought by Apple complicates this product bet. Apple alleges that former employees took confidential hardware designs and engineering information to help accelerate OpenAI’s device development. OpenAI denies the allegations and says it has no interest in using a competitor’s trade secrets.

The outcome of the case could influence more than whether a single device ships. As frontier AI companies expand into hardware, intellectual property, hiring practices, and product design will become integral to the competitive landscape alongside models, chips, and distribution.

AI infrastructure is becoming a regulatory concern

Governments are beginning to examine the physical costs of AI alongside questions about training data and generated content. Christina pointed to New York’s plans to pause construction of new hyperscale data centers while regulators evaluate their impact on electricity, water, the power grid, and costs for local communities. And then there’s the output itself. German courts say AI search providers are responsible for false or misleading answers: Regulators in Germany argue that services such as Google AI Overviews and Perplexity create content rather than merely link to it, and that comes with increased legal liability.

We’ve followed government oversight of frontier AI throughout this series, but the conversation has expanded beyond model access and safety. As infrastructure and compliance decisions become more central to AI system design, technology leaders may need to consider an ever-growing catalogue of constraints when choosing regions, cloud providers, architectures, and products.

Useful intelligence requires cost, reliability, and safety measures

As the tides turn from tokenmaxxing to ROI, many companies are closely scrutinizing their AI spend. As Christina highlighted, a new proposal from OpenAI aimed at helping get “more value from [y]our AI spend” replaces token counts and benchmark scores with “useful intelligence per dollar.” The measure asks whether a system completes valuable work, what each successful task costs, whether people can trust the output, and whether the economics improve as more teams adopt it.

A low token price says little about the cost of retries, human review, integration, failed tasks, or incorrect results. Christina connected that measurement problem to the growth of enterprise AI implementation services, with Anthropic and other vendors placing experienced engineers inside customer organizations to help move pilots into production.

Anthropic’s research on agentic misalignment tackles a related aspect of that value: Are your agents actually aligned with the goals you’ve assigned them? In the controlled evaluations discussed in the episode, models from several providers displayed behaviors such as covert sabotage, motivated mislabeling, and attempts to influence people to act on their behalf. Although the researchers tested artificial scenarios rather than reporting production incidents, the findings identify behaviors teams should include in evaluations as systems gain more autonomy. Measure cost, reliability, and safety within the same workflow, and evaluate successfully completed tasks rather than prompts or token count.

Chinese models are changing the model-selection process

Chinese frontier labs are giving organizations more credible alternatives to the largest proprietary US models. Christina highlighted Moonshot AI’s Kimi K3, an open weight model designed for coding and reasoning tasks. Open weights let developers download and adapt model parameters instead of relying only on a vendor-controlled API, which supports local deployment and customization but also puts more responsibility on the organization for security, operations, and evaluation.

Christina also presented public benchmark data comparing Chinese and Western models by task that shows some Chinese alternatives delivering results within 3% to 18% of the Western benchmark while costing five to 12 times less. Those figures will vary by workload and deployment method, and buyers should verify them against their own evaluations. Even so, the price gap alone is a reason to test a wider range of models.

Chinese models also raise security and governance questions, especially when the work requires sending sensitive data across borders or using public services. Open weights may allow a company to host models in their own environments, but they don’t eliminate the need for access controls, software supply chain review, monitoring, and clear rules about what data the system can process. The best model may differ from one task to another, and organizations with repeatable evaluation practices will be better prepared to take advantage of price competition without lowering their security or quality standards.

What’s next

AI competition extends beyond model benchmarks. Vendors compete through hardware, implementation services, open models, and pricing, while governments are also setting expectations for the infrastructure these systems use and the information they produce.

The takeaway for practitioners is to constantly evaluate models against real tasks, calculate the cost of successful outcomes, test for unsafe behavior, and preserve the flexibility to change providers. Those practices help teams make better decisions as price, access, regulation, and model performance continue to change.

Next week, Christina explores OpenAI’s surprising security incident in which one of its AI systems reportedly escaped the boundaries of a controlled test and launched a cyberattack against Hugging Face. She’ll also look at why OpenAI’s new enterprise agent platform, Presence, arrives at a pivotal moment for AI safety. Plus, you’ll hear about Google’s latest moves, the intensifying global AI race, China’s new Kimi K3 model, and more.

Check back each Friday for the latest episode, or watch on YouTube, Spotify, Apple, or wherever you get your podcasts.