Development with AI is most useful when it shortens a verified engineering task without weakening ownership, security or maintainability. Coding assistants and agents can help explore a repository, draft tests, explain unfamiliar code, propose migrations and prepare small changes. They can also reproduce an insecure pattern, misunderstand a business invariant, expose confidential context or produce a plausible change that passes shallow review. The implementation problem is therefore not simply tool enablement. It is designing a delivery system in which people remain accountable and machine-produced work must earn trust through evidence.
This checklist is for engineering leaders, platform teams and security owners planning a controlled adoption. It complements the broader development with AI delivery plan, the AI application development risk guide and the agentic development platform plan. The goal is a repeatable operating model, not a one-off demonstration.
Define the engineering outcome and boundary
Select a narrow workflow whose baseline is already visible. Good first candidates include test generation for a stable module, dependency-update analysis, documentation synchronized with code, or a small defect class with strong regression tests. Avoid starting with production access, autonomous deployment, cryptographic code, safety-critical logic or a poorly understood legacy core. Name the repository, languages, data classifications, approved model endpoints, permitted tools and actions, and the human who accepts the result.
Write a success statement that includes speed, quality and risk. For example: “Reduce median time to prepare a reviewed API regression test by 20%, while holding escaped defects and review rework at baseline, with no restricted data sent outside approved systems.” This prevents acceptance rate or generated lines of code from masquerading as value. NIST’s AI Risk Management Framework organizes work around govern, map, measure and manage; the same logic helps a team connect an AI capability to its context and accountable decision.
| Pilot decision | Evidence before use | Required guardrail | Expansion signal |
|---|---|---|---|
| Draft unit tests | Stable interfaces and a known coverage gap | Tests reviewed against behavior, not implementation | More useful defects found without brittle tests |
| Explain legacy code | Representative modules and current owners | No confidential code sent to unapproved endpoints | Faster onboarding with correct explanations |
| Prepare small refactors | Characterization tests and bounded files | Human-approved plan, diff and rollback | Lower cycle time without extra incidents |
| Triage defects | Labeled issue history and reproducible cases | No automatic closure or severity downgrade | Better routing and shorter time to diagnosis |
Set policy before connecting repositories
Create an approved-use policy that developers can apply during ordinary work. It should state which accounts and model providers are allowed; whether prompts, code or outputs are retained or used for training; what telemetry administrators can see; which repositories and data classes are excluded; and who can approve an exception. Evaluate subprocessors, regions, deletion terms, intellectual-property provisions, incident notification and export controls with legal and procurement owners. A consumer account should not become an informal path around an enterprise decision.
Treat prompts, retrieved files, tool results and generated patches as one information flow. Secrets, customer records, credentials, production logs and licensed third-party code need controls before they enter model context. Prefer organization-managed identities, least-privilege repository access, short-lived credentials and an allowlist of tools. Record policy versions and material configuration changes. The NIST SSDF provides a useful foundation for preparing the organization, protecting software, producing well-secured releases and responding to vulnerabilities.
Prepare trustworthy context and instructions
An assistant cannot infer undocumented architecture reliably. Give it concise repository instructions: build and test commands, supported versions, module boundaries, coding conventions, threat-sensitive areas and the definition of done. Keep architecture decisions, API contracts and runbooks current enough to retrieve. Remove obsolete instructions and conflicting examples. Use generated context indexes only when their access boundary matches the underlying files, and prevent one tenant or repository from retrieving another’s material.
Ask for a plan before a patch on nontrivial work. Require the tool to identify assumptions, files, tests and open questions, then let the developer correct the plan. In a payment retry change, for example, the prompt should name idempotency, duplicate-event handling and settlement reconciliation rather than merely requesting “better retries.” The human supplies business invariants; the model accelerates exploration and drafting. That division makes review sharper and reduces large speculative diffs.
Build verification gates around every change
Generated code follows the same branch protection and release path as human-written code. Run formatting, compilation, unit and integration tests, dependency and secret scanning, static analysis and policy checks. Add tests for authorization, error paths, concurrency and rollback where the change touches those concerns. The OWASP Application Security Verification Standard can turn security expectations into testable procurement and engineering requirements instead of relying on a generic “secure code” instruction.
Human review must evaluate intent, not just syntax. The reviewer should confirm that the issue is real, the patch is the smallest coherent change, inputs are validated at the correct boundary, permissions are enforced server-side, failure is observable and tests would fail without the fix. AI review can provide a second pass, but vendor guidance on responsible use still warns that generated output may be inaccurate and requires validation. Do not allow the same opaque workflow to author, approve and deploy its own change.
| Gate | Question | Evidence | Stop condition |
|---|---|---|---|
| Intent | Does the change solve the accepted issue? | Linked requirement and corrected plan | Ambiguous owner or behavior |
| Code | Is the implementation bounded and maintainable? | Readable diff and architecture fit | Unexpected files or generated bulk |
| Security | Are trust boundaries and dependencies safe? | Threat checks, scans and reviewed permissions | Secret exposure or unresolved high finding |
| Behavior | Does it work under success and failure? | Automated tests plus targeted manual exercise | Flaky, missing or circular tests |
| Release | Can operators detect and reverse harm? | Telemetry, rollout and rollback evidence | No owner, alert or recovery path |
Constrain agent tools and autonomous actions
Agentic tools add risk because they can read widely, execute commands and modify state. Start read-only. Add write access to a temporary branch or sandbox only after the team understands tool behavior. Require confirmation for package installation, network calls, database operations, infrastructure changes and any access to production. Deny dangerous command patterns at the execution boundary rather than relying on a prompt. Isolate untrusted builds, cap runtime and spend, and preserve a transcript that links requested intent to commands, tool results and the final diff.
The NIST generative AI SSDF community profile extends secure-development thinking to model producers, AI-system producers and acquirers. For an engineering agent, that means inventorying models, plugins, retrieval sources and tool permissions as dependencies; evaluating their changes; and maintaining a response path when a provider, model or prompt behavior changes.
Run a four-week controlled pilot
- Capture two weeks of baseline cycle time, review effort, rework, defects and developer sentiment for one workflow.
- Configure managed access, excluded data, repository instructions, logging, budget limits and an incident contact.
- Train a small volunteer cohort with concrete safe and unsafe examples; include reviewers and security partners.
- Use AI on eligible tasks while marking the assisted workflow in internal telemetry without stigmatizing individual developers.
- Review sampled prompts, diffs, test quality, policy exceptions, cost and failure cases every week.
- At the end, expand, revise or stop based on predefined quality and risk thresholds, then publish the decision and evidence.
Measure system outcomes, not generated volume
Compare eligible work, not all tickets. Track median and tail cycle time, review minutes, change-failure rate, escaped defects, rollback rate, security findings, test mutation or defect-detection quality, developer satisfaction and total tool cost. Segment by task type and repository maturity. A faster first draft with twice the review burden is not a productivity gain; a high suggestion-acceptance rate can simply mean people accepted easy boilerplate.
Inspect distributional effects. New team members may gain more from explanations while senior maintainers spend more time correcting subtle errors. Measure whether knowledge is spreading or concentrating in a few reviewers. Keep a sample of rejected outputs and incidents because they reveal where instructions, tests or tool boundaries need work. Re-evaluate after model upgrades instead of assuming prior results transfer.
Key takeaways
- Begin with a bounded, measurable engineering workflow and an explicit accountable owner.
- Protect prompts, retrieved context, tool output and generated code as one governed information flow.
- Keep AI-produced changes inside normal security, test, review and release controls.
- Start agents with read-only, sandboxed access and require confirmation for consequential actions.
- Expand only when cycle time improves without worse defects, review burden, incidents or data exposure.
Frequently asked questions
Must every AI-assisted line be labeled?
A per-line label is rarely the most useful control. Preserve workflow-level provenance where it supports audit, licensing or evaluation, and follow organizational or contractual disclosure duties. The essential point is that a named person accepts the change and the same evidence gates apply regardless of authorship.
Can a team use AI with private source code?
Only after confirming the approved service’s retention, training, access, region, deletion and incident terms and matching them to the code’s classification and contracts. Configure organization-managed access and exclusions, then test that controls behave as documented. Highly restricted repositories may remain ineligible.
When should an agent be allowed to merge or deploy?
Only for narrowly defined, reversible changes after substantial evidence shows dependable behavior and independent controls remain in force. Most teams should keep human approval for merge and production deployment, especially where changes affect security, money, personal data, infrastructure or customer commitments.
Conclusion
Development with AI succeeds when faster drafting sits inside a stronger engineering feedback loop. Define the task, govern context, constrain tools, verify behavior, retain human accountability and measure the whole delivery outcome. That approach lets a team learn where AI genuinely helps while keeping the codebase, customers and operators protected.