Things your team can try

Before an AI agent's code change goes live, have an engineer check the agent's plan for watching it in use, and agree in advance what happens if a problem appears.

Have AI agents review every pull request, reserve careful human review for core and sensitive code, check small low-risk changes more lightly, and have a person approve every merge.

Ask whoever hands over work that AI helped produce to confirm they have checked all of it, and treat any error in it as their error.

Set an AI agent's freedom by the risk of the task: let it work alone on documentation, and require a person's approval before any production deployment.

Before an AI agent's proposed change is applied, show users a preview of its full effect, including on other people, and apply it only when they confirm.

Review each interface an AI agent builds on its live preview link, including on a phone.

Keep a fixed list of changes that always need a person's approval, including changes to the approval rules, and check it with a script the AI agent cannot edit.

Have a coding agent attach a note to each change listing what was asked, what changed, what has no test and what was left out, for the reviewer to check.

Include an accessibility check in the reviews an agent must pass before it is released to other staff.

Publish the list of checks an agent must pass before release at the start of a project, so that builders plan for them from the first day.

Ask the coding agent for a plain-language summary of every change a designer submits, and hold the change to the same review standard as an engineer's.

Sort each code change written by an AI agent by risk, and require a person to review the high-risk ones.

Review risky AI-written code more closely than routine code, and keep going until the reviewer can explain the change and take responsibility for it.

Send every change that an AI agent makes through the same validation and saving code that people's changes use, so that the product's rules are kept in one place.

Report AI agent spending by team per piece of finished, reviewed work, so the cost of reviewing agent output counts, not only the AI model's bill.

Log the median time to approve and the approval rate for each agent approval step, and redesign steps below two seconds or above 95 percent approval.

Tier an AI agent's approval requests by consequence, such as spending, publishing, deleting and reading private data, rather than by which tool the agent uses.

Let the person who asked an AI agent for a code change review that change, and track how often people have to correct or redirect the agent.

Before a person reviews an AI agent's answers, give that person a verified reference to check them against, and re-check any corrections the reviewer makes.

Put a designer on the team that sets up the company's AI agents, so that the agents' output is judged by a designer's standard of good work.

Ask an expert in the subject, not a generalist, to review an AI agent's output, with a structured way to check each answer.

Give every change an AI agent makes its own live preview link that people outside engineering can open.

When an AI agent drafts text for users, let the AI model write the wording, and let ordinary code route requests, copy record numbers and check the output format.

When the team adopts a new coding or testing rule, update its AI coding agents' written instructions at the same time, so the agents follow the rule from the start.

Test AI agents on the same tasks with and without their added instruction files, because extra context can confuse an agent and make its results worse.

Write each design-system rule, with its known exceptions, in a short file that AI agents read every session, so that automated audits do not remove the exceptions.

Let AI agents propose changes to the design system but never merge them, and have a person merge each change only after the required automated checks pass.

Give an AI agent one new kind of task at a time, such as testing its own work before merging, and add the next only once it handles that reliably.

Keep a design system's colours, sizes and rules in one shared file, generate the component library, Figma files and documentation from it, and correct mistakes in that file.

Build the design system and one finished screen by hand, and give the agent a file of the system's rules before it extends that screen to the whole flow.

Keep every rule about who may see what in one central permissions table, so that adding a type of user or granting a permission is a one-line change.

Assign each context file that agents read to an owning team rather than to one person, so that the file keeps an owner through a reorganisation.

Give every design-system file that AI agents read a named owning team, and review changes to a file more carefully the more screens depend on it.

Keep building screens and maintaining the design system as separate jobs for AI agents, so an agent that needs a missing component notes it instead of changing the design system.

Check which shared files and systems a colleague's AI assistant can reach before concluding that the colleague resists using it.

When AI agents write much of the code, invest in shared structure for the parts that change most, such as a design system or generated database queries.

Count an AI agent's incident task as finished only when a separate check shows the problem has gone, such as the alarm clearing, not when the agent's action reports success.

Before an AI agent changes a live system, require a person to approve that exact change, let each approval be used once, and ask again if the change is altered.

When AI agents repair their own failing work, cap the repair attempts and the spending, and hand the problem to an engineer once either limit is reached.

Make one person responsible for how an AI-built product fits together as a whole, and have that person check that each new change fits.

