Agentic Development Workflow Guide

Design stays human-led because it requires judgment about how work actually flows, something agents cannot derive from requirements alone. Agents may assist with minor tweaks later, but they never lead initial creation. The design system then becomes the boundary within which agents must operate.

This gate exists to prevent agents from generating against an ambiguous or moving target. A signed scope is the agent's contract: it defines what good output looks like before a single line of code is written.

Environment setup is a hard prerequisite gate: agents cannot begin generation until the environment is verified. An agent generating code for a misconfigured environment produces output that cannot be tested, reviewed, or trusted.

Architecture guidelines are not optional context: they are the agent's decision framework. Without them, the agent fills gaps by inference, producing a codebase that appears functional in isolation but accumulates structural inconsistencies across files. Defining the architecture upfront is what makes generated code reviewable, maintainable, and extensible by a human team. The quality of the output is determined before the agent starts, not after.

Tests are generated in the same pass as the code, not after. This ensures coverage is tied to the requirements rather than reverse-engineered from the implementation. Generated tests are reviewed for meaningful behavior: passing tests are not sufficient evidence of quality.

Human review happens before the client sees anything. This gate filters output quality and prevents scope creep: only issues that survive team review become client-facing.

Reviewing one screen or feature at a time constrains the feedback surface. Showing everything at once produces unfocused feedback that is hard to convert into actionable issues. Structured issue logging, with intended vs. actual result and location, gives agents and developers enough context to act without back-and-forth.

The README/AGENTS file serves double duty: it keeps human developers and agents aligned on the same architectural decisions throughout the project, not just during initial generation. Cross-review on PRs is a quality gate. No single agent or developer approves their own work.

Re-running the original test suite at delivery catches regressions introduced during iteration. Client sign-off on staging, not production, preserves a rollback point if anything unexpected surfaces.

This constraint exists because of something an agent cannot know, rather than something it does badly. A model's training has a cutoff, and supply-chain compromises are by definition recent. When an agent recommends a package, it is not merely uncertain about that package's current safety, it has no access to the information at all. No amount of better prompting closes that gap. The general form of the rule: any agent action whose safety depends on facts newer than the model's training requires an external check. Dependency installation is the most common instance, not the only one. The check also has to be able to return no and stop the install, otherwise it is ritual rather than control.