Process
How I ship — a spec-driven workflow for AI coding agents
I built a workflow that cuts a Figma file and a business analysis into small feature packs, then has an AI agent implement each one under architecture rules it cannot renegotiate. I use it on my own projects and taught it to other developers.
Why I built it
Ask an AI agent to build the orders module and you get code that looks plausible and matches neither the design nor the business rules. Every session also invents its own architecture, so the tenth feature does not look like the first.
The model is rarely the problem. The input is. A whole Figma file and a long analysis document are too big and too vague to implement from, for an agent or for a person.
So the workflow does two things. It cuts the project into pieces small enough to leave no room for guessing, and it gives the agent rules that stay the same from the first feature to the last.
Stage 1: from design and analysis to feature packs
Pull the Figma file as JSON
A script calls the Figma API and saves the raw file.
Reduce it to a spec
A second script keeps what a backend needs to know (screens, fields, flows) and drops the drawing data.
Split by actor
Customer, provider, representative, admin. The Figma spec and the business analysis are both split, so each actor has its own screens file and its own business file.
Split each actor into features
Three separate agent runs with one job each: scan and index, extract the fragments, build the packs.
A feature pack per feature
Screens, business rules and an execution prompt, in one numbered folder.
A feature pack holds three files:
- The screens of this feature, as a fragment of the Figma spec.
- The business rules of this feature, as a fragment of the analysis.
- An execution prompt: what to build, which features it depends on, and where each requirement comes from.
Two rules are written into every pack. When the design and the business analysis disagree, the business analysis wins. And the agent may not invent a business rule that is not in the pack. Every field and rule carries a tag saying whether it came from the analysis or from the design.
Stage 2: implementing a feature
The project itself carries the rules. I call the main file the constitution. It is about 1,500 lines and fixes the things that should never vary between features: layering, naming, the shape of DTOs and requests, the response envelope, translations, API documentation, query performance and seed data.
One decision is taken once per project and then locked: whether the code uses a repository layer or a leaner path from service to model. The agent asks on the first feature, records the answer and never asks again.
To build a feature I name its folder and say “execute”.
Read the pack and the constitution, then open a branch
Build in a fixed order
Migrations, enums, DTOs, repositories, services, requests, resources, controllers, routes.
Sync the API collection after every endpoint
The work does not continue until the request exists in the shared collection.
Admin screens, translations, feature tests, API documentation
Run the quality gate
A checklist of about 25 items. Every unchecked box is fixed before the feature counts as complete.
Commit, push and open a merge request
The pack then moves to a finished folder, so the list of open features is always the list of remaining work.
The same folder name with the word “review” starts a different mode. The agent compares existing code with the pack and the constitution, refactors what breaks the rules and generates whatever is missing. That makes the workflow usable on a project that is already half built.
What I added on the latest project
On Al-Kout I kept the feature packs and changed how the work is driven.
- Delivery cycles. Features are grouped into cycles. Each cycle starts with a planning agent that writes a plan: the shared entities, the state machine, the order of pull requests, an acceptance scenario and a list of questions for me. I answer all the questions in one go, before any code is written.
- Separate agents for planning, implementing and reviewing. No agent reviews its own work.
- Triage before code. A pack that describes a navigation shell or another screen-only feature is classified as a frontend reference, and no backend code is written for it.
- One register for deferred work. Every agreed deferral has an identifier, a reason and a description of what remains. The agent may not record an approval I did not give.
- Skills. Thirteen small, reusable procedures such as generating a DTO, creating a repository or reviewing an endpoint.
Where I stay in the loop
Two rules matter more than the rest:
- A question the plan does not cover stops the work. The agent asks. It does not assume.
- Nothing is merged without my explicit decision.
Beyond those, the division is simple. I choose the architecture and write the rules. I answer the business questions. I review each pull request and run the full test suite myself. The agent does the typing, in an order that does not change.
What it has produced
- Msane, the first full project built this way: a B2B marketplace delivered in about seven and a half weeks with one backend developer.
- Al-Kout: 123 feature packs across three kinds of user, delivered in eight cycles over four weeks, with about 1,800 test methods.
- I taught the workflow to other developers, who went on to use it on their own projects.
What it does not solve
Speed moves the bottleneck. Review becomes the slow step, and it has to stay careful. External integrations such as payment gateways and SMS providers still wait on accounts, credentials and testing against the real service. And code that is correct in a test suite still needs to be verified against a real database under concurrent load.