Document AI-assisted engineering work by recording the judgment you exercised and the evidence you verified. Capture the constraint you identified, the alternatives you considered, the correction you made, and the result you checked. A transcript or a large generated diff does not, by itself, explain your contribution.
When an assistant writes the first implementation, the visible artifact can make the human work harder to see. The important contribution may have happened before the code: choosing the problem, rejecting an unsafe assumption, narrowing the scope, or deciding how to test the result.
You do not need to claim every generated line as manual work. You need an accurate account of responsibility. The record should make it possible to understand what you directed, what you reviewed, what you accepted, and what happened afterward.
Keep the decision, not just the transcript
A full conversation can contain false starts, irrelevant suggestions, and claims that were later corrected. Preserve approved source material where appropriate, but write a compact record of the consequential decision. Include enough context for someone to understand why you changed direction.
The Worktold manual guide uses a practical record of context, judgment, contribution, and outcome. For AI-assisted work, add the assistant’s role and the verification boundary. That makes the record more accurate without turning it into a performance of how much prompting you did.
A fictional example: the wrong fix for stale reads
A design requires a user to see a status change immediately. The proposed implementation reads from a replica. An assistant recommends bypassing the cache to solve stale reads. You know the replica is asynchronous and challenge the recommendation: removing the cache does not remove replication lag.
You ask for a bounded experiment comparing immediate reads from the primary and replica after a write. You review the implementation, run the test, and inspect the output. The result supports a narrow conclusion: replica-only reads do not satisfy the stated requirement in the tested conditions.
You then return to the design discussion with the result. That final step matters. The contribution is not only noticing the flaw; it is helping the team make a better decision using verified evidence.
Write the contribution at the right strength
Scroll sideways to see all columns.
| Field | Fictional example |
|---|---|
| Context | The proposed design needed immediate visibility after a status update |
| Judgment | I identified that cache bypass did not address replica lag |
| Contribution | I scoped, reviewed, and ran a comparison test, then documented the decision |
| AI assistance | The assistant helped draft the test implementation after the diagnosis was corrected |
| Outcome | The team ruled out the replica-only approach for the stated requirement |
| Limit | No production rollout, avoided incident, or financial saving was measured |
The final row prevents the story from growing every time it is summarized. “Ruled out an approach” is an outcome. It does not need to become “prevented a major outage” to be worth recording.
Attach evidence for each transition
A prompt requesting a change proves that you requested it. It does not prove that the change was made. A generated patch shows an implementation candidate. It does not establish that the tests passed. A successful local test does not prove production behavior.
Match each claim to the artifact that supports it: the design constraint, the human correction, the accepted change, the verification result, the release record, or the measured outcome. Keep missing transitions visible. If you personally attest to something without a source artifact, label that evidence accordingly.
This is also how you avoid giving the assistant credit for your judgment or taking credit for work it merely proposed. Separate suggestion, decision, implementation, and verification. Those distinctions are useful even when no AI is involved.
Map to the criterion, not to enthusiasm about AI
“Used AI effectively” may or may not be part of your company’s framework. Ask what the work actually demonstrates. The example above might support technical judgment, testing discipline, or collaboration. It does not automatically establish next-level influence.
To support a broader scope claim, you would need additional evidence: perhaps other teams adopted the decision method, a shared standard changed, or you guided a larger effort. Do not turn an individual debugging success into a claim about organization-wide leadership.
If your company has rules about disclosing AI assistance, follow them. A career record should be compatible with the expectations under which the work was performed.
Capture one decision after the session
At the end of a meaningful session, write a few lines while the reasoning is fresh. What did you accept or reject? What information changed the plan? What did you verify? What remains pending? Link only approved sources and remove sensitive details from any shareable summary.
You do not need a record for every prompt. Capture decisions that changed the work or help explain a contribution. A short, precise note is easier to maintain and more useful than an unfiltered transcript dump.
- Identify your consequential decision.
- Describe the assistant’s role accurately.
- Separate suggestion, implementation, and verification.
- Attach the evidence supporting the claimed state.
- Keep business impact and production claims within their proof.
- Ask your manager which criterion the example supports.
Compare a Claude skill workflow or ChatGPT project if you want to build this routine yourself. Worktold’s demo illustrates a dedicated version of the record; its MVP remains planned for November 26–29, 2026.
Written for Worktold using public sources and original illustrative examples. Product research checked November 10, 2026. Read our editorial approach and comparison limits.
