AI-Assisted Development Workflow: From Requirement to Code

The Pipeline at a Glance

Most teams treat AI coding as a chat window bolted onto their normal process. You open a file, type a prompt, paste the result, and hope the model guessed the conventions of the forty files it never saw. That works for small, local edits and falls apart the moment a feature spans a controller, a handler, a view, and a lookup table. The alternative is to stop prompting ad hoc and run a pipeline instead — a fixed sequence of artifacts where each phase is owned by either a human or the model, and nothing moves forward until a person signs off.

The pipeline has six phases:

1. Engineering rules — the authoritative technical standard that governs every generated file.
2. Data dictionary — the single hand-written file that describes the application.
3. Feature requirements — the business source of truth derived from the dictionary.
4. PRD — the build-ready technical blueprint, including a traceability matrix.
5. AI implementation — build feature by feature, keeping the solution compiling.
6. Human review — read the diff, run the app, and verify behavior.

The rest of this article walks each phase in order, using a real ASP.NET Core application — an Asset Manager — as the running case. Asset Manager is an example application used to demonstrate the workflow; it is not the Indotalent webstore.

Phase 0: Engineering Rules

Before the model writes a single class, it needs to know the standard it is being held to. In this workflow that standard lives in a skill file, SKILL-SOFTWARE-ENGINEERING.md, and it is authoritative: when a generated file and the skill file disagree, the skill file wins.

The skill file encodes the conventions that make AI output predictable instead of plausible:

• One entity, eighteen-plus files. A single entity class expands into a Controller, CQRS handlers, Minimal API endpoints, Razor views, and collocated .cshtml.js files, all generated together.
• Read first. The model must read the canonical reference implementation in full before writing anything. In the starter those references are Country (Pure Master), Currency (Master with Lookup), and Todo (Master-Detail).
• Entity type detection. A Pure Master has no foreign key and no collection; a Master with Lookup carries a string {X}Id plus a {X}? {X} navigation; a Master-Detail exposes ICollection<T>? Items.
• AutoNumber is mandatory. Anything that needs a human-readable key implements IHasAutoNumber with the format {ToShortNameConsonant(3)}/{Year}/{4-digit}, producing values like PRD/2026/0001 or TOD/2026/0001.
• Soft delete only. Rows are never physically removed. Deletes flow through the global query filter, which means never writing !x.IsDeleted in a query and never calling .Remove().
• CancellationToken everywhere. Every CQRS handler and every Minimal API endpoint accepts and forwards a CancellationToken.
• Validation. FluentValidation is preferred over data annotations, and endpoint routes end with the entity name — for example /api/{entitylower}/{lookupentitylower}-lookup.

Phase 1: The Data Dictionary

This is the only file the developer writes by hand, and everything else in the pipeline is derived from it. That is what keeps the workflow honest: if a requirement is not in the dictionary, the model has no license to invent it. The file is .ai-assisted/DATA-DICTIONARY.md.

The dictionary records the application name and short name, the personas the app serves, and the feature list. Each feature carries a Group to SubGroup taxonomy and a Stage enum. The personas are Admin (the existing Admin area, unchanged), Main (all new features, available to the Admin and Member roles), and Guest or Self Service (optional, and able to see only its own data).

A trimmed entry for the Asset Manager example looks like this:

Application Name : Asset Manager
Short Name       : AM
Personas         : Admin, Member, Guest

Feature          : Asset Model
  Group          : Asset
  SubGroup       : Model
  Stage          : AssetStage

AssetStage: ReadyToAssigned -> Assigned -> Repair
            -> Quarantine -> Missing

The Group to SubGroup taxonomy is not decoration. It drives menu placement, permission grouping, and the folder naming the model will use later, so an inconsistent taxonomy produces an inconsistent application. The Stage enum gives lifecycle-heavy features — assets, tickets, orders — a shared vocabulary for status that generated lists, filters, and badges can all rely on. Asset Manager's own entities (Branch, Department, Manufacture, Vendor, Depreciation, AssetModelGroup, AssetModelSubGroup, AssetModel, Asset, Employee) are the kind of feature set the dictionary is designed to express.

