In 1964, science fiction writer Arthur C. Clarke predicted that computers would overtake human evolution.“Present-day electronic brains are complete morons, but this will not be true in another generation,” he told the BBC. “They will start to think, and eventually, they will completely out-think their makers.” 

Daniel Roher opens his new documentary The AI Doc: Or How I Became An Apocaloptimist (2026) with this cheerful prophecy. And in the hundred-some minutes that follow, he tries to make sense of a technology that, by his own admission, he does not understand — and a world that is rapidly being changed by it. Explaining that he conceives of AI as a “magic box floating in space,” he enlists the help of experts to provide him with a crash course in what, exactly, AI is. 

Roher’s real concern, however, isn’t so much about the workings of AI — though some of his subjects do attempt to explain them for him — but whether it might displace us, as Clarke’s prediction suggests it will. 

While making the film, Roher learns that his wife Caroline is pregnant with their first child. He tracks his wife’s pregnancy and the birth of his son in parallel with the advent of AI. It’s a smart choice that builds on a fear all parents share: What sort of world are we making for our children? And behind that question is another, vibrating in anxious silence: What happens after our offspring replace us? This twinned existential angst drives his efforts to hear from the doomers, the techno-optimists, and the in-between “apocaloptimists” whose ranks he ultimately joins. 

The AI Doc, as its sweeping title suggests, wants to shape and lead the narrative around AI. It’s certainly set up to do that — Roher is fresh off an Oscar win for his documentary Navalny, and the film opened in nearly 800 theaters, which counts as wide-release for a nonfiction title. The final product is indicative of the ways that public attitudes around AI are in massive flux. Roher hopes to reach people of my grandmother’s generation who conflate AI with smartphones and spellcheck, as well as people who don’t seem to care whether a video was AI-generated. 

But I think that this documentary has come too late to steer the conversation, something the film itself acknowledges. For all its transformative potential, AI isn’t actually unique among emerging technologies yet — it has not been cataclysmic or ushered in a golden age of prosperity  — but Roher and many of those he interviews tend to treat it as a radical break with all that has come before. As a result, they tend to fixate on the binary extremes of doom or salvation. It’s an approach that reinforces our own helplessness in the face of AI-driven change, while also muddying our understanding of what we might yet be able to do as we seek to adapt, mitigate harm, and shape the world that AI could otherwise truly start remaking.

For good and for ill

Roher, contemplating his child’s future, opts to hear the bad news first. Tristan Harris, the cofounder of the Center for Humane Technology, doesn’t mince words: “I know people who work on AI risk who don’t expect their children to make it to high school.”

Many of the film’s other interviewees are similarly gloomy. Geoffrey Hinton, the “godfather of AI,” for example, argues that as AI becomes smarter, it will become better at manipulating humanity. But no one is more pessimistic than Eliezer Yudkowsky, the well-known AI doomer and co-author of the controversial book If Anyone Builds It, Everyone Dies. As the title suggests, Yudkowsky believes that superintelligent AI would wipe out humanity — a position that he stands by and lays out for Roher. 

Turning his back on these storm clouds — and taking the advice of his wife, Caroline, who tells him that he needs to find hope for the future — Roher tunes into the chorus of AI optimists. They tell him, variously, that there are more potential benefits than downsides to AI; that technology has made the world better in every way; that this will be the tool that helps us solve all our greatest problems. Not to mention: AI will bring the best health care on the planet to the poorest people on Earth, extend our healthspan by decades, and enable us to live in a postscarcity utopia free of drudgery. Oh, and: We will become an interplanetary species, all thanks to AI. 

These promises initially reassure Roher, perhaps because he seems easily led by whomever he’s spoken to most recently. It is Harris who ultimately convinces him that we can’t separate the promise of AI from the peril it presents. The conclusions that result will be obvious to anyone who’s thought about these issues for more than a moment or two: If AI automates work, for example, how will people make a living? 

It doesn’t help that many of the most invested players reflect on these questions superficially, if at all. OpenAI CEO Sam Altman tells Roher that he’s worried about how authoritarian governments will use AI — a claim that is followed in the film by a cut to images of Altman posing with authoritarian leaders. Other tech CEOs fall back on PR pleasantries in response to the filmmaker’s questions, and Roher too often goes easy on them, never diving deeper when they admit that even they aren’t confident that everything will go well. That these are the leaders of AI companies racing against each other to make the technology more and more advanced does little to inspire confidence.

