Step 5 & 6 - Test, Finalize & Document

The code is written, but the work is not done. Steps 5 and 6 ensure that what we built works, is safe, and is understandable to others.

Step 5: Test & Iterate

Use AI to help, not to decide

AI is useful for generating test scaffolding and suggesting cases, but humans define what "good coverage" means.

Patterns:

• Ask the AI to generate baseline tests for a function, endpoint, or component, then:
  • Add or adjust cases for edge conditions, failure paths, and business rules.
  • Remove redundant or meaningless assertions.
• When tests fail, provide the error and relevant code to the AI and ask for hypotheses or patches—but always validate the fix yourself.

Types of tests

Depending on the change, you may need:

• Unit tests for core logic and pure functions.
• Integration tests for contracts between services, modules, or DB.
• E2E or UI tests for critical user flows.

Your spec from Step 2 should already hint at the right mix. If it doesn’t, refine the spec.

Step 6: Finalize & Document

Documentation updates

Before opening a PR or merge request, ask:

• Did I change how the system behaves?
• Did I introduce new configuration, environment variables, or APIs?

If yes, update:

• Project docs (READMEs, architecture notes, runbooks).
• Example configs or .env templates.

You can use AI to draft these updates from your diff, but read and correct them carefully.

PR description and self-review

Use your AI-native IDE or chat tool to help summarize the change:

• Provide the staged diff.
• Ask for a concise PR description that explains why, what, and how, plus any risks or follow-ups.

Then perform a manual self-review in the hosting platform:

• Scan for debugging leftovers (logs, commented-out code).
• Confirm tests are present and meaningful.
• Check that the change aligns with quality gates and project rules.

Only then is the change ready for review by others and for the broader governance checks described in the Governance section.