Build
The definition doc is done. Now it gets built.
Development at Systeric is AI-first. The target is 80% AI-generated code. 100% is better. The definition doc you produced in Define exists precisely for this: it is the prompt. Its quality determines how fast and how cleanly Build goes.
The engineer's job is not to write code. It is to drive the AI to implement correctly and to make sure the output is right: right structure, maintainable, extendable, following the standards we have. You direct the AI, evaluate what it produces, catch what it gets wrong, and guide it to better solutions.
For PM: your job during Build is to protect velocity — be present and useful without being in the way.
Engineering: Driving AI Implementation
What's expected: The engineer uses the definition doc as the primary prompt. AI produces the implementation. The engineer reviews, validates, and corrects. The ratio of AI-written to human-written code should be as high as possible.
What good looks like: The engineer feeds the full definition doc into the AI with relevant codebase context. The output is reviewed against the doc for correctness, against the codebase for consistency, and against standards for structure. Corrections are made by prompting further, not by rewriting manually. The result is code that someone can read, extend, and debug six months from now.
How to get there:
Prompt from the definition doc. Feed it in full. Add context about the codebase structure, the patterns we follow, the adjacent code that should be consistent. The more context the AI has, the less you need to correct.
Validate the output against three things: does it do what the doc says? Is the structure consistent with the rest of the codebase? Does it handle the edge cases documented? If any of these are no, prompt again — don't fix manually unless it's a small detail.
Own the standards. AI will produce code that works before it produces code that's right. Working and right are not the same. Right means: consistent with our patterns, structured so the next feature is easy to add, not just the current one.
Tools:
- OODA loop — Observe, Orient, Decide, Act. Useful frame for the iterative prompt-review cycle. You're constantly observing what AI produced, orienting against the standard, deciding what's wrong, and acting by prompting again.
- Ladder of inference — when reviewing AI output, be careful about jumping to "this is wrong" from surface observations. Trace the reasoning: what did it do, why did it do that, is that actually a problem?
PM: Protecting Velocity
What's expected: PM is available and responsive. Decisions get made fast. Changes are surfaced immediately, not absorbed quietly.
What good looks like: When the engineer or AI-assisted process surfaces a question — about behavior, edge cases, priority — it gets answered the same day. When something changes, the release plan reflects it within 24 hours. No one is surprised at the end of Build by things PM knew mid-Build.
How to get there:
Answer questions fast. Unanswered questions either block or get resolved with a guess. Neither is good. Same-day is the baseline, same-hour is better.
Make decisions with confidence. Edge cases will come up that weren't in the definition doc. Make a call and explain the reasoning. Don't defer back to another meeting.
Raise changes early. If a requirement changes — from client feedback, new information, a realization in review — say it immediately. Discuss the impact with the engineer and update the release plan.
When Things Change
Something material will change. A dependency will slip. A client will revise a requirement. A design will turn out to be infeasible.
When this happens: say it immediately, to the engineer and to leadership. Update the release plan. Adjust milestones. If the change is significant enough to affect the story, loop in PD as well.
The release plan is not a contract. It's a shared understanding of what's happening. A plan that reflects reality — even when that reality is "we're two weeks behind" — is more useful than one frozen at the original intent.
What to Watch For
The engineer is quiet for too long. Check in: not "how's it going" — "what's blocking you right now?"
The scope is drifting. Features that weren't in the definition doc are appearing. These should be explicit decisions, not quiet additions.
The milestone is approaching and it doesn't feel right. Trust that feeling. Look at what's actually done and update the plan.
Next: Launch