An AI agent updates a schema in Service A.
Tests pass. Code is clean. PR looks solid.
Three days later, two downstream services break. Service B still expects the old format. Service C’s tests passed, because they mocked the dependency.
The agent wasn’t wrong. It just couldn’t see beyond its own repo.
This is the problem nobody talks about at AI keynotes:
Most AI coding tools assume a monorepo. Enterprises run polyrepos. Separate services. Separate teams. Separate repos.
Your company has dozens of services across separate repos. Your AI agent sees one at a time. Locally correct. Globally destructive.
The fix is a layer above your repos
The fix isn’t a better model. It’s a meta-repository sitting above your codebases. It holds what agents actually need: API contracts, service relationships, architecture decisions, shared conventions. The repos stay independent. The agent finally gets the full picture.
But context alone isn’t enough. Agents still hallucinate implementation details. Still guess at acceptance criteria. They need structure, not just access.
Spec-driven development
That’s where spec-driven development comes in. No vague prompts. No guessing.
So instead of: idea → prompt → code → pray
Run: spec → impact analysis → test cases → work packages → code
Each work package is scoped to one repo, one agent, one session. Every decision is traceable. Every change is intentional.
This flips the entire review cycle:
- Old way: write code → review code → find problems.
- New way: write spec → review spec → find problems → then write code.
A schema mismatch caught in a spec costs minutes. Caught in deployed code? Days. Caught in production? That’s your weekend.
The bottleneck was never the AI. It was what the AI couldn’t see.
Originally posted on LinkedIn
Keep reading
AI won't end your career. Being one-dimensional will.Essay · 2 min