Here is what our golden path asks of a developer who wants to ship a new service. Pick the right template from a menu of similar-sounding options. Fill in roughly twenty fields, several of which assume you already know our tagging taxonomy. Understand enough Terraform to recognize which module does what, configure the pipeline correctly, and request the right permissions.
That path is a real achievement. I have spent years helping build it, and I would defend every control on it. It beats starting from zero by a wide margin. But I have stopped pretending it is simple, because the golden path has a quiet requirement we rarely say out loud. Before a developer can walk the road, we ask them to learn it.
The golden path is a syllabus
Platform engineering earned its keep by paving the road. We took hundreds of decisions that every team used to make badly and differently, and we turned them into templates, defaults, and guardrails. The paved road works. What it never fixed is the interface, which still speaks implementation. To use our platform well, a developer has to hold our taxonomy, our module names, our pipeline stages, and our exception processes in their head.
The expensive part of that knowledge does not transfer. A developer who mastered our golden path would still start over at their next company, because what they learned was us. That is the tell. When the expertise a platform demands is expertise about the platform itself, the platform is charging a tax and calling it a curriculum.
Intent is the new interface
With agents in the loop, the interface can move up a level. Instead of a template plus twenty fields, the developer states what they need:
I need a TypeScript API, externally accessible, storing customer-confidential data, deployed in two regions, with a 99.95% availability target.
Natural language is not the contract. It is how the developer enters the contract. The platform should normalize that request into structured, reviewable intent: workload type, exposure, data classification, regions, availability target, and whatever else the organization needs to make the request unambiguous.
From there, the agent translates that intent into our approved primitives: the right template, the right modules, the right pipeline, the right access requests. Translating a clear specification into approved platform primitives is implementation, and implementation is exactly what agents are getting good at.
I argued in The Spec Is the Product that code is becoming the regeneratable output of a clear, versioned specification. Your Platform Has a New User: The Agent made the case that the platform now serves both the developer and the developer's agent. The intent interface is where those ideas meet. The developer expresses the specification. The agent creates the implementation. The platform verifies that the result satisfies its constraints.
The golden path does not disappear in this model. It stops being the primary interface and becomes the compiler target. Templates, modules, pipelines, policies, and controls are still there. The developer just no longer needs to learn their names before asking the platform for the right outcome.
The platform still owns the road
Nothing about this loosens control. The platform still owns the standards, the controls, the architecture, the pipelines, and the verification. The gate does not care whether a human or an agent produced the configuration. It checks the result against the constraints and passes or fails it. Trust the gate, not the actor.
AI changes the interface. The ownership stays exactly where it was. If anything, the intent interface strengthens the platform's hand, because intent that compiles through approved primitives cannot quietly wander off the road the way a hand-edited Terraform file can.
What a platform team does on Monday
Four moves make this concrete.
First, publish intent schemas. Decide what a developer must state and what the platform will derive. That line is the most consequential design decision on this list. Everything on the left is cognitive load you have chosen to keep. Everything on the right is a policy you now own and have to defend.
| The developer states | The platform derives |
|---|---|
| Workload type | Runtime, base image, service template |
| Exposure | Ingress, network placement, edge rules |
| Data classification | Encryption, key management, retention |
| Availability target | Regions, replication, backup policy |
| Team and cost center | Tagging, budget guardrails, chargeback |
Draw that line too far left and you have rebuilt the twenty-field form with better manners. Draw it too far right and you are quietly deciding things the developer should decide on purpose, like what a second region actually costs. An intent schema is a contract, and it deserves the same versioning discipline as any API you ship. Natural language can help populate it. The schema is what the platform should trust.
Second, make your constraints machine-readable. An agent can only compile intent into compliant primitives if the compliance rules exist somewhere better than a wiki page and a reviewer's memory. This is the argument from Context Is a Platform Capability Now: trusted context is canonical, versioned, fresh, attributable, accessible, and safe, and providing it is platform work.
Third, keep the compiled result inspectable. Intent in, primitives out, and a diff a human can read. That diff is also your new review artifact. When one stated intent produces four hundred lines of Terraform, nobody is really reviewing the Terraform, and pretending otherwise is how teams start approving changes by scroll speed. Review the intent, then review the delta between what the schema would have produced by default and what this request produced instead. The exceptions are where the judgment lives. The moment intent compiles into something nobody can inspect, you have traded a syllabus for a black box, and the black box is worse.
Fourth, instrument what fails to compile. Every intent your platform cannot satisfy is a gap in the schema, a gap in the capability catalog, or a policy nobody can defend anymore. All three are worth knowing about. Log the requests that fall back to a human, count them by cause, and work the list in priority order. A schema that cannot express what developers actually need is a syllabus with extra steps.
The objection worth taking seriously
The pushback I expect: if developers stop learning the platform, they stop understanding their systems. I take the concern seriously, and I think it aims at the wrong target. Knowing which of our nine templates maps to which workload was never engineering. Choosing the right data classification, understanding the failure modes of a two-region deployment, and deciding what 99.95% actually costs: that is engineering. The intent interface puts those decisions in front of the developer instead of burying them under field twelve of twenty.
There is a harder question hiding behind this one. When intent compiles to implementation, who understands the running system at 3 a.m. two years from now? That question deserves its own essay, and it gets one soon.
The golden path asked developers to learn the road before they could use it. An intent interface asks them where they are going and picks the road. Our job is making sure every road it can pick is one we already paved.
