‍Heinrich Hartmann has generated more code in the past two months than in any period of time he can remember. He also hasn’t written more than five lines of it himself.

During a sabbatical from his role as a Senior Principal SRE, Heinrich went deep on a side project that featured a lot of AI-assisted development. He built a typesetting system on top of MkDocs, patched a Terraform provider via Claude Code to manage conference mailing lists, and wired up integrations that would have taken weeks by hand. The output was real. The code just wasn’t written by hand.

Code like this is also increasingly getting pushed to production environments. His response: "I don't care who typed the code. You own the code. You are employed for your judgment and your expertise, and you can delegate the doing, but you cannot delegate the ownership or the accountability."

What AI changes is how fast you can do the parts you're accountable for — the architecture, the validation, the design decisions that determine whether the code holds up.

The Abstraction Shift

Heinrich describes his AI-assisted workflow like managing a small team: "You basically have three junior programmers, who all have PhDs. But it's their first day." They're fast. They're super capable. And they have no context about your codebase, your conventions, or your business.

So you manage them the way a good tech lead manages any team. You write ADRs (architecture decision records, the short documents that capture design rationale and constraints so decisions survive beyond the person who made them). You write style guides. You break work into scoped tasks. You define testing requirements. And then you review everything that comes back.

"I'm not doing anything differently than I would with a team," Heinrich says, "but I'm moving up the abstraction chain. I'm now more of an orchestrator and a manager than I am an executor and a coder."

If AI shifts engineering toward orchestration, the artifacts that support orchestration become the infrastructure that determines code quality. Not the AI model. Not the prompting technique. The context you feed it.

More Code, More Review

The productivity gains are real, but so is the cost.

"I'm never sure what the hell this next model is going to do with my code," Heinrich says. "I'm really tired of debugging stuff that used to work. It was working 20 commits ago, and now it's no longer working. So now I have to guide the language model through a tedious debugging session."

AI generates code faster than any individual can. But every line still needs to be owned by someone who understands what it does, why it's there, and what breaks if it changes. Volume goes up while familiarity goes down. And the review burden lands entirely on the human.

Anyone working heavily with AI tools has felt a version of this: AI reduces the cost of production but increases the cost of review, coordination, and decision-making. Each task is faster. The total cognitive load is not lower. It's redistributed toward judgment work, evaluating output you didn't create, which is a fundamentally different kind of effort than creating it yourself.

Heinrich's response wasn't to slow down. It was to invest more in validation. For one project, a typesetting system of moderate complexity, he wrote 85 integration tests. "Usually I would carefully code this kind of stuff without writing any tests, because I can get it to 'good enough' with half the effort, and it holds up for a long time. But now I’m no longer writing the code, integration tests have become very cheap. And because I don’t trust the code as much, I now need the validation."

The math is worth sitting with. Before AI, he wrote very few tests for stand-alone side-projects because the code was his and he understood it intimately. With AI, he writes 85 tests, because it’s cheap and effective at meeting the quality bar. Ownership didn't get easier. The effort just moved from writing to reviewing.

Design Compounds. Code Doesn't.

As AI can handle more of the low-level implementation, engineers are shifting their skillset upward: architecture, system design, understanding how components interact under load and over time.

John Ousterhout, the Stanford professor behind A Philosophy of Software Design, has argued in recent conversations with the Pragmatic Engineer that this makes design more important at every level of seniority, not just for staff engineers. When a model can generate a function in seconds, the value is in knowing which function to build, how it fits the broader system, and what it implies for future maintainability.

Heinrich's practice reflects this. His ADRs aren't busywork. They're the interface between his intent and the AI's execution. "You can onboard the model with the intentions from the ADRs. You have the integration test suite, and you're good to go." The decision records serve double duty: they capture design rationale for future human contributors and constrain AI behavior in the current session. Without them, each new model session starts from zero. With them, the work compounds.

Heinrich extends this to how ADRs get created in the first place: "You don't really produce ADRs by writing them. You produce them by giving the AI notes from a meeting and asking it to summarize and produce it. Or you give it a PDF from 10 years ago and say, scan the code base and summarize this as a style guide." The AI co-creates the documentation that then constrains its own future output. It's a feedback loop, and the engineer's job is to curate it.

AI Built It. You Own It.

Heinrich's argument about ownership extends naturally to how teams should be organized. He's a firm believer in the you-build-it-you-run-it model, and he sees AI making the case stronger.

"It should be you build it, you own it, you run it," he says. "This is more of a concern about performance and delivery speed than it is about reliability, because you create so much friction if you do the handover." When the person on call is also the same person who specified the intent, reviewed the AI output, wrote the ADRs, and defined the test suite, the accountability loop is tight. Break that loop with a handover to a separate operations team, and all the context that makes AI-generated code trustworthy gets lost in translation.

Heinrich extends this to SRE tooling more broadly: "The core value of any SRE product is more about productivity than reliability. Everybody will get to ‘good enough’ with whatever tools you give them. If you have a build-it-run-it culture, every developer will figure out how to do that reliably enough pretty soon. A great SRE tool just gets you there a lot faster."

This reframes the question. It's not "does AI make our systems more reliable?" It's "does AI help the people who own those systems reach reliability faster?" The accountability stays with the human. AI's job is to shorten the path.

"The constants are the tasks and accountability. They stay the same," Heinrich says. "It's just a question of which levels you're automating. The human part will be judgment and high-level architecture. You can delegate the execution, but you cannot delegate the ownership."

‍

Heinrich Hartmann is a Senior Principal SRE, host of the CASE Podcast, Chair of SREcon EMEA 2025, and organizer of Signals Berlin 2026, a single-track conference on reliability in the age of AI (Berlin, September 2026). Read more at his personal blog.