The AI driven workflow

How a team of BrSE, developers and QA works when agents do the first draft of everything

At a glance

• Roles covered: BrSE, QA, developer, designer, translator
• Shape: One plugin per role, installed separately
• Status: QA in daily use, the rest rolling out

1. AI ready spec
2. Normalise once
3. Test cases first
4. Build to the cases
5. Bug closes the loop

A bug that escapes becomes a new test case, which sends the loop back to step three.

What was wrong before

The old process cost days per feature

Two numbers from our own measurements, not from a vendor deck.

• QA spent about two days writing integration test cases for one feature
• Developers spent about one more day executing unit tests by hand

Testing always started too late

Test cases arrived after the code, so they could not shape it.

• Developers finished a feature before integration test cases existed
• Anything a developer generated alone was thin, and the bugs surfaced later in QA where they cost more to log and route

Everyone worked from a different document

The quiet failure that produces the most rework.

• Developers and QA regularly used two different versions of the basic design
• Each side generated its own AI summary of the spec, so the two drifted apart before a line was written

The steps

Write the spec for a machine, not only for a person

The document is the input to everything downstream, so it has to be readable by an agent.

• New projects write the basic design in Markdown and keep it in git, so history is explicit
• Change requests follow a fixed ticket template instead of free prose

Normalise the spec once, centrally

One normalised version, produced once, used by every role.

• The spec is checked against internal conventions before anyone builds on it
• A spec that fails the check goes back to the author rather than forward into code

Generate the test cases before the code exists

This is the step that inverts the old order, and it is the one that matters.

• QA generates integration test cases from the normalised spec and reviews them
• The reviewed cases are merged into a shared registry and become the reference point for the whole feature
• From then on, new features, change requests and bug fixes all update the registry first

Build against the test cases, not against an interpretation

Developers pull the cases directly rather than reading the spec again.

• An MCP server exposes the registry so the agent fetches cases in one hop
• Code has to satisfy every case in the registry, not a developer's reading of the spec
• End to end tests are generated and executed before handover, with skipped cases explained in writing

Close the loop when a bug escapes

A bug is treated as a missing test case, not only as a defect.

• QA still tests by hand, because generated coverage is not proof of quality
• If the bug slipped through because a case was missing, the case is added to the registry
• The fix then regenerates automated tests, so spec, cases, code and tests stay tied together

Principles

Prompt instead of operate

People move from producing the output to supervising it.

• Agents draft the spec, the design, the code, the cases and the reviews
• The human job becomes judging results and improving the agent for next time

Optimise every artefact for the agent

If an agent is in every step, the formats should suit an agent.

• Markdown and JSON over spreadsheets
• Git over shared drives, because history is part of the input
• A purpose built MCP server over telling an agent to go and find the data itself

Limits

• It needs real budget. In practice one paid agent account per person, which rules out teams that cannot fund it.
• It needs the freedom to choose your own process and output formats. If the client dictates both, most of this cannot be applied.
• It is built on one vendor ecosystem. Teams standardised on a different agent toolchain would have to rebuild the tooling.
• Agents tend to defend their own output. Ask one to check its work and it will often justify rather than find the fault.
• Generation is not deterministic. The same spec produces a different set of test cases on a different run, which is why human review before merging is mandatory.

Why write this down

Most teams using AI are using it privately. One developer has a good prompt, one QA has another, and nothing that works for one person survives to the next project. The output quality swings by who is at the keyboard.

The process on this page exists to fix that specific problem. It is not about individual prompting skill. It is about making a team produce consistent output regardless of who runs the task, by fixing the inputs, the formats and the order of the steps.

What actually changed

The single most important change is the order. In the old process, code came first and test cases described it afterwards. Now the test cases come first and the code is built to satisfy them. Everything else in the process exists to make that inversion possible: a spec an agent can read, one normalised copy of it, and a registry the developer's agent can reach without a human relaying it.

What I would tell you before you copy it

Start with the registry, not with the tooling. The plugins are replaceable. The part that carries the value is having one agreed set of test cases that every role reads from and writes back to. A team can get most of the benefit with that alone, and no team gets the benefit from tooling without it.

Questions people ask

Does this replace QA engineers?

No. It moves them earlier. QA now defines the acceptance criteria that development is built against, and still tests by hand afterwards. What disappears is the two days of typing, not the judgement.

How do you stop the agent from inventing test cases?

You do not, entirely. That is why nothing enters the shared registry without a human review, and why the registry lives in git with pull requests rather than being written directly by an agent.

What was the actual gain?

The largest is not speed, it is that testing moves in front of coding. The measurable part is the two days of test case writing and the day of manual unit test execution per feature that the old process required.

Can this be applied to my project?

It depends on three things: whether the team has agent budget, whether you control your own process, and whether the deliverable formats are yours to choose. If any of those is fixed by someone else, expect to apply parts of it rather than all of it.