AI in Software Development: Choose the Work, Owners and Measures

Adopt AI across planning, coding, testing and operations with task-specific ownership, a whole-lifecycle baseline and measurable accepted delivery.

AI can help software teams explain requirements, propose changes, prepare tests and investigate operational evidence. Adopt it around a specific delivery constraint, with an owner and a measure that includes the work transferred downstream. Faster typing is useful only when the resulting change can be understood, checked, released and supported within the team's quality and operating requirements.

For an engineering leader, the first decision is where assistance belongs in the software development lifecycle, or SDLC. A test-drafting assistant, an incident summarizer and a coding agent need different inputs and permissions. Buying one tool does not establish a working policy for all three. This article provides an adoption operating model, rather than a comparison of products or a promise about developer productivity.

Start with a delivery constraint you can observe

Choose a service and inspect how work moves from a request to a useful production result. Perhaps requirements arrive without examples, reviewers wait for reproduction steps, or engineers repeatedly translate logs into incident updates. Each constraint suggests a different intervention. If review capacity is already exhausted, producing larger patches may make delivery slower.

Define the unit before measuring improvement. It might be an accepted maintenance change, a reviewed test fixture or an incident update checked against the event timeline. Keep attempted, abandoned and corrected work visible. An accepted code suggestion in an editor is not necessarily an accepted product change.

Use permitted examples from the current process to establish why work waits. Avoid treating the most memorable difficult ticket as representative of every ticket. Record differences in change type, system familiarity and developer experience. A comparison between routine generated documentation and a historical security migration cannot establish a productivity effect.

Assign assistance separately across the lifecycle

During planning, an assistant can organize supplied facts, identify contradictions and suggest missing acceptance examples. The product owner still decides what the system must do. Ask the assistant to retain unresolved questions instead of completing a specification with plausible assumptions.

During implementation, useful tasks include explaining unfamiliar interfaces, drafting adapters and proposing small refactors. GitHub's responsible-use guidance for inline suggestions describes generated code as suggestions requiring review and validation. That documented feature behavior does not establish that an autonomous agent, another product or your repository has equivalent controls.

Testing needs an expected result independent of the proposed implementation. Operations needs source-linked observations rather than a convincing root-cause story. Documentation needs a checked revision and known omissions. The same fluent explanation can help in all these tasks, but the accepting owner and evidence differ.

Give the tool enough context without widening its authority

Useful context includes the relevant interface, dependency versions, accepted examples and local conventions. An entire production database is rarely an appropriate substitute for explaining a task. Source access, permission to transmit source to a provider and permission to execute generated commands are separate decisions.

Write down which repositories, environments, records and external services a tool may access. Include installation scripts, test runners and downloaded dependencies in the execution review. A command labelled test can still contact an external service or use an inherited credential. Start evaluation with synthetic records and inert integrations when those can answer the question.

Repository instructions and retrieved tickets also need a trust boundary. A comment in a file may be relevant implementation context without being authority to change deployment settings. Require explicit escalation when the proposed scope expands from a local function to a permission policy, schema or release workflow. Keep consequential credentials outside the proposal environment unless separately authorized.

Measure the work that moves rather than disappears

DORA's software delivery metrics examine delivery throughput and instability at the application or service level. They are useful operational signals, not an automatic causal test of an AI tool. Use their defined boundaries consistently, and supplement them with task-level observations such as review time, correction effort and unresolved failures.

A fictional team compares two ways of completing the same bounded maintenance workload. All amounts below are stipulated active labor hours, not an Ampity benchmark. The categories are disjoint: authoring includes initial implementation only, review includes checking before acceptance, and correction includes work to resolve returned defects.

Authoring falls by six hours, while the included total rises by four. These inputs would not support expansion on a labor-saving claim. They also do not measure elapsed delivery time, production defects or tool cost. Those need separate observations. The team could narrow the task to a familiar adapter and rerun the comparison rather than declaring either universal success or failure.

Keep engineering judgment and learning visible

An engineer accepting a generated change should be able to explain its behavior and the important failure paths. Treat unexplained code as review work still outstanding. A polished summary cannot replace understanding of the interfaces, data ownership and state transitions that the code changes.

Give less experienced engineers opportunities to predict a result, inspect the observation and explain the difference. Measure whether the tool helps them understand the system, rather than merely making their output resemble a senior engineer's patch. Pairing and focused feedback can remain valuable even when the assistant drafts most of the initial syntax.

Make disagreements inspectable. Preserve a rejected suggestion's relevant reasoning and test evidence without retaining confidential prompts unnecessarily. Repeated corrections in one subsystem may indicate stale context, missing architecture guidance or an unsuitable task. Respond to that pattern instead of asking everyone to produce more prompts.

Review failure conditions before expanding

Expansion changes both capability and workload. A tool that only explains a stack trace may later propose a patch; a patching tool may later run commands. Each change needs a review of the newly affected permissions, sources and recovery consequences. Calendar milestones and subscription renewals are not acceptance evidence.

Use this reusable adoption checklist for each task class:

• Name the service, delivery constraint and accepting owner.
• Define an accepted output and a comparable baseline.
• Record permitted context, provider handling and execution permissions.
• Include review, correction, operating effort and material tool charges.
• Retain rejected and inconclusive cases with their reasons.
• Define who stops the tool, handles exceptions and removes access.

Stop the current trial if protected data reaches an unapproved destination, a tool broadens its authority, or reviewers cannot explain the proposed changes. Correct the boundary before resuming. Ordinary quality failures may justify narrower tasks or better context; they should not disappear from the record.

Next action: prepare a task-level adoption record

Choose one recurring bottleneck this week and document its current inputs, waiting time, active effort and completion evidence. Select an assistance task that addresses that bottleneck without changing production authority. Ask the service owner and an independent reviewer to agree what would count as improvement and what would block expansion.

The AI workforce preparation article owns broader recurring-role preparation. The AI-assisted code accountability paper owns detailed release evidence. Use those resources when the adoption record grows into a delegated role or a consequential release policy. For a narrower implementation experiment, continue with generative AI for software development.

Sources checked on 19 October 2026. Examples and checklists are proposed engineering guidance; no customer trial, production release or measured productivity improvement is claimed.