Coding Agents Don't Replace Platforms — They Make Them More Important

There’s a growing belief in engineering circles that because coding agents can generate code so cheaply and quickly, we no longer need to invest in platform frameworks, services, and shared systems. The argument goes something like: code is essentially free now, so why bother with reusable building blocks? Just let agents generate what you need on the fly.

I think this perspective fundamentally misunderstands both how agents work and what makes software development expensive.

Agents Already Use Frameworks

Here’s the irony of the “we don’t need platforms anymore” argument: coding agents themselves rely heavily on frameworks, libraries, and established patterns to produce good output.

When you ask Claude Code or Cursor to build you a web application, it doesn’t reinvent HTTP from scratch. It reaches for React, FastAPI, Express, or whatever framework fits the context. When it writes infrastructure code, it uses Terraform modules or Pulumi components. The agent’s effectiveness comes precisely from having well-understood building blocks to compose, not from generating everything from raw primitives.

Addy Osmani captured this well in his piece on writing specs for AI agents, noting that vague prompts produce vague results while specific constraints and well-defined building blocks dramatically improve output quality.

This maps directly to platform engineering. A well-designed internal developer platform is, at its core, a curated set of constraints and building blocks. Golden paths, opinionated templates, standardized observability, security guardrails — these aren’t overhead. They’re the context that makes both human and AI-driven development faster and more reliable.

Constraints Improve Agent Output

There’s a counterintuitive principle at work here: giving agents fewer choices often produces better results.

When an agent operates with a blank canvas and unlimited options, it pattern-matches against its training data, which includes code of wildly varying quality. The result is what people call “AI slop”: technically functional output that’s tangled, inconsistent, and painful to maintain. But when you provide architectural constraints, approved component libraries, established patterns, and clear specs, the agent’s output improves dramatically.

This is why the emerging best practice for agentic development isn’t “let the agent do whatever it wants”. Instead, teams are investing in AGENTS.md files, architectural constraint validators, spec-driven development workflows, and code health scoring systems that give agents objective signals about quality. As CodeScene’s analysis of agentic coding patterns concludes: coding via agents requires more rigor, more structure, more code quality — not less.

Platform engineering is the organizational expression of exactly this idea. When you give development teams (and their agents) a set of well-maintained building blocks (vetted libraries, standardized service templates, pre-configured CI/CD pipelines, embedded observability) you’re constraining the solution space in productive ways. If you need more building blocks, you can use agents to build those too. The platform grows, but it grows deliberately.

Disposable Code vs Durable Code

Charity Majors wrote a piece that frames this tension well: Disposable Code Is Here to Stay, but Durable Code Is What Runs the World. Her core argument is that software development is separating into two domains with very different cost models and risk profiles.

Disposable code (design mocks, experiments, data processing scripts, prototypes) has exploded since agents made generation cheap. You spin something up, use it, throw it away. Agents are fantastic at this.

But then there’s the code that runs financial transactions, manages medical records, routes airline flights, and powers commerce sites. This is durable code, and its cost isn’t defined by how hard it was to write. The cost is defined by the standards you build to and the entire lifecycle that follows: maintenance, extension, migration, understanding its behavior, and fixing it when it breaks. Disposable code is cheap because you don’t even try to maintain it. Durable code is expensive because you must.

This distinction matters enormously for the platform engineering conversation. Platform systems (the shared services, frameworks, SDKs, infrastructure components) are definitionally durable code. They’re the foundation that many teams and many applications depend on. They need to be reliable, performant, well-tested, observable, and maintained over time. As Majors points out, the cheapest way to build good durable software is by investing in the sociotechnical systems that unlock fast feedback loops: CI/CD, observability, testing. The only companies currently reaping efficiency gains from AI are the ones who already invested in these foundations.

Building is the shortest phase of a software system’s life. Maintenance is where the real cost lives. A platform of durable building blocks doesn’t just speed up initial development — it dramatically reduces the ongoing cost of maintaining everything built on top of it.

Specs, Code, and the Feedback Loop

I see enormous value in using agents for durable purposes, not just throwaway scripts. Drew Breunig’s experiment with a software library with no code is an interesting thought experiment. He released whenwords, a library containing only a spec and tests, no implementation code. You paste the spec into a coding agent, tell it your target language, and it generates a working implementation. It works across Ruby, Python, Rust, Swift, and more.

Maybe we don’t need to share code at all, just specs and tests. Vercel built just-bash (a simulated bash environment in TypeScript) and Pydantic built Monty (a Python interpreter in Rust) using similar approaches — throw a test suite at an agent, make it pass.

But in a follow-up talk, Breunig walked back the premise. His biggest takeaway: “No-code libraries are toys because they are unproven.” The act of implementing code clarifies and communicates intent in ways that specs alone cannot. A spec doesn’t truly work until it’s implemented, just like software doesn’t truly work until it meets the real world.

