AI Workshop: From Idea to a Reviewed Engineering Task
A practical workflow for separating engineering, independent review and implementation when working with ChatGPT, Codex and AI agents.
AI coding agents are very good at doing work quickly.
That is also an easy way to get into trouble.
Give an implementation agent a vague request such as:
“Add this feature, work out how it should fit, test it and make sure everything is correct.”
and you have quietly assigned several different jobs to the same agent.
It must understand the problem, inspect the architecture, make engineering decisions, implement them, decide how to test them and finally judge whether its own work is correct.
For small changes this may be perfectly reasonable. For more complicated engineering work, I have found a more structured pattern useful:
separate engineering from independent review, and separate both from final implementation.
The workflow is:
IDEA → CONTROL ROOM → AI WORKSHOP → WORKER → REVIEWER → ENGINEERING COMPLETE → CODEX → TEST → VALIDATED RESULT
This is not the only correct way to work with AI agents. It is a practical pattern developed through real work to reduce ambiguity, context loss and unnecessary implementation-agent work.
The giant-prompt problem
Modern coding agents can inspect repositories, modify files and run tests. It is therefore tempting to give the agent the entire engineering problem.
But capability and responsibility are different things.
Before implementing a non-trivial feature, you may need to know:
What already exists?
Which components must remain unchanged?
Does the proposed feature duplicate existing functionality?
Which interfaces and prerequisites does it depend on?
What actually constitutes success?
Can the available test measure that success?
These are engineering questions.
If one agent answers all of them and immediately implements its own conclusions, one incorrect assumption can propagate through the entire task.
The resulting code may even pass every test.
It may simply have tested the wrong objective successfully.
1. Control Room
The Control Room decides what problem should be solved next.
It maintains the objective, constraints and sequence of work rather than implementing everything itself.
A task might begin like this:
OBJECTIVE
Add reliable configuration validation.
CURRENT TASK
Determine which configuration inputs already have validation.
DO NOT
Modify production code.
Redesign configuration handling.
OUTPUT
Existing validation.
Missing validation.
Smallest justified implementation task.
This prevents an investigation from silently becoming a redesign.
2. AI Workshop
The Workshop handles engineering before implementation is handed to the coding agent.
Instead of asking Codex to investigate, architect, implement and validate a poorly understood problem simultaneously, the Workshop prepares a bounded, reviewable engineering result.
For significant tasks I separate this into two roles.
Worker Agent
The Worker performs the engineering task.
It might:
Most importantly, it works against explicit acceptance criteria.
Reviewer Agent
The Reviewer has a different responsibility.
It does not simply continue the Worker's work. It attempts to determine whether the Worker actually solved the stated problem.
For example:
REVIEW
1. Does the result satisfy the objective?
2. Were the acceptance criteria tested?
3. Was anything outside scope modified?
4. Are claims supported by evidence?
5. Does the test measure the intended behaviour?
VERDICT
PASS
PASS WITH CONDITIONS
FAIL
The distinction matters.
A Worker naturally tries to demonstrate that its solution works.
A Reviewer should actively look for reasons why that conclusion may be wrong.
Git as persistent AI memory
Multiple AI sessions create another problem: context.
Chats end. Context windows change. Agents start fresh sessions.
A Git repository provides a simple persistent engineering state.
For example:
AI-WORKSHOP/
├── AGENTS.md
├── policies/
├── agents/
│ ├── WORKER.md
│ └── REVIEWER.md
├── projects/
├── tasks/
├── evidence/
├── reviews/
├── checkpoints/
└── status/
AGENTS.md defines operating rules.
tasks/ contains bounded tasks.
evidence/ contains test results.
reviews/ contains independent reviews.
checkpoints/ preserves accepted decisions.
status/ records current state.
The exact folders are not important. The principle is:
Conversation is temporary. Accepted engineering state should be persistent.
A new agent can inspect the repository instead of reconstructing the project from thousands of lines of conversation.
Give every task a finish line
Compare:
Improve the application's reliability.
with:
Determine whether malformed YAML configuration
is rejected before application startup.
ACCEPTANCE
- valid configuration still loads;
- malformed YAML is rejected;
- missing required fields are rejected;
- existing behaviour remains unchanged.
Do not modify unrelated code.
Stop after tests pass or an exact blocker is identified.
The second task tells the agent when it is finished.
Without a finish line, agents can continue finding interesting improvements indefinitely.
That is useful during exploration and expensive during implementation.
Evidence beats confidence
I try not to ask an agent:
“Are you sure it works?”
I prefer evidence such as:
NEW TESTS: 14 passed
REGRESSION: 38 existing tests passed
FILES CHANGED: validator.py, test_validator.py
PROTECTED FILES CHANGED: none
BLOCKERS: none
A confident explanation is not validation.
A reproducible test is much closer to it.
This also makes independent review easier because the Reviewer has concrete evidence to challenge.
Compile the conversation before Codex
This is one of the most useful parts of the workflow.
ChatGPT is excellent for exploration.
You can discuss architecture, challenge assumptions, compare alternatives and discover that the original task was wrong.
But Codex does not necessarily need that entire conversation.
Ten thousand words of engineering discussion may eventually produce a task that can be expressed in a few hundred words.
Send the few hundred words.
For example:
OBJECTIVE
Implement the reviewed configuration validator.
VERIFIED STATE
Parser already returns structured configuration.
Validation currently occurs after subsystem startup.
ALLOWED
validator.py
test_validator.py
PROTECTED
parser.py
runtime.py
IMPLEMENT
Run the reviewed validator before runtime initialization.
VALIDATE
Existing regression tests.
Malformed-input tests.
Valid configuration regression.
STOP
Stop after PASS or report the exact blocker.
The implementation agent now has less ambiguity.
Its capacity is being spent on implementation rather than rediscovering engineering decisions that have already been made.
A small example
Imagine a Python application needs exact duplicate-file detection.
The original request is:
Add duplicate detection.
The Control Room first converts this into a bounded engineering problem:
Determine the smallest safe method for detecting
exact duplicate files without modifying source data.
The Worker inspects the application and proposes SHA-256 hashing.
It prepares tests containing identical and different files.
The Reviewer discovers that the first implementation incorrectly includes filenames in the comparison logic.
The Worker corrects it.
The Reviewer passes the result.
Only then does the implementation agent receive:
Implement the reviewed SHA-256 duplicate detection.
Do not modify input files.
Do not add near-duplicate detection.
Preserve existing scan behaviour.
Run the supplied regression tests.
Stop after PASS or exact blocker.
Codex is no longer being asked to invent the engineering solution.
It is executing a reviewed engineering unit.
Do you need all these agents?
No.
Fixing a typo does not require a Control Room, Worker, Reviewer and engineering checkpoint.
The structure becomes useful when a task has:
architectural consequences;
uncertain requirements;
expensive implementation-agent usage;
important existing behaviour;
multiple dependencies;
or a meaningful risk of implementing the wrong solution.
The roles also do not necessarily require different AI models.
Worker and Reviewer could even use the same model in separate contexts.
The important separation is responsibility, not the number of tools.
The practical lesson
AI coding agents make implementation dramatically cheaper.
That makes deciding what should be implemented more important, not less.
My working pattern is therefore:
IDEA
↓
CONTROL ROOM
↓
AI WORKSHOP
↓
WORKER
↓
REVIEWER
↓
REVIEWED ENGINEERING RESULT
↓
IMPLEMENTATION AGENT / CODEX
↓
TEST
↓
VALIDATED RESULT
The objective is not to create bureaucracy around AI.
It is to spend each tool where it provides the most value:
Use conversation to resolve ambiguity.
Use engineering agents to develop and challenge solutions.
Use implementation agents for bounded implementation work.
Use tests and evidence to decide whether the result is actually complete.
And preserve important engineering state somewhere more durable than the chat that created it.
