Occupation manual 005 / Software engineering
A proof-first route from requirement to change plan, implementation, tests, security, accessibility, review, release, rollback, and monitoring—with no “one prompt shipped production” fiction.
Short answer: use AI as a scoped engineering assistant, not a product owner, security approver, reviewer, merger, deployer, or incident commander. Give it repository rules and explicit acceptance criteria. Require a visible plan, scoped diff, mapped test evidence, known limitations, human review, rollback route, and post-release signals.
NIST's Secure Software Development Framework is designed to integrate security practices into any software development lifecycle. AI can help organize requirements, propose changes, generate tests, document evidence, and surface review questions inside those controls.
CISA safe-deployment guidance calls for well-defined phases, robust testing, measurements, and preparation for failure. W3C accessibility criteria are testable, but full conformance cannot be inferred from a single automated scan or one component.
Name the user problem, repository owner, in-scope paths, out-of-scope systems, approved AI tool, forbidden actions, reviewers, merge/deploy authority, and risk level.
Record acceptance criteria and their authoritative source. Include failure behavior, authorization, privacy, security, accessibility, performance, observability, migration, rollback, and compatibility where relevant.
Inspect existing patterns, identify affected files and interfaces, consider alternatives, record tradeoffs, review dependencies and threats, and define a disable or rollback route before broad edits.
Record each change unit, files, reason, AI role, human inspection, and unexpected effects. Do not hide copied code, generated dependencies, assumptions, warnings, failures, or manual steps.
Use unit, integration, browser, accessibility, security, performance, and manual evidence as appropriate. Test failure paths and permissions—not only the happy path—and keep untested areas visible.
Package the requirement links, scoped diff, test evidence, security/privacy/accessibility reviews, migrations, and limitations. AI confidence is not approval evidence.
Bind the exact artifact/version, deployment authority, staged or canary evidence, rollback triggers and steps, health signals, observation window, and incident route.
| Job | Approved input | AI output | Human gate |
|---|---|---|---|
| Requirement clerk | User request, product source, repository rules | Questions and testable acceptance draft | Product/technical owner confirms intent |
| Change planner | Approved requirements and inspected codebase | Scoped files, steps, risks, and alternatives | Responsible developer approves the route |
| Implementation copilot | Approved plan and least-privilege workspace | Reviewable edits and explanation | Developer inspects every material change |
| Test-prep clerk | Acceptance criteria, risks, and current test patterns | Candidate tests and evidence matrix | Human runs, interprets, and expands tests |
| Release-prep clerk | Exact build, approvals, runbook, and monitoring plan | Release/rollback checklist | Authorized process or person deploys and observes |
A green build may prove syntax, compilation, or selected tests. It does not automatically prove user intent, authorization behavior, failure recovery, accessibility, security, performance, data integrity, or compatibility. Tie each material release claim to a requirement, environment, procedure, expected result, actual evidence, and reviewer.
WCAG 2.2 success criteria are testable and technology-neutral. W3C also explains that accessibility evaluation combines automated testing and human evaluation, and conformance applies to full pages—including responsive variations—not a cherry-picked component. State the intended target and evidence; do not claim conformance from one scanner.
CISA safe-deployment guidance emphasizes defined phases, robust testing, measurements, and practices that prepare for flawed updates. Bind the release to an exact artifact, use the project's staging or canary path, define rollback triggers, test the rollback where feasible, and name who watches which signals for how long.
Act as a software engineering preparation assistant, not a product owner, security approver, reviewer, merger, deployer, or incident commander. Using the supplied repository rules and requirement ledger, produce: (1) unanswered requirement questions, (2) a scoped change plan, (3) candidate tests mapped to acceptance criteria and failure modes, (4) security/privacy/accessibility review flags, and (5) a release/rollback evidence checklist. Do not invent requirements, claim tests ran, hide failures, expose secrets, add unreviewed dependencies, execute destructive commands, merge, deploy, or change production data. Mark assumptions and unverified areas explicitly.
Download the desk, tailor it to the real repository and release system, and start with a small change whose requirements, tests, review, rollback, and monitoring can all be inspected.