(Some of the techno-pessimistic people interviewed for the documentary have expressed their strong displeasure with the final result.)

“Why can’t we just stop?” Roher asks these tech CEOs. He’s told that a moratorium is a pipe dream: Many groups around the world are building advanced AI, all with different motivations. Legislation lags far behind the rate of technological progress. Even if we could pass laws in the US and EU that would stop or slow things down, says Anthropic CEO Dario Amodei, we’d have to convince the Chinese government to follow suit. 

If we don’t create it, the thinking goes, our enemies will. It’s best to get ahead of them.

This is, of course, the logic of nuclear deterrence: If we don’t mitigate the risk of ending the world through mutually assured destruction, there’s nothing stopping someone else from pressing the button first. 

An apocalypse in every generation

The atomic comparison is apt, if only because Roher sees the stakes in similarly stark terms. “Will my son live in a utopia, or will we go extinct in 10 years?” he wonders aloud. It’s a question that’s central to the film. But he never really sits with the more likely scenario that AI will neither lead to human extinction nor end all disease and drudgery. Every generation faces the specter of its own annihilation — and yet the ends of days keep accumulating, no matter how close the doomsday clock gets to apocalypse.

The point, then, isn’t that AI won’t be bad for us, but that by framing the question in strictly utopian or dystopian terms, we miss the messy reality that lies between hell on earth and heaven in the stars. Although The AI Doc tries to chart an “apocaloptimist” course between two extremes, it doesn’t grasp the real stakes. AI doesn’t really create new risks as such — it’s a force multiplier for existing ones like the threat of nuclear warfare and the development and use of biological weapons. The chief existential risks of AI are human-made and human-driven. And that means, as Caroline says in the film’s ending narration, “We get to decide how this goes.” She’s right, but her husband never seems to understand how she’s right. 

Like too many Big Issue Documentaries, Roher’s film is heavy on problems and light on solutions. It does offer some, calling for international cooperation, transparency, legal liabilities for companies if something goes wrong, testing before release, and adaptive rules to match the speed of progress. But just as this is a strictly introductory course in AI — one that will probably irritate those who’ve already moved on to AI 102 — these recommendations are only a starting point. For Roher, they offer reason to be hopeful. For the rest of us, they’re just the beginning of an opportunity to meaningfully steer the course of our future.

OpenAI wants to raise taxes on the rich, expand the welfare state, let workers decide how their employers use artificial intelligence, and give everyone a cut of the tech industry’s profits.

Or so the company claims in a new vision statement.

In that document, the AI titan argues that the government needs to enact sweeping economic reforms, so as to “share prosperity broadly” in “the age of intelligence.”

The plan received far more attention than your typical policy white paper, due largely to its improbable author. Tech companies do not typically issue sweeping proposals for restructuring the American economy. 

This said, OpenAI’s vision statement is not entirely unprecedented. AI moguls have long warned that their technology could cause mass unemployment, while gesturing toward the need for income redistribution. 

Still, even by those standards of Silicon Valley thought leadership, the agenda OpenAI outlines is remarkably progressive. In fact, it overlaps heavily with Sen. Bernie Sanders’s own AI proposals (minus his moratorium on data center construction). Since advanced AI could shift income away from workers and toward business owners, OpenAI proposes the creation of a “public wealth fund.” Essentially, the government would purchase a stake in the nation’s most profitable companies and then give shares to every US citizen. In other words, it would give Americans a little socialism, as a treat.

OpenAI also calls for, among other things: higher capital gains taxes; more public funding for jobs in health care, education, and community service; giving workers more influence over corporate governance; and holding AI companies accountable to new safety regulations.

All of these policies are hazily sketched. The document is 13 pages and dedicates only a short paragraph to most of its proposals. It reads a lot like something that ChatGPT would spit out, if you asked it to research ideas for combating AI-induced inequality for 10 minutes.

For OpenAI’s progressive critics, however, its agenda is less irksome for its laziness than its hypocrisy: The political behavior of its top leaders belies the firm’s purported commitment to egalitarian reform.

In truth, OpenAI is engaging in one of Silicon Valley’s most annoying traditions: advertising its support for radical new social policies that have no actual chance of becoming law in the near-term, while ignoring — if not abetting — attacks on actual welfare programs in the here and now.

OpenAI supports social democracy in theory — and Republicans in practice