Start using AI agents in one low-risk process that the rest of development does not depend on, and name one person in that team to set the agents up.

Give each AI coding agent one whole feature, from interface to storage, instead of one layer such as the frontend, so that agents seldom need to brief each other.

Make one person responsible for each AI agent: its instructions, its review rules and the quality of its work.

Have AI agents that check other agents' work answer pass, warn or fail in a fixed format, and compare several checkers' answers instead of trusting a single one.

Name an owner for each instruction file an AI agent follows to build interface screens, and have the owner reread it when the task or the AI model changes.

When adding an AI agent to one low-risk step of development, measure the review and testing time it adds to the steps before and after, not only local speed.

Before an AI agent writes code, write the tests that define a correct result, let the agent work until they pass, and review the tests instead of the code.

Before an agent builds a prototype, write a spec that lists how the agent will verify each part of its work.

Do not count tests that an AI model wrote for existing code as verification, because they record what the code already does, errors included.

Have a person read 10 real user sessions with an AI feature and note what went wrong, then 100, before anyone writes a measure of its quality.

Measure how often a known error appears in AI output before changing the prompt, and measure it again after every change.

Check each failure that an agent proposes against the team's own notes on real sessions, and accept or reject it before the team starts to measure it.

Before building starts, agree with the people who will approve AI-made changes which automatic checks every change must pass.

Add the questions a design review would ask to the instructions an AI agent follows when planning, so that they are answered before anything is built.

Write the automatic tests for AI-written changes with the engineers who approve them, and add tests until they would merge a change on the test results alone.

List the tasks AI agents now do, have their former owners test whether they can still do them unaided, and schedule practice without AI for skills that are slipping.

Put a short human-written brief above the agent prompt in every ticket for a coding agent, and label each section as written by a person or generated by the agent.

Label each section of a design specification handed to an agent as written by a person or generated by the agent, so that reviewers know where to check for inventions.

Replace the requirements document, the design brief and any side specification for a feature with one table that has a row for each thing the product lets someone do.

Link every synthesised finding and ticket to the transcript or feedback it came from, and stop work on any item that cannot be traced to its source.

Link a click-through prototype of each flow under its row in the feature's capabilities table, and record a video walkthrough for the top in place of a design brief.

Give a named person time to keep the documents that explain the product current, and to mark the ones that are out of date.

Build AI-generated apps in a fixed order, design system first, then prototype, then working app, and use ready-made components for sign-in, databases and email.

Cap how many topics each engineer and each squad may have open at once, and hold the cap when stakeholders or engineers push to start more AI-assisted work.

Have an AI app builder settle the design system as its first stage, before it generates any prototype.

Write down the business rules a piece of software must follow before prototyping it with AI, and give developers those rules along with the prototype.

Before choosing a direction from an AI prototype, build out the states it leaves out, such as a cancelled booking, to see whether the direction still holds.

Throw away a prototype built to learn, and design its data model again before any of it goes into the product.

Once AI agents write most of the code, have engineers present their finished work to the team, so that each keeps pride in the work and knows what colleagues build.

Ask the team that owns a critical service to explain its recent consequential changes without its go-to engineer or its AI tool before approving the next release.

Give the team that owns a critical service the authority to delay a release when it cannot explain a change, before any reliability target is breached.

Take each workflow apart step by step before an agent is built for it, and decide which steps the agent takes over and which are cut.

When AI agents build the same feature separately for iOS and Android, make both versions pass one shared test suite for the business logic before either ships.

Add the question of whether users understand and trust a feature to every product review, beside the question of whether it works.

Design an AI feature to hand users the finished result first, such as a personalised report, and offer the underlying articles and controls afterwards for those who want more.

Offer each new AI model to staff on release day as an experiment with a capped budget, and keep it only if benchmarks, user reports and cost data support it.

Compare a new AI model's cost per session on the same group of early users before and after, because early users are heavier users of AI than most staff.

When people keep asking an AI agent in chat to do the same job, have the agent build a small dedicated tool for that job instead.

Design the first screen of an AI feature around the result the user came for, and offer the underlying tool as a second step.

Show users what the AI system checked, what it inferred and what still needs their review before the next step.

Have the same developer build each mobile feature on both iOS and Android with AI coding agents, instead of keeping separate iOS and Android teams.

Write down the customer problem a new feature solves before building it, and choose a familiar pattern when it solves that problem as well as a novel one.