Phase 2: Feature Requirements

On a fresh project, FEATURE.md is intentionally empty. It is generated, not authored, and the model fills it by reading the data dictionary. The ordering matters: the requirements document is a projection of what the developer declared, not a second place to quietly add scope.

FEATURE.md is the business source of truth. It describes what each feature does in domain language — the entities, their relationships, the lifecycle, the actors — without committing to controllers, tables, or endpoints. If you have ever watched a backlog drift away from an implementation, this file is the anchor that stops it. Every later artifact traces back to a line in the dictionary and a section here.

Because the dictionary already fixes the Group, SubGroup, and Stage for each feature, the generated FEATURE.md can describe the Asset lifecycle in exactly the terms the domain uses: an asset becomes ReadyToAssigned, then Assigned, then possibly Repair, Quarantine, or Missing. No translation step, no invented status names.

Phase 3: The PRD

The next phase turns the business description into a technical blueprint. ORCHESTRATOR.md runs PROMPT.md, which drives the model to produce PRD.md. Like FEATURE.md, PRD.md starts empty and is generated — and it is never run as a standalone step.

The PRD is where abstract requirements become concrete: entity definitions with their detected type (Pure Master, Master with Lookup, or Master-Detail), the AutoNumber prefix, the endpoints, the views, and the relationships between features. It also carries a traceability matrix that maps each requirement back to the feature that satisfies it. That matrix is what lets a reviewer answer "did we build what we said we would build?" without reading every generated file.

Phase 4: AI Implementation

With the blueprint in place, the model builds feature by feature. The order is deliberate — Pure Master first, then Master with Lookup, then Master-Detail — because each level depends on the one before it. A Pure Master like Country teaches the model the shape of a complete slice. A Master with Lookup like Currency reuses that shape and adds a foreign-key pattern. Only when both are in place does a Master-Detail feature like Todo make sense, because it composes the previous two.

After every feature, the model runs dotnet build and fixes every error until the build is clean. It does not batch a dozen features and compile once. One feature, one build, zero errors — that cadence keeps the failure surface small enough that a mistake is always attributable to the last change.

$ dotnet build
Build succeeded.
    0 Warning(s)
    0 Error(s)

Because the skill file fixes the entity-to-file mapping, a single entity class reliably becomes a full vertical slice following the same shape as the reference implementations. That consistency is what makes the output reviewable by a human instead of merely impressive to a demo.

Phase 5: Human Review

The build is not the finish line. The reviewer's job starts where the compiler stops: read the diff, run the application, and exercise the behavior. A clean build says the code is internally consistent. It does not say the lookup dropdown returns the right rows, that the AutoNumber resets properly in January, that the soft-delete filter hides the record from every list, or that the Stage transition you asked for is the one that was implemented.

Treating review as optional is the fastest way to turn a promising workflow into a liability. The pipeline is built around the assumption that a person owns the outcome, and every gate is a place where that ownership is exercised.

The start the development Command

All of this collapses into a single instruction. The developer writes .ai-assisted/DATA-DICTIONARY.md, then tells the agent: start the development. The README is unambiguous that ORCHESTRATOR.md, PROMPT.md, and PRD.md are never run as separate manual steps — the orchestrator sequences them.

The first thing the orchestrator does is Gate 0. It checks AppSettings:Name in appsettings.json. If the value is Indotalent, it proceeds. If it is anything else, it stops, because a customized application is in maintenance mode and should not be regenerated. This is a small check with a large effect: it guarantees the pipeline is never pointed at a project that has diverged from the template.

After the gate, the orchestrator reviews the dictionary, generates FEATURE.md and then PRD.md, and enters the build loop. One command, six phases, and a human gate at every step that matters.

Key Takeaways

• Write DATA-DICTIONARY.md; let everything else be generated.
• FEATURE.md is the business source of truth; PRD.md is the technical blueprint with a traceability matrix.
• Build Pure Master, then Master with Lookup, then Master-Detail, with a clean dotnet build after each feature.
• The build is the verification ceiling — a human still validates runtime behavior.
• Run the whole thing with one command, start the development; never run the phases by hand.