For years now, tech billionaires have been worrying aloud about how artificial intelligence could swell inequality and unemployment. And many have argued that the government must create a universal basic income (UBI) — a guaranteed minimum salary for every American — to account for this risk. Elon Musk and Mark Zuckerberg were all making versions of that argument as far back as 2017.

Of course, there was no actual prospect of Congress creating a UBI that year. By contrast, congressional Republicans did try to gut the Affordable Care Act in 2017.

It is hard to see how one could believe that 1) everyone should collect an income, regardless of their employment status and 2) people shouldn’t necessarily receive health insurance if they don’t have a job.

If tech-induced inequality justifies universal cash benefits, presumably it also demands universal health care. Yet Musk, Zuckerberg, and many of the Valley’s other UBI proponents made little effort to thwart the GOP’s attempted repeal of Obamacare. Nor did they mobilize to prevent the expiration of Joe Biden’s enhanced Child Tax Credit, a policy that effectively guaranteed a minimum income for all parents with young children.  

In 2026, the disconnect between OpenAI’s advocacy for legislatively irrelevant reforms — and its approach to live political debates — is even larger. While the company floats collective ownership of the AI industry in PDFs, its leaders are bankrolling the welfare state’s opponents.

OpenAI itself is staying out of political races. In September, though, OpenAI president Greg Brockman and his wife gave $25 million to a pro-Trump super PAC. Along with OpenAI investor Marc Andreessen, Brockman has also poured funds into Leading Our Future, a PAC dedicated to electing opponents of state-level AI regulations. As part of that effort, the group is supporting a wide array of Republican candidates.

OpenAI CEO Sam Altman, meanwhile, maxed out donations to several Republican lawmakers in 2024, while throwing $1 million toward Donald Trump’s inauguration fund.

If this cash bought Altman and Brockman any influence with the White House, there’s no sign they used it to oppose Trump’s push for new work requirements on food stamps and Medicaid last year.

And yet, those policies are totally antithetical to the economic philosophy that OpenAI is now broadcasting. Surely, if the threat of mass, AI-induced unemployment demands the creation of a public wealth fund, it must also forbid choking off basic medical care to millions of people who can’t find work. 

Nevertheless, OpenAI’s leaders did not feel compelled to publicly oppose Trump’s legislation. And Brockman’s super PAC appears to put zero weight on its candidates’ social welfare policies. Whether it is intervening Republican primaries or Democratic ones, the group’s sole concern seems to be blocking state-level AI safety regulations — including several that OpenAI ostensibly endorses in its vision statement.

Bleeding-heart billionaires should get back to the basics

Of course, there are worse things than hypocrisy. I’d rather see AI companies virtue signal about wealth redistribution than, say, build chatbots who rant about “white genocide.”

Further, I suspect that the actual authors of OpenAI’s “industrial policy” document are sincere. The company’s leadership and employees don’t have the same politics (the latter donated overwhelmingly to Democrats in 2024). 

Nevertheless, the people in charge of OpenAI have made their political priorities clear — and sharing “prosperity broadly” is not among them.  

Wealthy techies who are genuinely concerned with that objective, however, should probably spend a bit less energy on cooking up half-baked UBI proposals — and a bit more on intervening in actual legislative fights over social welfare policy.

The following article originally appeared on Addy Osmani’s blog site and is being reposted here with the author’s permission.

Comprehension debt is the hidden cost to human intelligence and memory resulting from excessive reliance on AI and automation. For engineers, it applies most to agentic engineering.

There’s a cost that doesn’t show up in your velocity metrics when teams go deep on AI coding tools. Especially when its tedious to review all the code the AI generates. This cost accumulates steadily, and eventually it has to be paid—with interest. It’s called comprehension debt or cognitive debt.

Comprehension debt is the growing gap between how much code exists in your system and how much of it any human being genuinely understands.

Unlike technical debt, which announces itself through mounting friction—slow builds, tangled dependencies, the creeping dread every time you touch that one module—comprehension debt breeds false confidence. The codebase looks clean. The tests are green. The reckoning arrives quietly, usually at the worst possible moment.

Margaret-Anne Storey describes a student team that hit this wall in week seven: They could no longer make simple changes without breaking something unexpected. The real problem wasn’t messy code. It was that no one on the team could explain why design decisions had been made or how different parts of the system were supposed to work together. The theory of the system had evaporated.

That’s comprehension debt compounding in real time.

I’ve read Hacker News threads that captured engineers genuinely wrestling with the structural version of this problem—not the familiar optimism versus skepticism binary, but a field trying to figure out what rigor actually looks like when the bottleneck has moved.

