8 posts
Specs copy-paste the product on every increment, and coding agents paraphrase business rules into forks nobody decided. The fix is the same fix we applied to code decades ago: define the rule once, canonically, and make every spec cite it.
A real app shipped two different models of the same tax form. The strange part: its own spec folder both forbids and requires the same service, in one file. I replayed that mistake with Product Definition as Code in place to see if it would get caught. Here is what happened.
Andrej Karpathy's LLM Wiki and Product Definition as Code share a substrate: persistent, Git-backed, agent-friendly Markdown. But they establish fundamentally different contracts around truth, authority, semantics, and delivery. This article takes the comparison seriously.
AI-assisted delivery is probabilistic, but product boundaries do not have to be. Product Definition as Code provides a bounded product ontology before the backlog and the spec, while keeping runtime enforcement where it belongs: in the software.
AI accelerates software delivery and shifts the bottleneck to product thinking. I propose Product Definition as Code: a versioned graph of product artifacts that provides deterministic context to agents and humans before a single line of code is written.
Software engineering careers were built on the assumption that engineers create value by writing code. That assumption is collapsing. The new competitive advantage is understanding the entire engineering system. DevEx is becoming the critical discipline of the AI era.
While designing a vendor-agnostic AI architecture for repositories, I discovered the ecosystem is missing a fundamental standard: a shared discovery protocol for AI artifacts. The problem is not prompt engineering or package management. It is architecture.
Multiple AI coding agents in one repository create duplicated, drifting instruction artifacts. A canonical semantic layer solves the problem.