When it is no longer the code but the specification that stands at the center, the question immediately arises what such a specification must look like so that an agent reliably builds code from it and a human can review it. A running text that circumscribes a goal is comfortable to read, but too vague for reliably generating code from it or deriving checks. A purely formal machine model would be the other extreme: precise, but heavyweight and hardly still suitable as a working tool for many of those involved. AIND deliberately positions itself in between: a structured language that an agent reliably implements and that a human still understands.

Specification with Structure, Instead of Prose

AIND gives the specification a fixed structure. A system is broken down into components, and each component holds four things together:

• Requirements: what the component is supposed to deliver, as verifiable statements.
• Assurances: which technical properties the generated code must fulfill.
• Decisions: which options were considered and why one was chosen.
• Supplementary artifacts on intent: purpose, boundaries, and domain knowledge of the application area; design documents such as UI designs, flow diagrams, data models, interfaces.

These building blocks are arranged by aspect and are each assigned to a responsible person. The specification therefore belongs to someone; it is not a running text without an owner. And it is verifiable, by the same principle as the reconciliation between assurance and code, only one level higher: do the requirements and assurances still cover what was wanted?

With this, the chain from need through requirement and assurance to code from the previous part has its fixed place: it is the structure of requirements, assurances, and decisions in which this chain is maintained. The specification does not serve documentation but becomes the working tool of development itself.

Readable for Humans and Machines

An AIND specification has two consumers. One is the agent, which generates code from it, selects context, or prepares checks. The other is the human, who needs to understand what was wanted, why a decision was taken, and whether the assurances still match the domain intent. From this follows a twofold requirement: the specification must be precise enough for the agent and comprehensible enough for the human.

The strength of AI lies precisely in the fact that it does not force us to translate everything into a hard-to-read machine format. An agent can work with structured language, i.e. with requirements, assurances, decisions, and explanations. But this language must not be arbitrary. It needs order, responsibilities, and clear relationships.

AIND makes use of exactly this room for maneuver. The specification remains reviewable by humans but is structured in such a way that an agent can process it. It is the common denominator for human intent and machine implementation. This is a decisive difference from earlier automation approaches, in which one often had to choose between documentation that is readable for humans and a formalized model. With AI, a hybrid form emerges that was previously scarcely viable: structured human language becomes a productive development artifact.

The Why Gets a Home

The real benefit, however, lies deeper. With this structure, the why of a system gets a fixed, versioned place. Code only ever says what a system does, but never why the system is built this way and not otherwise. Otherwise, this intent sits in the heads of developers, in chat histories, in emails, or in documentation that belongs to no one and therefore gets out of hand: outdated, incomplete, at some point ignored.

As long as humans wrote the code, this could be bridged after a fashion by reading the code and reconstructing the intent behind it. That was laborious, but possible. When the agent writes the code, however, the relationship is reversed: the intent is then the most valuable thing that humans possess, and the part that they do not delegate. Precisely for this reason, it must be maintained. Requirements, decisions, boundaries, rationales, and assurances get a home in the structured specification: ordered, versioned, reviewed, and tied to the code. The why is thus no longer fleeting knowledge, but a maintained artifact.

This helps not only humans but also the agent. The more clearly purpose, boundaries, and decisions are described, the better it can select the right context, generate suitable implementation proposals, and avoid working past the actual goal.

Why Not a Requirements Management System?

If requirements, decisions, and traceability are so important, why not simply store them in a requirements management system? Particularly from the perspective of the PLM world, where such systems have long existed, that is an obvious question. What speaks against it is that such a system is often over-dimensioned for small teams. Instead of having to license, operate, and maintain yet another tool, AIND provides structured and reviewed traceability with less effort and directly where development takes place. For developing with AI, it is decisive to have the why within direct reach during the development process, to avoid the drifting apart of requirements and code. That is easier with AIND than with an external requirements management system. Anyone who is already using such a system does not have to give it up, but can integrate it into AIND via a connector.

Interface Between Intent and Implementation

Why control passes to the specification when programming with agents was the subject of the previous part. This part has shown what such a specification has to look like: at once machine-processable and human-reviewable, close enough to the code not to become outdated, and rich enough in context to capture the why.

An agent-ready specification therefore describes not only what is to be built, but also captures why it is to be built, which assurances the code must fulfill, and which decisions have led to this form. With AIND, the specification becomes the interface between human intent and machine implementation.

The next part in this chapter leaves the internal structure of the specification behind and asks how it fits into existing development environments – where code, requirements, models, and product data already come into being today.