A recent Anthropic study titled “How AI Impacts Skill Formation” highlighted the potential downsides of over-reliance on AI coding assistants. In a randomized controlled trial with 52 software engineers learning a new library, participants who used AI assistance completed the task in roughly the same time as the control group but scored 17% lower on a follow-up comprehension quiz (50% versus 67%). The largest declines occurred in debugging, with smaller but still significant drops in conceptual understanding and code reading. The researchers emphasize that passive delegation (“just make it work”) impairs skill development far more than active, question-driven use of AI. The full paper is available at arXiv.org.

There is a speed asymmetry problem here

AI generates code far faster than humans can evaluate it. That sounds obvious, but the implications are easy to underestimate.

When a developer on your team writes code, the human review process has always been a bottleneck—but a productive and educational one. Reading their PR forces comprehension. It surfaces hidden assumptions, catches design decisions that conflict with how the system was architected six months ago, and distributes knowledge about what the codebase actually does across the people responsible for maintaining it.

AI-generated code breaks that feedback loop. The volume is too high. The output is syntactically clean, often well-formatted, superficially correct—precisely the signals that historically triggered merge confidence. But surface correctness is not systemic correctness. The codebase looks healthy while comprehension quietly hollows out underneath it.

I read one engineer say that the bottleneck has always been a competent developer understanding the project. AI doesn’t change that constraint. It creates the illusion you’ve escaped it.

And the inversion is sharper than it looks. When code was expensive to produce, senior engineers could review faster than junior engineers could write. AI flips this: A junior engineer can now generate code faster than a senior engineer can critically audit it. The rate-limiting factor that kept review meaningful has been removed. What used to be a quality gate is now a throughput problem.

I love tests, but they aren’t a complete answer

The instinct to lean harder on deterministic verification—unit tests, integration tests, static analysis, linters, formatters—is understandable. I do this a lot in projects heavily leaning on AI coding agents. Automate your way out of the review bottleneck. Let machines check machines.

This helps. It has a hard ceiling.

A test suite capable of covering all observable behavior would, in many cases, be more complex than the code it validates. Complexity you can’t reason about doesn’t provide safety though. And beneath that is a more fundamental problem: You can’t write a test for behavior you haven’t thought to specify.

Nobody writes a test asserting that dragged items shouldn’t turn completely transparent. Of course they didn’t. That possibility never occurred to them. That’s exactly the class of failure that slips through, not because the test suite was poorly written, but because no one thought to look there.

There’s also a specific failure mode worth naming. When an AI changes implementation behavior and updates hundreds of test cases to match the new behavior, the question shifts from “is this code correct?” to “were all those test changes necessary, and do I have enough coverage to catch what I’m not thinking about?” Tests cannot answer that question. Only comprehension can.

The data is starting to back this up. Research suggests that developers using AI for code generation delegation score below 40% on comprehension tests, while developers using AI for conceptual inquiry—asking questions, exploring tradeoffs—score above 65%. The tool doesn’t destroy understanding. How you use it does.

Tests are necessary. They are not sufficient.

Lean on specs, but they’re also not the full story.

A common proposed solution: Write a detailed natural language spec first. Include it in the PR. Review the spec, not the code. Trust that the AI faithfully translated intent into implementation.

This is appealing in the same way Waterfall methodology was once appealing. Rigorously define the problem first, then execute. Clean separation of concerns.

The problem is that translating a spec to working code involves an enormous number of implicit decisions—edge cases, data structures, error handling, performance tradeoffs, interaction patterns—that no spec ever fully captures. Two engineers implementing the same spec will produce systems with many observable behavioral differences. Neither implementation is wrong. They’re just different. And many of those differences will eventually matter to users in ways nobody anticipated.

There’s another possibility with detailed specs worth calling out: A spec detailed enough to fully describe a program is more or less the program, just written in a non-executable language. The organizational cost of writing specs thorough enough to substitute for review may well exceed the productivity gains from using AI to execute them. And you still haven’t reviewed what was actually produced.

The deeper issue is that there is often no correct spec. Requirements emerge through building. Edge cases reveal themselves through use. The assumption that you can fully specify a non-trivial system before building it has been tested repeatedly and found wanting. AI doesn’t change this. It just adds a new layer of implicit decisions made without human deliberation.

Learn from history

Decades of managing software quality across distributed teams with varying context and communication bandwidth has produced real, tested practices. Those don’t evaporate because the team member is now a model.