He reframed spec-driven development from a one-way equation (specs + tests + agent = code) into what he calls the Spec-Driven Development Triangle: a feedback loop where implementing code improves the spec, updated specs drive new tests, and the three nodes must be kept in sync as they evolve. Even with well-defined specs, real-world projects generated 20-comment threads debating the right way to implement something, because no spec is ever complete.

Durable platform building blocks aren’t just code, they’re code that has been through that triangle many times. The spec has been refined by implementation. The tests have been shaped by production behavior. The code has earned trust through time. That feedback loop is precisely what makes platform components more valuable than freshly generated code, no matter how good the agent is.

There’s a middle ground between “generate everything from scratch” and “only use proven platform code” that I find compelling, and it’s directly relevant to platform engineering.

Using Agents to Extend Platform Reach

Consider a server-driven UI system. The real value of such a platform is on the server side: the configuration layout, the integration with data systems for hydration, the logic and filtering for managing delivered content, the APIs for client interaction. This is durable, complex, evolving code that benefits from deep expertise and long-term investment.

The frontend SDK, though, is a different story. It’s written in a specific tech stack (Swift for iOS, Kotlin for Android, React for web) but the behavior it implements is largely mechanical: take the server’s UI models, render components, handle actions, manage state. If you could extract the specs (the API contracts, the UI model definitions, the action behaviors) you could ask an agent to generate a frontend SDK in a new tech stack. React Native, Flutter, whatever your team needs next.

This isn’t “disposable code generated on the fly.” It’s using agents to build durable code from durable specs, extending the platform’s reach to new tech stacks without requiring a team of specialists in each one. The server-side platform remains the source of truth. The generated SDKs are tested against the same contract. The specs are the stable foundation; the implementations are the part that agents can help scale.

You could apply the same pattern to client API wrappers. If you have a well-specified API (clear endpoints, typed request/response models, error handling contracts, authentication flows) an agent can generate idiomatic client libraries for Python, Go, TypeScript, Java, and beyond. Not as throwaway code, but as maintained, tested libraries that follow the spec. When the API changes, you update the spec and regenerate.

This is something like Breunig’s original “library with no code” concept, but bounded and connected to a larger platform system. The spec isn’t floating freely, it’s anchored to a real, maintained, durable platform. These generated implementations feed back into the triangle: building the Flutter SDK might reveal ambiguities in the spec that the Swift SDK never surfaced, improving the platform for everyone. The generated code isn’t pure commodity. It extends the platform’s value into new contexts while strengthening the spec it’s built from.

Google’s recent A2UI project hints at a similar future: a declarative UI protocol where agents send component descriptions that different client renderers (web, mobile, desktop) can display natively. The spec is the stable contract; the renderers can be built per-platform, potentially with agent assistance.

The Real Relationship: Agents and Platforms Together

The emerging picture isn’t agents vs. platforms. It’s agents and platforms reinforcing each other.

Platforms give agents the constraints, context, and building blocks they need to produce high-quality output. Golden paths become agent-friendly paths. Architectural validators catch agent mistakes before they hit production. Standardized templates mean agents start from a proven foundation rather than a blank page.

Agents, in turn, help platforms scale their impact. They can generate implementations from specs across multiple tech stacks. They can help maintain the platform itself, updating templates, running migrations, fixing linting issues across codebases. They can handle the mechanical work of extending platform reach to new contexts.

The State of Platform Engineering Report calls this the “dual mandate” for 2026: platforms must be AI-powered (using agents to enhance developer productivity) and must simultaneously be platforms for AI (providing the guardrails and governance that agents need to operate safely). Ninety-four percent of organizations now view AI as critical to the future of platform engineering.

As the Anthropic Agentic Coding Trends Report puts it, engineers are shifting from writing code to coordinating agents — focusing expertise on architecture, system design, and strategic decisions. That’s exactly what platform engineering has always been about: making the right thing the easy thing, so teams can focus on what matters.

The Takeaway

Code generation getting cheaper doesn’t mean platforms get less important. It means they get more important.

Building blocks improve agent output. Agents with constrained, well-defined component libraries produce better code than agents with a blank canvas. Platform engineering provides those blocks.

Maintenance outlasts building. The cheapest part of a software system’s life is writing the first version. Durable building blocks reduce the cumulative maintenance burden across every application built on top of them.

Agents can extend platform reach. Well-specified platform systems (APIs, UI models, action contracts) can be implemented across new tech stacks with agent assistance, turning platform specs into multi-platform value.

Platforms need to serve agents too. As agents become active participants in the development lifecycle, platforms must provide the guardrails, context, and observability that agents need to operate reliably.

The organizations that will move fastest aren’t the ones letting agents generate everything from scratch. They’re the ones giving agents great building blocks to work with and using agents to make those building blocks available everywhere.