For a prototype, a few hours and a well-written brief are enough. For an application with dozens of screens, external data sources and daily use, they are not. An AI agent starts every new task without memory. It does not know why the data model looks the way it does, what we tried and dropped last week, or what must not change. That is why I work with a process I call Full Agentic Spec-Driven Development.
What I mean by it
It is a defined process for the whole project, not just for writing code. Next to the code, the repository holds documents that describe what we are building and why: architecture decisions, an implementation plan for each feature, its impact, risks and test design. The agent reads them first and only then touches the code.
The specification is not paperwork for people. It is context for an agent that would otherwise see only files and a chat prompt.
What sits in the repository next to the code
- Project description and rules – what the application is for, who uses it, what it runs on and what the agent must not do.
- Architecture – the main parts of the system, the data model and integrations with external services.
- Decision records – the situation, the decision and its consequences. Mainly for things that would otherwise be reopened a month later.
- Plan and feature status – what is done, what is in progress and what is waiting.
- Setup guide – how to run, configure and deploy the project.
- Tests – designed before the code is written.
How one feature is built
- Brief. I describe what the feature should do and why, in business language, without a technical solution.
- Analysis and proposal. The agent goes through the code and documentation and proposes a solution: what changes, what it affects, what the risks are and how we will test it. For larger changes I stop here and read the proposal. Coding starts only after I approve it.
- Decision. If the feature changes the structure of the application (data model, integration, deployment), a decision record is written.
- Tests and implementation. Tests first, according to the proposal, then the code.
- Verification and document updates. I check the result against the brief. The agent updates the plan, status and documentation as part of the same task, not as clean-up some time later.
What it solves for me in practice
Parallel work. I often run several threads on one project at the same time, for example the main application and a separate catalogue module. Without shared documents the threads know nothing about each other and overwrite each other's assumptions. A shared architecture and decision records keep them together.
Coming back after a break. When I return to a project after two weeks, I don't have to explain to the agent again why something works the way it does. The documents are enough.
Finding bugs earlier. Tests designed upfront catch problems that would otherwise show up in production. Especially with changes that look small at first sight.
Security. The project rules tell the agent what it must not do. I enter passwords, tokens and keys myself, directly in the admin of each service. They never end up in the chat or in the repository.
When I don't use it
Not for a quick prototype or a client demo. There, speed matters more than documentation, and the code is often thrown away. I switch the process on once it is clear the application will live for a long time and more people or more agents will work on it. This is how applications such as product comparison with competitors or custom reporting are built.
Documents also go stale. If updating them is not part of every task, within a few weeks they do more harm than good, because they describe a state that no longer exists.
How to start
Two files are enough: a project description with rules, and a list of decisions. In the first, write what the application is for, what it runs on and what is not allowed. In the second, record every decision you would otherwise have to explain again. Add the rest when you need it.
