AI can help turn development evidence into documentation. It should not be allowed to reconstruct a convincing version of work from memory and call it fact.
The safest pattern is evidence first, draft second, verification last.
Capture evidence while the work is fresh
Create a small work record for each meaningful change:
- problem or request
- scope and exclusions
- files or services changed
- important decisions and rejected options
- commands or migration steps run
- test output
- unresolved risks
- rollback or recovery route
Voice notes can help capture reasoning, but they are not proof that a command ran or a route worked. Link the note to the diff, log, test result or ticket that supports it.
Separate three kinds of statement
The drafting prompt should force a distinction between:
- Observed: directly shown by a file, log, test or environment.
- Inferred: a reasonable explanation of the evidence, labelled as such.
- Planned: intended work that has not yet happened.
This prevents a familiar documentation failure: a build note quietly becoming a deployment claim.
Give the model a strict brief
Use a prompt along these lines:
Draft a technical handover from the evidence below. Do not claim a test, deployment, performance result or production state unless the evidence explicitly shows it. Separate observed facts, interpretations, outstanding work and verification steps. Preserve commands exactly. Flag contradictions and missing evidence instead of filling gaps.
Ask for a predictable structure:
- Outcome
- Context
- Changes made
- Evidence
- Verification completed
- Remaining checks
- Rollback or recovery
- Sources and owners
Keep secrets and personal data out
Before sending evidence to any model, remove credentials, tokens, customer data, private URLs and unnecessary personal information. Use an organisation-approved service and confirm its data-handling terms.
If Microsoft Copilot is used, Microsoft documents how work data, Microsoft Graph permissions and prompts are handled. Those protections do not remove your responsibility to minimise the data you provide (Microsoft Learn).
Verify the draft independently
The reviewer should compare the documentation with the underlying evidence, not just read it for fluency.
Check:
- every changed file is real
- every command is exact
- every claimed test has output
- development and production are clearly separated
- dates and version numbers have a source
- limitations and failed checks remain visible
- links point to the final authoritative source
For high-risk changes, the person who wrote the implementation should not be the only approver.
What to automate
Automate low-judgement collection where possible: change lists, commit metadata, test reports and known environment identifiers. Keep interpretation and approval visible.
Do not automatically publish an AI draft to a public knowledge base. A wrong internal note is inconvenient. A wrong indexed procedure can be repeated by people and other AI systems for years.
The proof boundary
This workflow can improve the consistency of a development record. It does not prove the code is correct, deployed or safe. Only the relevant test, environment readback and responsible approval can establish those things.
For more evidence-first AI working patterns, join Microsoft Copilot Adopters.