Direct Coding Agents

The Product Engineer uses coding agents to turn approved intended behavior into working software while retaining accountability for what was built. The implementation loop should be incremental, observable, and consistent with the project's standing constraints.

Responsible role: Product Engineer.
Participants: Coding agent; architect or UX designer when decisions require them.
Inputs: Current feature specifications, project objectives, approved instructions and assets, existing product behavior, identified constraints.
Outputs: Working implementation, associated ordinary automated tests, updated specifications when behavior changes, and a clear account of unresolved issues.

1. Choose an implementable slice. Select a coherent set of feature behavior with enough surrounding context. Large features may be implemented incrementally, but preserve the relationship to the controlling specification.

2. Provide the source of truth. Direct the agent to read the project's standing instructions and the relevant specifications. Identify the required behavior, acceptance conditions, and any boundaries not already evident from project context.

3. Ask for implementation, not unsupported policy decisions. The agent may propose an implementation strategy and reuse existing components. It should not invent business permissions or introduce new dependencies, architecture, or design-system conventions without necessary approval.

4. Inspect functioning behavior. Exercise the result yourself using realistic flows and representative data. Check the happy path and meaningful exceptions. Reading a summary of generated files is not equivalent to validating the experience.

5. Iterate with concrete feedback. Report observed behavior and what should happen instead. Distinguish an implementation defect from a change in stakeholder intent. If intended behavior changes, update the specification before or alongside the next implementation iteration.

6. Preserve maintainability. Use approved libraries and components, keep code understandable, maintain routine automated checks, and avoid needless proliferation of similar implementations. Involve the architect for structural or security consequences beyond the Product Engineer's authority.

7. Record unresolved work clearly. Do not hide incomplete flows, access limitations, failing tests, or unapproved assumptions. Make them visible for subsequent review and verification.

“Implement the behavior described in feature specification SPEC-002 using the existing project instructions and approved components. Do not invent new approval rules or introduce dependencies. Show any unresolved ambiguity before implementing it. Include appropriate automated checks and summarize what behavior can now be exercised.”

This is an example of a productive request, not a mandated prompt syntax. The specification, not the wording of the request, remains the durable product reference.

The relevant behavior can be demonstrated, its accepted requirements remain accurately specified, routine automated checks have been performed, and material issues are identified before the work moves to technical or stakeholder review.

Blindly accepting generated summaries; making large unreviewable batches of changes; treating an agent's guess as a policy decision; allowing convenient custom components to bypass approved assets; and failing to synchronize specifications after approved behavior changes.