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. Our technical standards are documented in Engineering Thinking and Engineering Fundamentals. These are the reference for what “right” looks like: API design, data modeling, error handling, naming conventions, and more.
Build the knowledge base. When AI makes the same mistake twice, document it. A CLAUDE.md file in the project repo captures patterns, caveats, and corrections specific to the codebase: things like “always use X pattern for pagination,” “never call Y directly, use the service layer,” “this module expects Z format.” The AI reads this file at the start of every session. A team that maintains it gets progressively faster. A team that doesn’t re-explains the same things indefinitely.
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, or 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, whether from client feedback, new information, or 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.
Demo Checkpoints
What’s expected: At each milestone in the release plan, PM and PD review working software together with the engineer. Not a status update, but a hands-on look at what’s been built.
What good looks like: The demo covers the main user flow end-to-end. PM and PD test it against the definition doc: does it behave as intended? Are the edge cases handled correctly? Does the design match what was agreed? Feedback is specific and actionable. Issues are flagged immediately, not accumulated for the end.
How to get there:
Schedule the demo at the time you set the milestone. Don’t leave it to chance. Keep it short: 30 minutes is usually enough. The engineer walks through what’s been built. PM and PD interact with it directly, not just watch.
The questions to answer in every demo:
- Does this match the user flow in the definition doc?
- Are edge cases handled the way we agreed?
- Is there anything here that would confuse or block the user?
- Is there anything missing that would block Launch?
Issues found in a demo are far cheaper than issues found after launch. The checkpoint exists to find them while there’s still time to fix them.
What to Watch For
The engineer is quiet for too long. Check in. Not “how’s it going” but “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.
Time-Blocking
Work expands to fill the time available for it. If a task has no time box, it will take longer than it should. This applies to Build more than anywhere else.
What’s expected: Every task in Build has an estimated time box. Milestones have dates. The release plan is not just a list of what needs to happen. It’s a list of what needs to happen and by when.
How to get there: Before starting any piece of work, decide how long it should take. If it runs over, that’s a signal: the scope was wrong, the definition was unclear, or something unexpected came up. Any of those warrant a conversation. None of them warrant silently expanding the timeline without telling anyone.
Parkinson’s law is real. A time box is not pressure. It’s a forcing function for focus.
Clear Ownership and Next Actions
Every open item has one owner and one next action. If it has two owners, it has zero owners. If it has no next action, it doesn’t exist.
This applies to anything that comes out of a conversation, a demo, a blocker, a scope decision. Before any interaction ends, whether a standup, a message thread, or a milestone review, there should be a clear answer to: who owns this, and what happens next?
Oncken and Wass called these “monkeys.” The next move in any problem sits on someone’s back, and it needs to be clear whose. Monkeys need to be fed or shot. A monkey that sits untended, with no owner, no next action, no deadline, starves the project. If a problem can’t be acted on right now, either assign it to the right person with a specific next step, or explicitly decide it’s not worth solving and drop it. The worst outcome is a half-alive problem that blocks progress without anyone noticing.
The rule: every conversation ends with a named owner and a named next action. No exceptions.
Technical Communication
What’s expected: Engineers communicate updates that are brief, specific, and actionable. Not status reports, but signals: what’s done, what’s next, what’s blocked.
What good looks like: “Cart persistence backend complete. Starting on the session restoration logic today. One question: should the 30-day window reset on each visit or only on each purchase?” That’s a useful update. “Working on the feature, making good progress” is not useful.
When something material changes, communicate it immediately to PM and to the relevant stakeholders. Don’t wait for the next standup. Don’t absorb the information and adjust silently. Surface it fast so the team can respond.
Next: Launch — Also: Code Review