What changes with AI is cost (dramatically lower), speed (dramatically higher), and interpersonal management overhead (essentially zero). What doesn’t change is the need for someone with a deep system context to maintain a coherent understanding of what the codebase is actually doing and why.

This is the uncomfortable redistribution that comprehension debt forces.

As AI volume goes up, the engineer who truly understands the system becomes more valuable, not less. The ability to look at a diff and immediately know which behaviors are load-bearing. To remember why that architectural decision got made under pressure eight months ago.

To tell the difference between a refactor that’s safe and one that’s quietly shifting something users depend on. That skill becomes the scarce resource the whole system depends on.

There’s a bit of a measurement gap here too

The reason comprehension debt is so dangerous is that nothing in your current measurement system captures it.

Velocity metrics look immaculate. DORA metrics hold steady. PR counts are up. Code coverage is green.

Performance calibration committees see velocity improvements. They cannot see comprehension deficits because no artifact of how organizations measure output captures that dimension. The incentive structure optimizes correctly for what it measures. What it measures no longer captures what matters.

This is what makes comprehension debt more insidious than technical debt. Technical debt is usually a conscious tradeoff—you chose the shortcut, you know roughly where it lives, you can schedule the paydown. Comprehension debt accumulates invisibly, often without anyone making a deliberate decision to let it. It’s the aggregate of hundreds of reviews where the code looked fine and the tests were passing and there was another PR in the queue.

The organizational assumption that reviewed code is understood code no longer holds. Engineers approved code they didn’t fully understand, which now carries implicit endorsement. The liability has been distributed without anyone noticing.

The regulation horizon is closer than it looks

Every industry that moved too fast eventually attracted regulation. Tech has been unusually insulated from that dynamic, partly because software failures are often recoverable, and partly because the industry has moved faster than regulators could follow.

That window is closing. When AI-generated code is running in healthcare systems, financial infrastructure, and government services, “the AI wrote it and we didn’t fully review it” will not hold up in a post-incident report when lives or significant assets are at stake.

Teams building comprehension discipline now—treating genuine understanding, not just passing tests, as non-negotiable—will be better positioned when that reckoning arrives than teams that optimized purely for merge velocity.

What comprehension debt actually demands

The right question for now isn’t “how do we generate more code?” It’s “how do we actually understand more of what we’re shipping?” so we can make sure our users get a consistently high quality experience.

That reframe has practical consequences. It means being ruthlessly explicit about what a change is supposed to do before it’s written. It means treating verification not as an afterthought but as a structural constraint. It means maintaining the system-level mental model that lets you catch AI mistakes at architectural scale rather than line-by-line. And it means being honest about the difference between “the tests passed” and “I understand what this does and why.”

Making code cheap to generate doesn’t make understanding cheap to skip. The comprehension work is the job.

AI handles the translation, but someone still has to understand what was produced, why it was produced that way, and whether those implicit decisions were the right ones—or you’re just deferring a bill that will eventually come due in full.

You will pay for comprehension sooner or later. The debt accrues interest rapidly.

Luca Mezzalira, author of Building Micro-Frontends, originally shared the following article on LinkedIn. It’s being republished here with his permission.

Every few years, something arrives that promises to change how we build software. And every few years, the industry splits predictably: One half declares the old rules dead; the other half folds its arms and waits for the hype to pass. Both camps are usually wrong, and both camps are usually loud. What’s rarer, and more useful, is someone standing in the middle of that noise and asking the structural questions: Not “What can this do?” but “What does it mean for how we design systems?”

That’s what Neal Ford and Sam Newman did in their recent fireside chat on agentic AI and software architecture during O’Reilly’s Software Architecture Superstream. It’s a conversation worth pulling apart carefully, because some of what they surface is more uncomfortable than it first appears.

The Dreyfus trap

Neal opens with the Dreyfus Model of Knowledge Acquisition, originally developed for the nursing profession but applicable to any domain. The model maps learning across five stages:

• Novice
• Advanced beginner
• Competent
• Proficient
• Expert

His claim is that current agentic AI is stuck somewhere between novice and advanced beginner: It can follow recipes, it can even apply recipes from adjacent domains when it gets stuck, but it doesn’t understand why any of those recipes work. This isn’t a minor limitation. It’s structural.

