Something shifted quietly in how software gets built, and most platform teams haven’t caught up yet. AI coding agents have moved past the hype phase and into the everyday workflow, some leaders are now encouraging their engineers to use AI to code for productivity gains. People are already leaning on tools like Copilot, Cursor, and Claude to push features at a pace that was once impossible. On the surface, that is a massive win for productivity. However, there is a hidden friction point. These agents might be experts at writing syntax, but they are completely blind to the specific constraints and nuances of your platform.
They don’t know you standardized on exponential backoff for retry logic. They don’t know every service needs those three security headers. They don’t know the naming convention your on-call rotation depends on. They just generate code, and they generate it fast, and by the time a PR lands for review, the decisions are already baked in.
This is the problem platform teams need to get ahead of. Not by slowing AI down. By giving AI something to follow.
Spec-Driven Development (SDD) is a methodology built around a simple premise which is to write the specification before you write the code. Not a wiki page. Not a Confluence doc nobody reads. A precise, structured, machine-readable spec that becomes the single source of truth for everything that follows.
GitHub recently released Spec-Kit, a toolkit that operationalizes SDD for AI-assisted development. At the center of it is a file called constitution.md. The idea is exactly what it sounds like: before any code is generated, you define the non-negotiables. The principles the AI cannot violate. The rules that apply to every feature, every implementation, every PR.
From the Spec-Kit docs: the constitution is the architectural DNA of the system, and it encodes things like auth requirements, compliance rules, and organizational standards so they apply automatically through gate checks before any implementation proceeds.
Read that again from a platform engineering lens. Auth requirements. Compliance rules. Organizational standards. That’s not just SDD. That’s your job description.
The Platform Team Is the Constitution
Here’s the reframe I want you to sit with.
Platform teams have always been in the business of encoding standards. The golden path, the paved road, the internal developer platform, all of it is really an attempt to answer the same question: how do we make sure engineers build things the right way without having to explain it every single time?
The problem is that most of the answers live in static places. A wiki. A README. A Slack message from six months ago. Engineers are supposed to read them, internalize them, and apply them when they build. That worked, imperfectly, when humans were writing every line.
It doesn’t work when an AI agent is generating a service in thirty minutes.
The solution isn’t more documentation. It’s executable documentation. A platform constitution that isn’t just written down, it’s enforced. A spec that the AI agent reads before it plans, before it generates, before anything gets committed.
What Goes In a Platform Constitution?
Think about what your platform team actually owns. Not in the abstract, but the concrete things that go wrong when product teams ignore them.
Security headers that get missed. Retry logic that’s inconsistent across services. Service names that break your observability tooling. Auth flows that get implemented from scratch instead of using the shared library. IAM policies that are too permissive because nobody remembered the standard.
Every one of those is a principle that belongs in a platform constitution.
A platform constitution.md might look something like this:
- Every service must include headers X, Y, Z
- All retry logic must use exponential backoff with jitter, max three attempts
- Service naming follows the pattern [team]-[service]-[env]
- Authentication must use the internal auth library, no custom implementations
- All new services must emit the standard observability events before merging
These aren’t suggestions. They’re gates. And when you give AI agents a constitution to work from, they become gates the agent checks itself, before a human even sees the code.
And here’s where it gets really powerful for platform teams: you can bake the constitution directly into your self-service templates.
When an engineer scaffolds a new service through your internal developer platform, the template they start from already has the security headers wired in, the retry logic stubbed out correctly, the naming convention pre-applied. The constitution isn’t something they read before they build. It’s something they inherit the moment they hit “create.” AI agents working from that template inherit it too. Compliance stops being a review step and becomes a starting condition.
That’s the difference between a standard and a spec. Standards ask engineers to remember. Specs make forgetting structurally difficult.
This Is Bigger Than Tooling
I want to be clear: GitHub Spec-Kit is still experimental. You don’t need to adopt it tomorrow. But the pattern it represents matters right now, regardless of which tool you use.
The question every platform team needs to answer in the next twelve months is: what happens to your standards when AI agents are writing half the code in your system?
The teams that will get ahead of it are the ones that stop treating their platform standards as documentation and start treating them as specifications. Living, versioned, enforceable contracts between the platform and everyone building on top of it.
Not a wiki page that is months out of date. A constitution.
—
The shift from “here’s how we do things” to “here’s the spec your agent must follow” is one of the most important moves a platform team can make right now. And this is because AI is going to make undocumented tribal knowledge very expensive, very fast.
Write the constitution before your agents start making assumptions.
