AI-native SDLC: seven practices for reliable delivery

A coding agent can finish its task while the change still waits for review or release. For a CTO, the gain depends on whether the whole change reaches users sooner, at an acceptable level of quality and cost.

In an AI-native software development life cycle (SDLC), agent work is built into the team’s delivery process, with defined tasks, permissions and acceptance checks. People set direction and remain accountable for what reaches production. These recommendations draw on field experience across Artefact’s engineering teams.

1. Map the delivery flow and find the bottleneck

Take several recent changes and trace their path through clarification, design, implementation, testing, review and deployment. Separate time spent doing the work from time spent waiting or correcting it. This shows whether the main delay comes from unclear requirements, a slow test suite or a review queue.

Choose the first experiment to address that delay. If review is the bottleneck, producing more code may make it worse; preparing test evidence or keeping changes smaller may help more. Measure the effect through to production so you can see whether you removed the constraint or moved it elsewhere.

2. Make the request testable and supply the context

Describe the behavior you expect, what must stay unchanged and the checks the result must pass.

For example, “add a customer export” leaves important decisions open. The brief should say who can export which records and fields, what limits apply and how failures should be handled. Use those rules to define the acceptance checks.

Give the agent the relevant repository conventions, interfaces and instructions for running tests. Keep that context current, with a named owner. When essential information is missing, the agent should stop and ask a focused question rather than choose a plausible interpretation.

3. Define what agents can do and who accepts the result

Give agents authority to implement changes and run checks within an agreed scope. Keep a named person accountable for acceptance, with clear rules for when the agent must stop or escalate.

Match review to the consequences of a mistake. A documentation update and a change to access permissions need different checks; write down which changes require explicit human approval.

Automated checks can miss a wrong interpretation of the requirement. If an agent writes both code and tests, both can reflect the same mistake. Reviewers should check the agreed behavior and the effect on the surrounding system, including failure cases the agent’s own tests may have missed.

4. Control access and keep a record of the work

Run agent work in an isolated environment with task-specific permissions. Restrict credentials and data access, and use the normal authorization process for any production access. A sandbox alone does not prevent an agent from using credentials it has been given.

If a ticket or event starts a session, define which work it authorizes, what the agent may change and when it must stop.

Keep a shared record of actions, code changes, test results and failures, accessible only to the appropriate team and with secrets and sensitive data removed or protected. Another engineer should be able to understand the work and take over without relying on the original operator’s laptop.

5. Evaluate complete workflows on representative tasks

Build an evaluation set from work in your own repositories, including the constraints that usually make it difficult. Include cases where the correct response is to ask for clarification or stop at a permission boundary.

Compare complete setups: model, instructions, context, tools and checks. Keep tasks and acceptance criteria fixed, and record successful completions alongside human corrections, elapsed time and total cost. Repeat important cases to see whether success is consistent.

Use public benchmarks to choose candidates, then make deployment decisions using results from your own environment. Re-run evaluations when a model or another important part of the setup changes.

6. Measure time, quality, value and cost

Keep two time measures distinct:

• Request-to-production time starts with an agreed need and ends when the change is usable in production. It includes clarification, waiting and rework.

• DORA’s change lead time runs from a commit in version control to deployment in production. It covers a narrower part of that journey.

Pair speed with quality and evidence of the intended benefit. For a feature, usage may be relevant; for a reliability fix, fewer repeat incidents may matter more. Track deployment failures and defects found after release as well.

For cost per accepted change, include model usage, execution infrastructure and human review or correction. Include the cost of unsuccessful attempts, too. Define acceptance in advance and compare changes of similar scope and difficulty.

7. Pilot with one team before expanding

Start with one team and a repeatable task with limited consequences if it goes wrong. Before the pilot, agree on scope, baseline performance and the results required for expansion. Set conditions for stopping or narrowing the trial.

Use actual pilot work for training. Product owners should practice writing acceptance criteria; engineers should practice detecting a plausible but wrong result. Check that the team can investigate a failed change and follow the recovery procedure even when the agent or its provider is unavailable.

Expand when the results meet the agreed criteria and the team can operate the workflow without depending on one specialist.

At your next planning session, bring one delayed change and find out where it waited. If you need help turning that diagnosis into a first pilot, talk to Agilytic.