The canonical example Neal gives is beautiful in its simplicity: An agent tasked with making all tests pass encounters a failing unit test. One perfectly valid way to make a failing test pass is to replace its assertion with assert True. That’s not a hack in the agent’s mind. It’s a solution. There’s no ethical framework, no professional judgment, no instinct that says this isn’t what we meant. Sam extends this immediately with something he’d literally seen shared on LinkedIn that week: an agent that had modified the build file to silently ignore failed steps rather than fix them. The build passed. The problem remained. Congratulations all-round.

What’s interesting here is that neither Ford nor Newman are being dismissive of AI capability. The point is more subtle: The creativity that makes these agents genuinely useful, their ability to search solution space in ways humans wouldn’t think to, is inseparable from the same property that makes them dangerous. You can’t fully lobotomize the improvization without destroying the value. This is a design constraint, not a bug to be patched.

And when you zoom out, this is part of a broader signal. When experienced practitioners who’ve spent decades in this industry independently converge on calls for restraint and rigor rather than acceleration, that convergence is worth paying attention to. It’s not pessimism. It’s pattern recognition from people who’ve lived through enough cycles to know what the warning signs look like.

Behavior versus capabilities

One of the most important things Neal says, and I think it gets lost in the overall density of the conversation, is the distinction between behavioral verification and capability verification.

Behavioral verification is what most teams default to: unit tests, functional tests, integration tests. Does the code do what it’s supposed to do according to the spec? This is the natural fit for agentic tooling, because agents are actually getting pretty good at implementing behavior against specs. Give an agent a well-defined interface contract and a clear set of acceptance criteria, and it will produce something that broadly satisfies them. This is real progress.

Capability verification is harder. Much harder. Does the system exhibit the operational qualities it needs to exhibit at scale? Is it properly decoupled? Is the security model sound? What happens at 20,000 requests per second? Does it fail gracefully or catastrophically? These are things that most human developers struggle with too, and agents have been trained on human-generated code, which means they’ve inherited our failure modes as well as our successes.

This brings me to something Birgitta Boeckeler raised at QCon London that I haven’t been able to stop thinking about. The example everyone cites when making the case for AI’s coding capability is that Anthropic built a C compiler from scratch using agents. Impressive. But here’s the thing: C compiler documentation is extraordinarily well-specified and battle-tested over decades, and the test coverage for compiler behavior is some of the most rigorous in the entire software industry. That’s as close to a solved, well-bounded problem as you can get.

Enterprise software is almost never like that. Enterprise software is ambiguous requirements, undocumented assumptions, tacit knowledge living in the heads of people who left three years ago, and test coverage that exists more as aspiration than reality. The gap between “can build a C compiler” and “can reliably modernize a legacy ERP” is not a gap of raw capability. It’s a gap of specification quality and domain legibility. That distinction matters enormously for how we think about where agentic tooling can safely operate.

The current orthodoxy in agentic development is to throw more context at the problem: elaborate context files, architecture decision records, guidelines, rules about what not to do. Ford and Newman are appropriately skeptical. Sam makes the point that there’s now empirical evidence suggesting that as context file size increases, you see degradation in output quality, not improvement. You’re not guiding the agent toward better judgment. You’re just accumulating scar tissue from previous disasters. This isn’t unique to agentic workflows either. Anyone who has worked seriously with code assistants knows that summarization quality degrades as context grows, and that this degradation is only partially controllable. That has a direct impact on decisions made over time; now close your eyes for a moment and imagine doing it across an enterprise software, with many teams across different time zones. Don’t get me wrong, the tools help, but the help is bounded, and that boundary is often closer than we’d like to admit.

The more honest framing, which Neal alludes to, is that we need deterministic guardrails around nondeterministic agents. Not more prompting. Architectural fitness functions, an idea Ford and Rebecca Parsons have been promoting since 2017, feel like they’re finally about to have their moment, precisely because the cost of not having them is now immediately visible.

What should an agent own then?

This is where the conversation gets most interesting, and where I think the field is most confused.

There’s a seductive logic to the microservice as the unit of agentic regeneration. It sounds small. The word micro is in the name. You can imagine handing an agent a service with a defined API contract and saying: implement this, test it, done. The scope feels manageable.

Ford and Newman give this idea fair credit, but they’re also honest about the gap. The microservice level is attractive architecturally because it comes with an implied boundary: a process boundary, a deployment boundary, often a data boundary. You can put fitness functions around it. You can say this service must handle X load, maintain Y error rate, expose Z interface. In theory.

