The spec is the new source code

For decades, the constraint on enterprise data work was engineering capacity. Business teams described what they needed, and engineers translated those requirements into code.

Coding agents have changed the status quo. When implementation becomes abundant, the bottleneck moves upstream: can you describe business rules precisely enough for an agent to build with all the right assumptions baked in?

How agents “handle” business ambiguity

At “Your Data Stack is Going Agentic”, a data developer meetup hosted by Maxa in Montreal, Mathieu Di Mercurio, COO of Aviron, framed the shift as a question of population: billions of people can write text, while only a fraction of them can write software.

His example was the twenty-five people in Finance who already know rules like: “when an invoice is received at this address, use this GL account.” Give that rule to an agent and it can produce working code.

But enterprise data systems are rarely governed by one rule from one person.

Finance might count a customer one way for commissions and another way for the board. Revenue Operations might own a different account hierarchy. A legacy exception might still apply to historical revenue even though nobody remembers why.

Give this tangle of business logic to an agent and it still produces working code.

An agent has to resolve contradictions somehow. It picks an interpretation and keeps building, and usually doesn’t announce the judgement calls it makes. The number renders and the mismatch may not surface in a report until months later.

The description you hand the agent determines which system you get.

Why not just build and iterate?

Writing a specification before building assumes fully-formed knowledge waiting to be written down clearly enough.

For most product software, users learn what they need by seeing a prototype. A feature, or logic, within a prototype survives contact with reality or it gets replaced. Specify everything up front and the team gets very good at building the wrong thing precisely. Agents sharpen the objection: implementation got cheap enough that running three versions beats debating a document.

That reasoning holds while the correct behavior is still under investigation. It stops holding when the rules were settled long ago: payroll calculations, tax rules, protocol implementations.

Enterprise finance and ERP logic sits in the second group, because the knowledge already exists.

The knowledge already exists, now how do you capture it?

Which GL account an invoice hits is hardly a hypothesis waiting for user feedback. Someone in Finance already knows. The same goes for which accounts roll up to the same parent, which system wins when two of them disagree, etc.

The answers exist, scattered across people, spreadsheets, Slack threads, ERP configuration, and the memory of an ex-employee. See: Before you work with a coding agent, talk to Robert.

Enterprise data work is primarily an extraction problem. Where extraction runs out, it becomes a decision problem.

Some rules are settled and undocumented: Finance knows the GL treatment and always has. Others were never settled at all, because two teams have used the same word differently for years and nobody has been asked to adjudicate.

Endlessly building and iterating resolves neither scenario.

Being wrong is still expensive

Cheap feedback depends on wrong being visible, but a wrong number can look exactly like a right number when it renders in the dashboard, sits in the board deck, and stays there for two quarters until flagged.

Fast iteration needs a signal to iterate against, but coding a data pipeline can lead to quiet, undetectable failure. So the spec has to be right going in.

Requirements gathering is the beginning of work

"We need revenue reporting by segment" is a requirement, and also the start of a dozen decisions. The real work has always happened in those follow-up questions.

A spec systematically captures the definitions, the exceptions, and the open choices in one place for follow up with business stakeholders before passing to coding agents.

The spec becomes the durable artifact

Once definitions, exceptions, and open decisions are resolved, the spec becomes the record of business rules and logic.

While implementation will keep changing, and agents may generate the same logic in a different stack next year, business rules will carry forward.

In an agentic stack, the durable artifact is the spec.