How should a software team adapt its development process when using AI coding tools?

Plan work so an agent can help without choosing the product

Planning needs a little more structure when agents will implement part of the work. A useful issue records the user outcome, current behavior, expected behavior, exclusions, affected components, acceptance criteria, data or privacy constraints, rollout expectation, and the person who can answer domain questions. These details make it possible for a developer to judge whether an agent changed the right thing.

Use an agent early for repository exploration, dependency mapping, test discovery, or a draft implementation plan. Then have the engineer or technical lead accept the plan before code generation starts when the change affects architecture, business rules, data contracts, or more than one service. GitHub's current guidance for its cloud coding agent makes the same narrow point: well-scoped tasks work best when they state the problem, acceptance criteria, and relevant files, while broad, context-rich, critical, or ambiguous work may need to remain with a developer. GitHub task-scoping guidance

Meeting transcripts can be useful input, but they are not an approved requirement. Have a product or engineering owner turn an agent's draft requirement or system-design note into the issue that the team will build. This preserves a place to resolve contradictions, record non-goals, and decide which trade-offs the agent must not make.

Size work by intent and evidence

The right agent task is small enough that a reviewer can explain its purpose, inspect every changed file, and run the relevant checks. It does not need an arbitrary line-count limit. A change that adds one behavior with one clear acceptance test can be small even if it touches several files. A mixed refactor, dependency upgrade, UI redesign, and database migration belongs in separate tasks because each has different evidence and rollback concerns.

Ask for a plan before a patch on unfamiliar work. The plan should identify files to change, the proposed behavior, tests to add or update, assumptions, and unanswered questions. If it uncovers missing information, return the issue to the owner instead of asking the agent to invent a policy. This also makes capacity planning possible again: the team can estimate a reviewed change and its test work, rather than counting agent sessions as completed engineering work.

Set up the implementation workspace

Run the agent on a branch or isolated workspace, with the repository instructions, build commands, test commands, linting rules, and local-development assumptions available as versioned project material. A current cloud-agent implementation uses an ephemeral environment, makes its changes on a branch, and allows tests and linters before a pull request is created. GitHub cloud agent documentation The exact product is optional. The useful pattern is that an agent's work remains inspectable and does not silently alter the developer's working tree or protected branch.

Give the agent only the access needed for its assigned change. An agent fixing a UI validation rule usually does not need production credentials, a deployment token, unrestricted network access, or a broad database tool. This reduces the impact of mistakes and of hostile instructions in issues, pull-request comments, documentation, logs, or connected tools. OWASP specifically identifies those materials as possible indirect prompt-injection inputs for coding agents and recommends limiting the context and tools used for the task. OWASP Secure Coding with AI Cheat Sheet

The agent's first implementation pass should leave evidence for its reviewer: the accepted plan, changed files, commands run, test results, known failures, assumptions, and any generated dependency or configuration changes. A prose summary helps navigation, but it cannot prove correctness. The pull-request diff, executable checks, and relevant behavior in a test environment remain the evidence.

Preserve the source of truth for design and code

When designers, product managers, or support staff can ask AI to create code, keep the same issue, branch, review, and release path that an engineer uses. It is reasonable for non-engineers to propose an issue, validate a preview, or contribute a narrow change with help. Engineering still needs ownership of repository conventions, interfaces, tests, and deployment decisions.

Do not replace a design system or interface contract with an agent conversation. Store design tokens, component specifications, API schemas, and repository instructions in maintained locations that a human and an agent can both use. If the team uses AI to turn a design into code, include the relevant design reference in the task and require the reviewer to check the resulting component against it. This keeps later maintenance from depending on an unsearchable chat or a recording.

Review the change with named owners

AI changes make review more important and can make it more expensive. The reviewer must own a specific question: does this code implement the intended behavior, preserve the relevant contracts, and meet the team's quality bar? That question is different from asking whether the agent's description sounds plausible. Require an author self-review first, then request a reviewer who understands the affected area. Small, focused pull requests support that work because reviewers can understand the purpose and inspect the history. GitHub pull-request guidance

Use code ownership for areas where a particular team must approve changes, such as service boundaries, shared libraries, data migrations, authentication, build and deployment configuration, and security-sensitive instructions. GitHub documents that code owners can be automatically requested and, with required review rules, their approval can be required before merge. GitHub code-owner documentation Choose the ownership map to match your architecture. A small product team may use one experienced reviewer; a platform team may need a domain owner and a release owner.

Review the whole diff, including tests, generated files, dependency locks, workflow files, and configuration. This matters for agent work because a passing suite can be misleading if the same agent weakened an assertion, deleted a failing test, or changed the test's subject. OWASP recommends independent review of AI-generated test modifications and cautions that a test suite produced by the same agent is not independent assurance. OWASP guidance on tests and agent changes

An agent session log or recorded coding session can explain how a change was made, but it should supplement the review rather than replace it. Use it when the diff needs context or the reviewer wants to reproduce an assumption. Do not require reviewers to replay every agent interaction for routine work. That turns review into a new bottleneck without improving the code decision.

Integrate and maintain the feature through normal delivery signals

The merge should satisfy the same branch protections, checks, and release conditions as a human-authored change. Keep preview or ephemeral environments for changes that benefit from realistic verification, but do not make a flaky preview environment the only route to merge. Maintain a reliable local or integration test path, make environment failures visible as infrastructure work, and distinguish them from failures caused by the feature.

Release in a way that matches the feature's blast radius. A minor presentational change may use the regular release train. A change to billing, authorization, data migration, or a shared API may need a feature flag, staged rollout, migration plan, or explicit operational owner. Those are normal SDLC decisions. AI code does not create a separate standard of correctness.

Keep a durable link from the production change back to the issue, accepted plan, pull request, tests, release, and any agent configuration or custom instructions that materially shaped the code. This makes a later incident or regression easier to investigate and helps the team improve its task templates. NIST's Secure Software Development Framework is designed to be integrated into an organization's existing SDLC so secure practices remain part of development rather than an afterthought. NIST SP 800-218

Measure whether the adjusted process helps the team. Useful signals include time from ready issue to merged change, pull-request review age, percent of agent tasks returned for unclear requirements, escaped defects, rollback or hotfix rate, reliability of test environments, and time spent maintaining generated code. Review these by task type. If agent-created changes raise review age or regressions for a subsystem, narrow the assignment, improve the repository guidance, or return that work to a human-led path.

Example

Hypothetical invoice-status feature

A customer dashboard already receives an invoice record from the billing service, but it does not show whether the newest invoice is ready for download. Product writes an issue with the desired customer message, a non-goal that payment status must not change, the existing billing API as the source of truth, an accessibility requirement, and acceptance criteria for ready, pending, and unavailable states. The billing and frontend owners agree that the feature can be delivered in two focused pull requests.

For the first task, an agent is asked to inspect the billing client and add the existing downloadReady field to the dashboard's typed data contract, with a contract test. It proposes the touched files and test command, then works on a branch. A billing owner reviews the API mapping and the test; the frontend owner confirms that the task did not change payment behavior. The second task uses the approved contract to add the status component and its visual and accessibility tests in a preview environment.

Each pull request is reviewed and merged through the team's normal checks. The feature is released behind a flag, and the team observes client errors, support contacts, and download completion before enabling it for all customers. If a later invoice state is added, the issue and contract test show where the dashboard must change. In this example, the agents help with exploration and first drafts; the team checks billing behavior and plans future maintenance. Whether the process is faster would need to be measured.