In practice, we barely enforce this stuff ourselves. The agents have learned from a corpus of human-written microservices, which means they’ve learned from the vast majority of microservices that were written without proper decoupling, without real resilience thinking, without any rigorous capacity planning. They don’t have our aspirations. They have our habits.

The deeper problem, which Neal raises and which I think deserves more attention than it gets, is transactional coupling. You can design five beautifully bounded services and still produce an architectural disaster if the workflow that ties them together isn’t thought through. Sagas, event choreography, compensation logic: This is the stuff that breaks real systems, and it’s also the stuff that’s hardest to specify, hardest to test, and hardest for an agent to reason about. We made exactly this mistake in the SOA era. We designed lovely little services and then discovered that the interesting complexity had simply migrated into the integration layer, which nobody owned and nobody tested.

Sam’s line here is worth quoting directly, roughly: “To err is human, but it takes a computer to really screw things up.” I suspect we’re going to produce some genuinely legendary transaction management disasters before the field develops the muscle memory to avoid them.

The sociotechnical gap nobody is talking about

There’s a dimension to this conversation that Ford and Newman gesture toward but that I think deserves much more direct examination: the question of what happens to the humans on the other side of this generated software.

It’s not completely accurate to say that all agentic work is happening on greenfield projects. There are tools already in production helping teams migrate legacy ERPs, modernize old codebases, and tackle the modernization challenge that has defeated conventional approaches for years. That’s real, and it matters.

But the challenge in those cases isn’t merely the code. It’s whether the sociotechnical system, the teams, the processes, the engineering culture, the organizational structures built around the existing software are ready to inherit what gets built. And here’s the thing: Even if agents combined with deterministic guardrails could produce a well-structured microservice architecture or a clean modular monolith in a fraction of the time it would take a human team, that architectural output doesn’t automatically come with organizational readiness. The system can arrive before the people are prepared to own it.

One of the underappreciated functions of iterative migration, the incremental strangler fig approach, the slow decomposition of a monolith over 18 months, is not primarily risk reduction, though it does that too. It’s learning. It’s the process by which a team internalizes a new way of working, makes mistakes in a bounded context, recovers, and builds the judgment that lets them operate confidently in the new world. Compress that journey too aggressively and you can end up with architecture whose operational complexity exceeds the organizational capacity to manage it. That gap tends to be expensive.

At QCon London, I asked Patrick Debois, after a talk covering best practices for AI-assisted development, whether applying all of those practices consistently would make him comfortable working on enterprise software with real complexity. His answer was: It depends. That felt like the honest answer. The tooling is improving. Whether the humans around it are keeping pace is a separate question, and one the industry is not spending nearly enough time on.

Existing systems

Ford and Newman close with a subject that almost never gets covered in these conversations: the vast, unglamorous majority of software that already exists and that our society depends on in ways that are easy to underestimate.

Most of the discourse around agentic AI and software development is implicitly greenfield. It assumes you’re starting fresh, that you get to design your architecture sensibly from the beginning, that you have clean APIs and tidy service boundaries. The reality is that most valuable software in the world was written before any of this existed, runs on platforms and languages that aren’t the natural habitat of modern AI tooling, and contains decades of accumulated decisions that nobody fully understands anymore.

Sam is working on a book about this: how to adapt existing architectures to enable AI-driven functionality in ways that are actually safe. He makes the interesting point that existing systems, despite their reputation, sometimes give you a head start. A well-structured relational schema carries implicit meaning about data ownership and referential integrity that an agent can actually reason from. There’s structure there, if you know how to read it.

The general lesson, which he states without much drama, is that you can’t just expose an existing system through an MCP server and call it done. The interface is not the architecture. The risks around security, data exposure, and vendor dependency don’t go away because you’ve wrapped something in a new protocol.

This matters more than it might seem, because the software that runs our financial systems, our healthcare infrastructure, our logistics and supply chains, is not greenfield and never will be. If we get the modernization of those systems wrong, the consequences are not abstract. They are social. The instinct to index heavily on what these tools can do in ideal conditions, on well-specified problems with good documentation and thorough test coverage, is understandable. But it’s exactly the wrong instinct when the systems in question are the ones our lives depend on. The architectural mindset that has served us well through previous paradigm shifts, the one that starts with trade-offs rather than capabilities, that asks what we are giving up rather than just what we are gaining, is not optional here. It’s the minimum requirement for doing this responsibly.

What I take away from this

Three things, mostly.

