For years, platform engineering has worked from a simple premise: the developer is the customer.
Build the paved road, reduce cognitive load, and automate the undifferentiated work. Make the secure path the easy path, so developers spend more time building software and less time learning how the machinery underneath it works.
I still believe all of that. What is changing is the customer. The developer increasingly arrives with an agent sitting beside them.
Claude Code, Codex, GitHub Copilot, Cursor, and whatever comes next are becoming part of the development environment. Developers are asking agents to understand codebases, diagnose failures, modify applications, generate infrastructure, create tests, review pull requests, and eventually perform larger chunks of the software delivery life cycle.
That creates an interesting question for those of us who own developer platforms. What happens when the consumer of your platform is no longer just a human?
I think the answer has much bigger implications than adding a chatbot to the developer portal.
Your platform now has two personas
Most internal platforms are designed around a human interaction model. A developer reads the documentation, knows which repository template to use, understands how the pipeline works, and recognizes an internal acronym in an error message. They know that one configuration lives in a wiki page and another is buried three levels deep in a service catalog. When they get stuck, they ask someone.
In a mature platform organization, we try to reduce how often that happens. But an enormous amount of organizational context still lives in documentation, conventions, conversations, and tribal knowledge. Humans are surprisingly good at working around that mess.
Agents are much less capable of working around that ambiguity.
An agent cannot reliably infer that the architecture standard documented three years ago on your Wiki is obsolete but still ranks first in search. It does not know that the deployment example in a README is technically valid but discouraged. It cannot walk over to someone on the platform team and ask what Tier F actually means.
It knows what we make available to it.
That means the internal developer platform increasingly has two personas: the developer and the developer's agent. And that gives platform owners a new design constraint.
The agent-readiness test
Here is a simple test I have started thinking about:
If an AI coding agent joined your company tomorrow, could it figure out how to deploy an application correctly without asking someone on the platform team?
The bar is higher than producing some plausible YAML. Could the agent discover the approved path, pick the right application pattern, and understand which controls apply? Could it interpret a failed pipeline? Could it find the authoritative documentation instead of a three-year-old example, and could it tell the difference between what is technically possible and what the organization actually wants developers to do?
That is a much harder test, and I suspect most of our platforms would fail it.
The failure would say more about the platform than about the AI. If the correct path depends on tribal knowledge, humans struggle with it too. If the documentation contradicts the automation, humans eventually notice too. If five teams implement the same pattern five different ways, developers pay that cognitive tax today. Agents simply make those inconsistencies easier to see.
In that sense, agent readiness may become a useful new measure of platform maturity.
Machine-readable beats human-readable
Platform teams have invested heavily in developer documentation, and rightly so. But an agentic development environment requires us to think beyond documentation pages and ask whether the platform itself is understandable.
That means APIs with predictable behavior, schemas that describe themselves, service metadata with clear ownership, versioned standards, structured errors, and discoverable capabilities. The more important something is, the less it should depend on an agent scraping prose and hoping it interpreted the paragraph correctly.
This extends a principle I already believe strongly: standards are more valuable when they live in systems than when they live in documents. If every production service requires ownership metadata, enforce it. If every internet-facing application needs a particular security control, encode it. If only three deployment patterns are supported, make those three discoverable through the platform. And if a workload needs additional resilience because of its criticality tier, the platform should know how to translate that tier into infrastructure.
Humans benefit from this too, and that is one of the things I find most interesting about designing platforms for agents. Most of the improvements that make the platform easier for an agent also make it better for developers. Clear APIs beat tribal knowledge, deterministic automation beats wiki instructions, and useful error messages beat numeric failure codes. Canonical examples beat 40 slightly different Git repositories.
The agent is not creating the need for good developer experience. It is increasing the cost of bad developer experience.
Error messages become an interface
Error handling is a small example with outsized implications. Developers encounter platforms through failure as much as through success: a build fails, a permission is denied, a deployment violates a policy, a workload refuses to start.
Historically, platform teams have written those errors for themselves. AccessDeniedException. Policy check failed. Exit code 1. Technically accurate and practically useless. A developer translates the error through experience, documentation, Slack history, or a support ticket. Agents will try to do the same thing. The difference is that agents give us a compelling reason to make the error itself useful.
Instead of:
Deployment rejected: policy violation.
Imagine:
Deployment rejected because this service is classified as customer-facing and requires multi-AZ deployment. Set
availability: multi-azinservice.yaml. See the approved customer-facing service pattern.
That is a better platform interface, not merely better documentation. The developer understands the failure, the agent understands the failure, and both have enough information to attempt a safe correction. The best support ticket may be the one the platform never requires.
Give agents capabilities, not just context
There is another side to this. It is not enough for agents to understand the platform; eventually they need safe ways to act through it.
I do not want an autonomous coding agent reverse-engineering how to create an AWS account, constructing raw IAM policies, inventing Terraform, and calling infrastructure APIs directly. I want the agent consuming the same opinionated capabilities we want developers consuming: create a service, request a database, deploy a workload, add a secret, expose an API, run a security scan, roll back a deployment. Those capabilities should already encode our architecture, security, reliability, financial, and operational expectations.
The agent supplies intent, and the platform supplies constraints. The combination produces an approved action.
This connects closely to an argument I made in The Spec Is the Product. As execution gets cheaper, describing what we actually want becomes increasingly important. The developer should be able to say:
I need a TypeScript API that stores confidential customer information, is externally accessible, and needs 99.9% availability.
The agent can help translate that intent. But the agent should not invent what 99.9% availability means inside my organization. The platform should know that. It should know which deployment pattern is approved, which network controls apply, what observability is required, how backups work, which regions are allowed, and which security controls are mandatory.
AI changes the interface. It should not weaken the architecture.
The paved road becomes more important, not less
There is a temptation to assume that AI makes platform abstraction less important. If an agent can write Terraform, maybe everyone can just write Terraform. If it understands Kubernetes, maybe developers no longer need an abstraction over Kubernetes. If it can debug AWS, maybe the opinionated cloud platform has run its course.
I think the opposite is true. Generating infrastructure becomes easier. Generating correct infrastructure for your organization remains difficult. An agent can produce hundreds of technically valid solutions. None of that tells it which solution aligns with your security model, cost expectations, architecture strategy, operational capabilities, regulatory requirements, or support model.
Abundant generation makes constraints more valuable. The paved road therefore becomes more important in an agentic environment, not less. It becomes the boundary between what an agent can create and what the organization is actually prepared to operate.
One of the central ideas in my writing about the agentic SDLC is that we trust the gate, not the actor. We do not govern this environment by trusting every actor to make the correct decision. We govern the system through gates, standards, feedback loops, and verification, and the platform is where many of those controls should live.
Context becomes part of the platform
Agents need to understand more than infrastructure APIs. They need architecture standards, application classifications, service ownership, approved libraries, dependency information, security requirements, deployment patterns, operational history, and current documentation. In other words, they need context, and I think platform teams will increasingly inherit the job of providing it.
Today, that knowledge is scattered everywhere. Some of it lives in Git, some in a developer portal, some in Confluence, some in tickets, some in Slack, and a surprising amount in people's heads.
We have spent years building platforms that standardize infrastructure. I suspect the next phase of platform engineering will include standardizing how organizational context is exposed to developers and agents. That does not mean dumping every document into a vector database and calling it done. Context needs ownership, freshness, provenance, and access controls. It needs to distinguish authoritative guidance from someone's experiment in a repository three years ago.
That starts to make context itself a platform capability, and I think it will become one of the most important developer experience problems of the next few years.
Do not build PlatformGPT
The most obvious response to all of this is probably the least interesting one. Build a chat window, connect it to some documentation, and call it PlatformGPT.
There will absolutely be useful conversational interfaces to internal platforms, and I expect us to build some. But I do not think that is the end state. The best AI developer experience may become almost invisible. The failed pipeline explains itself, the CLI suggests the compliant fix, and the service catalog already understands the application. The developer expresses intent, the platform translates that intent into the correct capabilities, and the agent discovers what it needs without reverse-engineering the organization.
Developers should not have to stop what they are doing, navigate somewhere else, and ask an AI how the platform works. The platform should increasingly explain itself. That is a much higher bar, and a much more interesting one.
A platform product question
None of this changes the core job of platform engineering. Platform teams exist to take complexity that every development team would otherwise absorb and turn it into reusable capabilities. AI gives us another powerful way to do that.
It also creates a new consumer with very different strengths and weaknesses. Agents are fast, persistent, and able to consume enormous amounts of information, and they will retry a solution as many times as it takes. They are also perfectly capable of confidently taking the wrong path if the platform makes that path easier to discover than the right one.
So the question for platform owners is no longer just whether the platform is easy for a developer to use. We should start asking whether the right thing is easy for both the developer and the developer's agent to discover, understand, and execute. Cleaner interfaces, better metadata, explicit standards, useful failures, trusted context, and strong verification are not new platform engineering ideas. AI raises the stakes on all of them.
We spent the last decade building platforms for developers. The next generation of those platforms will still serve developers, but developers will increasingly bring someone with them.
Your platform has a new user. It is probably time we started designing for it.
