Two Hundred Engineers, Two Hundred AI Setups

An engineer at a 500-person SaaS company walked me through his AI setup last quarter. CLAUDE.md in every repo. A prompts/ folder with thirty-seven markdown files. A custom shell wrapper that read which directory he was in and injected the matching product context. A small harness that pulled definitions from the team's Confluence into Claude Code. He showed me all of it because he was proud of it. He should be – it's good work, and his velocity is real.

Then I asked him: how many other engineers at the company have something like this?

He didn't know. Probably most of them. Probably all different.

It's not a one-off. Every time I've seen AI tooling running at scale – at SaaS companies, at enterprises – the shape is the same. The details vary. The pattern doesn't. Two hundred engineers, each running their own version of the same thing. None of it shared, none of it audited, none of it durable. When that engineer takes another job, his AI workflow goes with him – his prompts, his harness, the accumulated decisions about how to talk to AI tools about this product. All of it leaves in a laptop bag, and the next senior hire spends three months rebuilding it.

That's what's actually happening at most Fortune 1000 non-tech companies right now. It isn't on a slide deck. It isn't in the CIO's plan. It's the AI posture you have whether you wrote one down or not – and increasingly, it's the answer you owe when the board, the CIO, or the audit committee asks how AI is governed at the company.

This piece is for the people who own that problem – VPs of Engineering, Heads of Platform, Heads of Developer Experience. The engineers building their own AI scaffolding aren't doing anything wrong. They're doing exactly what they should be doing given what they have. The question is what to do at the org level so what works for one engineer keeps working when there are five hundred of them.

At five engineers, the personal-prompt-library model works. Everyone knows everyone. If Marco writes a sharp pricing.md for the billing service, it's in everyone else's repos by Friday. Slack carries the context. The team holds the product in its collective head, and AI tools work fine because the humans are still doing the integration.

At fifty engineers, the cracks show. Marco's pricing.md is now in nine versions across five squads. The platform team has its own. The mobile team has theirs. When the pricing model changes – and it always changes – six of the nine don't update for weeks. Engineers hit each other's stale context and don't know it. The AI generates code that looks correct against an old definition. The PR ships. Production catches it three sprints later.

At five hundred engineers, the model has stopped meaning anything. Every onboarding engineer rebuilds context that already exists somewhere. Every prompt is a fork of someone else's prompt. Every agent harness is a slightly different hand-rolled MCP client. Nobody can answer the basic governance questions. Who decided what "active subscriber" means for AI-generated code? Where does that definition live? Who's allowed to change it? 

In most enterprises, the answer is some version of "I'd have to ask around."

This is the part that doesn't scale. Not the AI tools – those are fine. The scaffolding underneath them. Engineers built it on laptops, in personal Notion pages, in team wiki spaces, because nobody gave them anywhere else to put it. They built it because the work needs it. The same way shadow IT happened in 2010, AI scaffolding is happening now. The fix isn't to take it away. The fix is to give it somewhere governed to live.

Four words for what AI artifacts at scale need to be. Every enterprise engineering org I've talked to nods at all four and has none of them.

Repeatable. Two engineers in two parts of the codebase, working on related features, ask their AI tool the same question about the product. They get the same answer. Today, in most enterprises, they don't. One has a stale .md from January. One has a fresher version from April. One has nothing and is going off the Jira ticket title. The AI generates three subtly different implementations of "subscription renewal," and the deltas don't surface until something breaks in QA.

Updated. When the product manager decides "active subscriber" now excludes paused accounts, that change has to propagate. Not as a Slack announcement nobody reads. Not as a wiki edit that doesn't reach the AI tools. The next AI session – anyone's – uses the new definition. The engineer doesn't have to remember to refresh anything.

Controlled. Product Knowledge doesn't live in scattered files where changes are impossible to track. When a definition changes, you can see what changed, who changed it, and when. If an update isn't right, it can be corrected or undone. Both the knowledge itself and what gets built from it remain traceable over time.

Permissioned. Shared knowledge needs clear stewardship. Not everyone is responsible for maintaining Product Knowledge. Permissioned means there are designated owners responsible for keeping the Glossary accurate, evolving it as the product changes, and managing how contributions are made over time.

These four aren't a feature list. They're the bar. Anything underneath enterprise AI use that doesn't meet all four is a future incident, and probably a future audit finding. Engineers running personal scaffolding meet zero of them. Not because they're doing it wrong – because they can't meet them alone.

Atono sits alongside Jira or Linear. Engineers don't change their workflow. The PM doesn't move tools. Atono adds one layer underneath what you already have – the layer that holds the product context AI tools need to produce specs and stories that match your product. Think of it as infrastructure, not a product. Plumbing under the existing stack.

The Glossary captures how your product works – the terminology, workflows, permissions, features, and relationships that define it. Authored, versioned, owned. When the product manager changes a definition, the change is in the Glossary, not in someone's .md. The Glossary is repeatable because everyone reads from the same place, updated because changes propagate from a single edit, controlled because changes are tracked, traceable, and reversible, and permissioned because contribution is managed rather than open to everyone.

Through Atono's MCP server, AI tools can retrieve the same product knowledge from a single source – the terminology, workflows, permissions, features, and relationships that define the product. The engineer in squad A gets the same understanding of the product as the engineer in squad B, without either maintaining local definitions, prompt libraries, or markdown files.

The same MCP server also provides the work context the Glossary doesn't: stories, bugs, and the AI Context attached to them. Claude Code, Cursor, Copilot, internal agents – any connected tool can retrieve the story it's working on, read the design decisions and technical investigation the team has captured, and write back what it changed. Every action attributed to the engineer who triggered it. Every update versioned.

Decisions and intent live on the stories themselves, captured during authoring and carried through to engineering via AI Context. The prompt library – the Glossary – is now infrastructure. The work history – AI Context – is now durable.

Nothing displaces. Everything connects.

A note on how we know this matters. When we evaluated AI-generated stories against our Glossary, 60% needed changes. That's our internal dogfooding – Atono using Atono on Atono's work. AI builds what you tell it to build. Give it better context, and you get better outcomes. The failure mode is consistent: almost right is worse than wrong. Wrong gets caught in review. Almost right gets shipped, and you find it later – usually in production, usually under load.

Three things change for an enterprise engineering org that puts a governance layer over the AI scaffolding engineers are already building.

Developer Experience improves because engineers stop being responsible for maintaining their own context infrastructure. The personal prompt library was never the work. It was the cost of doing the work. When that cost goes to zero – when context shows up in the AI session because the org maintains it centrally – engineers spend their time on the actual code. Onboarding gets shorter. Senior engineers stop being the only ones who can ship reliably against an AI tool.

Cost goes down because parallel work stops. Two hundred engineers writing two hundred versions of the same pricing.md is two hundred engineer-hours every time pricing changes. Centralizing that into a Glossary edit by a single owner is the difference between a recurring tax on the entire org and a single decision in one place.

Governance becomes possible because the artifacts AI tools depend on now sit in a place you can audit, version, permission, and own. Compliance can answer questions it couldn't answer before. Security can see what context flows into which AI session. When the board asks how AI is governed at the company, the CTO can point at a piece of infrastructure – not describe what two hundred engineers are individually doing.

Smart engineers are already building this. They're building it on laptops, in repos, in personal Notion. The work is good. The placement isn't.

Atono is the place to put it.

Next read: the 60% one-pager. Two pages on what we found when we ran our own Glossary against AI-generated stories. No form. The full governance brief follows shortly after.