The first is that introducing deterministic guardrails into nondeterministic systems is not optional. It’s imperative. We are still figuring out exactly where and how, but the framing needs to shift: The goal is control over outcomes, not just oversight of output. There’s a difference. Output is what the agent generates. Outcome is whether the system it generates actually behaves correctly under production conditions, stays within architectural boundaries, and remains operable by the humans responsible for it. Fitness functions, capability tests, boundary definitions: the boring infrastructure that connects generated code to the real constraints of the world it runs in. We’ve had the tools to build this for years.

The second is that the people saying this is the future and the people saying this is just another hype cycle are both probably wrong in interesting ways. Ford and Newman are careful to say they don’t know what good looks like yet. Neither do I. But we have better prior art to draw on than the discourse usually acknowledges. The principles that made microservices work, when they worked, real decoupling, explicit contracts, operational ownership, apply here too. The principles that made microservices fail, leaky abstractions, distributed transactions handled badly, complexity migrating into integration layers, will cause exactly the same failures, just faster and at larger scale.

The third is something I took away from QCon London this year, and I think it might be the most important of the three. Across two days of talks, including sessions that took diametrically opposite approaches to integrating AI into the software development lifecycle, one thing became clear: We are all beginners. Not in the dismissive sense but in the most literal application of the Dreyfus model. Nobody, regardless of experience, has figured out the right way to fit these tools inside a sociotechnical system. The recipes are still being written. The war stories that will eventually become the prior art are still happening to us right now.

What got us here, collectively, was sharing what we saw, what worked, what failed, and why. That’s how the field moved from SOA disasters to microservices best practices. That’s how we built a shared vocabulary around fitness functions and evolutionary architecture. The same process has to happen again, and it will, but only if people with real experience are honest about the uncertainty rather than performing confidence they don’t have. The speed, ultimately, is both the opportunity and the danger. The technology is moving faster than the organizations, the teams, and the professional instincts that need to absorb it. The best response to that isn’t to pretend otherwise. It’s to keep comparing notes.

If this resonated, the full fireside chat between Neal Ford and Sam Newman is worth watching in its entirety. They cover more ground than I’ve had space to react to here. And if you’d like to learn more from Neal, Sam, and Luca, check out their most recent O’Reilly books: Building Resilient Distributed Systems, Architecture as Code, and Building Micro-frontends, second edition.

For example, an architect can define a set of components via a diagram, along with their dependencies and relationships. That design reflects careful thought about coupling, cohesion, and a host of other structural concerns. However, when they turn that diagram over to a team to develop it, how can they be sure the team will implement it correctly? By defining the components in code (with verifications), the architect can both illustrate and get feedback on the design. However, we recognize that architects don’t have a crystal ball, and design should sometimes change to reflect implementation. When a developer adds a new component, it isn’t necessarily an error but rather feedback that an architect needs to know. This isn’t a testing framework; it’s a feedback framework. When a new component appears, the architect should know so that they can assess: Should the component be there? Perhaps it was missed in the design. If so, how does that affect other components? Having the structure of your architect defined as code allows deterministic feedback on structural integrity.

This capability is useful for developers. We defined these intersections as a way of describing all different aspects of architecture in a deterministic way. Then agents arrived.

Agentic AI shows new capabilities in software architecture, including the ability to work toward a solution as long as deterministic constraints exist. Suddenly, developers and architects are trying to build ways for agents to determine success, which requires a deterministic method of defining these important constraints: Architecture as Code.

An increasingly common practice in agentic AI is separating foundational constraints from desired behavior. For example, part of the context or guardrails developers use for code generation can include concrete architectural constraints around code structure, complexity, coupling, cohesion, and a host of other measurable things. As architects can objectively define what an acceptable architecture is, they can build inviolate rules for agents to adhere to. For example, a problem that is gradually improving is the tendency of LLMs to use brute force to solve problems. If you ask for an algorithm that touches all 50 US states, it might build a 50-stage switch statement. However, if one of the architect’s foundational rules for code generation puts a limit on cyclomatic complexity, then the agent will have to find a way to generate code within that constraint.

This capability exists for all nine of the intersections we cover in Architecture as Code: implementation, engineering practices, infrastructure, generative AI, team topologies, business concerns, enterprise architect, data, and integration architecture.

Increasingly, we see the job of developers, but especially architects, being able to precisely and objectively define architecture, and we built a framework for both how to do it and where to do it in Architecture as Code–coming soon!