From Cloud-Native to AI-Native: What Actually Changes
written by Stefan Christoph
The Fifteen-Year Echo
Fifteen years apart. Same stage. Different world.
In 2010, Adrian Cockcroft stood on the QCon stage and told the audience that Netflix was running its entire business on a public cloud. Most people in the room thought he was crazy.
Fifteen years later, Cockcroft was back at QCon, this time explaining how he manages swarms of autonomous AI agents that produce several days’ worth of code in fifteen minutes [1]. The audience reaction was different. Nobody called him crazy. They were taking notes.
What struck me wasn’t the technology. It was the pattern. Cloud-native development didn’t appear the day AWS launched EC2. It emerged years later, when practitioners figured out the architectural patterns (microservices, service discovery, circuit breakers, observability) that made distributed systems actually work. The cloud was the infrastructure. Cloud-native was the discipline.
We’re at a similar inflection point with AI. The models are the infrastructure. What we’re missing is the discipline. And the early patterns are starting to crystallize.
The parallel isn’t perfect. Cloud infrastructure fails in messy, timing-dependent ways, but the software running on it has specified semantics: a container either runs your code as written or it doesn’t. AI agents introduce non-determinism in the output itself. The patterns I’ll describe aren’t about making agents deterministic. They’re about building reliable systems on top of probabilistic components, the same way cloud-native patterns built reliable systems on top of infrastructure that could fail at any moment.
AI-Assisted Is Not AI-Native
Luca Mezzalira’s “Token by Token” newsletter recently synthesized a distinction that most teams are quietly avoiding [2]. Peter P. frames it sharply: bolting AI tools onto your existing workflow and getting 10-20% efficiency gains isn’t AI-first. It’s AI-assisted.
The difference matters.
AI-assisted means your developer writes code, and an AI autocompletes some of it. Your architect designs a system, and an AI suggests improvements. Your process stays the same. The AI is a faster pair of hands.
AI-native means redesigning your process around the assumption that the agent is the primary builder. The human provides judgment, constraints, and verification. The architecture, the org structure, the definition of “done”: all of it changes.
I wrote about this shift a few weeks ago [3]: running an entire workday through a coding agent, covering meetings, research, CRM, expenses, and content creation. Not a single line of code. That wasn’t AI-assisted. The workflow was designed from the ground up around what agents are good at (context gathering, synthesis, structured output) and what humans are good at (judgment, relationships, strategy).
Most organizations claiming to “use AI” are AI-assisted. They’ve added Copilot licenses. They’ve run a hackathon. They’ve built a chatbot. The process underneath hasn’t changed. And the productivity data reflects it: a 10% gain, not 10x [4].
The Patterns That Are Emerging
So what does AI-native actually look like in practice? Between Cockcroft’s QCon talk [1], Mezzalira’s synthesis [2], and my own experience building a skill-based agent system, five patterns keep showing up.
A caveat before diving in: these patterns come from a small number of practitioners working on personal or small-team projects. They’re early signals, not established best practices. Some will survive. Some will be replaced by better ideas. That’s exactly how cloud-native patterns evolved too.
1. Director, Not Pair Programmer
The key skill shift isn’t learning to prompt better. It’s learning to evaluate outcomes without reading every line.
Cockcroft’s framing is the most vivid: he manages agents like a director-level manager, not a pair programmer.
“If you’re a director, you don’t read code. You have a team of people. You’re trying to do something for your business. You don’t watch everything they do.”
The agents build things he didn’t ask for. Sometimes things he didn’t know to ask for. He still nags them repeatedly (“I want 100% test coverage, not 90%”) and they behave like human developer teams, with the same annoying patterns. The difference is speed: several days’ work in fifteen minutes.
The key skill shift isn’t learning to prompt better. It’s learning to evaluate outcomes without reading every line. That’s a management skill, not a coding skill.
2. BDD as the Agent Contract
Cockcroft found that Behavior-Driven Development produces significantly better results than TDD when driving agents. The Given/When/Then structure gives agents more constraints, making it harder to fake results. BDD specs become the system specification. In theory, you could delete the codebase and regenerate from specs, though nobody has demonstrated this at production scale yet.
This maps to a broader pattern that keeps proving out in these workflows: the more structured the input, the more reliable the output. Neal Ford and Sam Newman argue that agents are stuck at the “advanced beginner” stage of the Dreyfus skill acquisition model [2], an analogy borrowed from human skill development, not a validated classification of models. On their reading, agents follow rules well but struggle with novel judgment. BDD plays to that strength. You’re not asking the agent to architect. You’re asking it to implement a precise behavioral contract.
I’ve seen the same pattern in non-coding work. The skills in my agent system [3] are essentially BDD specs for professional workflows: given this calendar event, when the attendees include external participants, then pull context from Slack, CRM, and LinkedIn, and produce a briefing document. The more precise the spec, the more reliable the execution.
3. Persistent Knowledge, Not Persistent Prompts
Chris Reddington noticed he kept typing the same setup instructions into every new agent session [2]. His solution: treat the knowledge, not the prompt, as the asset.
His framework uses two file types: AGENTS.md captures repo-wide conventions, and SKILL.md packages reusable procedures that only load when relevant. Both depend on tool support, AGENTS.md travels exactly as far as the tools that have adopted the convention, and skill loading works where the client implements it. Every session starts from a stronger baseline without rebuilding from scratch.
Cockcroft independently arrived at a similar pattern: context blocks. A 100-200 line block comment at the top of each source file containing what the code does, its APIs, version history, and known issues. Every agent reads this first before modifying anything. It works across different tools (Cursor, Claude Code, Codex) because the knowledge lives in the code, not in the tool’s memory.
This is the AI-native equivalent of documentation-as-code. In cloud-native, we learned that infrastructure should be defined in code, not configured manually. In AI-native, agent knowledge should be defined in files, not typed into chat windows.
4. Microservices for Agents
Here’s where the cloud-native parallel gets concrete. Cockcroft found that when multiple agents work on the same codebase, they stomp on each other’s code, exactly like human developers working on a monolith. His solution: break work into separate repos with stable APIs and clean interfaces. Each team of agents works in an independently deliverable single-function service.
Part of the microservices rationale carries over to multi-agent development, the part about contention and clean interfaces, which here lives in repos and worktrees, not in how anything is deployed. The runtime arguments for microservices (independent scaling, ownership, failure isolation) are a separate case that agent work doesn’t automatically inherit. Monolithic agent work produces what Cockcroft calls “a monolithic ball of mud.” In his experience, and mine, specialized agents with bounded contexts produce better results because each agent is single-minded, just doing one job. Then they check on each other’s work.
Claude Flow [1], the multi-agent framework Cockcroft uses, makes this explicit: each agent is set up as a coder, tester, architect, researcher, or DevOps engineer, the persona comes from its role prompt and the orchestration layer, while a specialized MCP server supplies the tools that role needs. They communicate via shared memory and to-do lists. A “Hive queen” agent is the line manager, coordinating the swarm.
5. The Harness: Guides and Sensors
Every failure tightens the harness. Every success adds evidence for the constraints.
Birgitta Boeckeler introduces the concept that ties it all together [2]: a “harness” for trusting coding agents in production, composed of guides (pre-execution constraints) and sensors (post-execution verification).
The human role shifts from writing code to two activities: steering the system by improving guides, and tightening controls every time the agent gets something wrong.
The harness pattern: guides constrain, sensors verify, failures tighten.
One important nuance: the harness doesn’t eliminate the need for domain expertise. It redirects it. The humans writing the initial guides need to understand the domain well enough to specify correct constraints. A fundamentally wrong guide produces confidently wrong output. The feedback loop catches gaps over time, but the starting point still requires competent humans.
This is the feedback loop that lets AI-native systems improve over time, provided someone actually folds the detected failures back into the guides. Every failure tightens the harness. Every success adds evidence, not proof, that the constraints hold, since a passing run can still hide a weak check or a case the sensors never exercised. The system “learns” not through model fine-tuning, but through humans (or automation) improving the scaffolding.
I described this exact pattern as “the flywheel” in my earlier article [3]: every interaction is both productive work and system improvement. A missing contact template gets added. A new expense format gets encoded. The skills don’t come from a product roadmap. They emerge from real work, in real time.
The Organizational Shift
Cockcroft’s most provocative prediction: organizations will shift headcount from application development to platform development.
“You’re going to move your headcount from application development largely to platform development. That platform’s going to do policy, security, guardrails, pre-built components. When a product manager wants to build a feature, they’ll use the platform. They’ll spin up a bunch of developers to go build the next version. That’ll take an hour or so.”
The platform he describes isn’t like the cloud platforms we’ve been building. It’s “incredibly fast changing, chaotic, poorly understood.” Probably “a big pile of MCP servers, all randomly programmed to do something or other.”
This maps to Mezzalira’s argument about the comb-shaped developer [2]: in his view, the T-shaped model (broad knowledge plus one area of deep expertise) is no longer sufficient. When agents handle the breadth, humans need depth in multiple areas. The value shifts from knowing a little about everything to exercising judgment across several specializations.
The implication for engineering organizations, a hypothesis extrapolated from small-team experience, not yet an organizational study, is that the people who build and maintain the agent platform become some of the most critical hires. Not because they write the most code, but because they define the constraints within which all the agent-generated code operates. They’re writing the guides and sensors of Boeckeler’s harness, at organizational scale.
What’s Still Missing
I want to be honest about the gaps. These patterns are emerging, not established.
Cockcroft himself admits he needs a “director agent,” something that nags the other agents into compliance without human intervention. He’s still doing too many repetitive management tasks manually: reminding agents to push to GitHub, insisting on 100% test coverage, cleaning up scattered documentation files.
The observability story is immature. In cloud-native, we built sophisticated monitoring, tracing, and alerting. In AI-native, we’re mostly reading terminal output and hoping for the best. When Cockcroft runs Claude Flow with multiple agents, things move too fast to watch. That’s fine for personal projects. It’s not fine for production systems.
The learning path question is unresolved. The “director, not pair programmer” framing works for senior engineers who have decades of experience evaluating code quality. But where do junior developers build that judgment if agents handle the implementation? The “tidy first” pattern (review and improve agent-generated code) might be part of the answer, but the industry hasn’t figured out AI-native onboarding yet.
And the governance question remains open. Everything I’ve described, and everything Cockcroft demonstrates, works because it’s personal and sandboxed. One user, their own data, mistakes that affect only them. The enterprise version needs identity, access control, audit trails, and cost management. Services like Amazon Bedrock AgentCore provide building blocks for exactly that [5], the controls, not the governance itself; wiring them into something that satisfies your compliance bar is still your work. The coding agent handles the creative, ad-hoc work. The governed platform handles the customer-facing, regulated work. Both will coexist. The boundary between them is still moving.
The Fifteen-Year Bet
Cloud-native took roughly a decade to go from “Netflix is crazy” to “this is how everyone builds software.” The patterns that emerged (twelve-factor apps, service meshes, GitOps, SRE) weren’t obvious at the start. They crystallized through practice, failure, and iteration.
AI-native is at the beginning of that same arc. The five patterns I’ve described (director-level management, BDD contracts, persistent knowledge files, microservices for agents, the guide-and-sensor harness) come from a handful of practitioners working mostly on personal projects. The evidence base is thin. Some of these patterns may turn out to be model-generation-specific and break with the next model shift.
But the underlying principle is more durable than any specific pattern: the discipline of building reliable systems on unreliable components. Distributed-systems and fault-tolerant computing established that principle decades before the cloud; cloud-native operationalized it at industry scale and taught a generation of us to practice it. The components have changed. The discipline hasn’t.
We’re not just adding AI to existing workflows. We’re rebuilding the workflows around AI. My bet: the organizations that figure out the discipline, not just the technology, will end up with the same kind of edge that cloud-native companies had over their lift-and-shift competitors.
The infrastructure is here. The discipline is what we’re building now.
Sources
[1] Cockcroft, A. “Directing a Swarm of Agents for Fun and Profit”, QCon SF 2025 (InfoQ transcript), https://www.infoq.com/presentations/coding-agents/
[2] Mezzalira, L. “Token by Token: Let’s Decode”, a newsletter synthesis featuring Neal Ford, Sam Newman, Chris Reddington, Peter P., Birgitta Boeckeler; the individual positions above are cited as reported in this synthesis, not from each author’s primary talk or article, https://www.linkedin.com/posts/lucamezzalira_lets-decode-this-week-neal-ford-and-sam-share-7450289982029815809-nAfl
[3] Christoph, S. “The Coding Agent That Doesn’t Code”, https://schristoph.online/blog/the-coding-agent-that-doesnt-code/
[4] Christoph, S. “AI Coding Productivity: 10%, Not 10x”, https://schristoph.online/blog/ai-productivity-10-percent-not-10x/
[5] Amazon Bedrock AgentCore, https://aws.amazon.com/bedrock/agentcore/
Related writing:
- Security Is Job Zero, Even (Especially) in the Age of Coding Agents, the security agent as a permanent team member in multi-agent architectures
- “It’s Faster If I Just Do It Myself”, The Most Expensive Sentence in AI, the Dreyfus model and patience patterns for agent adoption
- From Chaos to Control: Building Predictable AI Agents, the skills architecture that implements the harness pattern
- The Protocol We Should Have Built for Humans, MCP as the connectivity layer for AI-native platforms
About the Author
Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.
This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.