Practices the articles on this site describe, grouped by topic. Working Surface writes each one from its linked article, and tags it for product, design or engineering work. The link page shows the line each practice comes from. Jev, an AI model from TypeSafe, checks that each practice makes sense without its article, and it has checked all 116. Each topic lists the clearest first. How the check works
Human approval
A person other than the one who built a piece of AI-assisted work checks it and approves it before it reaches customers.
When a pull request was approved without every part being read, say in its description which parts nobody read, so that later reviewers and incident reviews know what was checked.
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.
Assign the review of each agent-built code change to the tech lead or engineering manager of the team that owns that code, not to whoever is free.
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.
Include an accessibility check in the reviews an agent must pass before it is released to other staff.
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.
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.
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.
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.
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.
Sort each code change written by an AI agent by risk, and require a person to review the high-risk ones.
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.
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.
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.
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.
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.
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.
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.
Agent context files
The files an AI agent reads before it works, such as design-system rules and written instructions, and the person or team who keeps them current.
Write down, in the standing instructions an AI agent reads before every task, which actions it may take on its own and which need a person's approval.
List in an AI agent's standing instructions the design rules it must follow and the design changes that need a designer's approval.
Make one person responsible for the design system, separate from whoever builds screens, and have that person review every gap or exception the builders record.
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.
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.
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.
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.
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.
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.
Check which shared files and systems a colleague's AI assistant can reach before concluding that the colleague resists using 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.
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.
Agent ownership
A person or team answers for what an AI agent does, and decides its instructions, its default settings and when it must hand a decision to a person.
Instruct each design agent to ask clarifying questions first and to build nothing without an explicit go-ahead from a person.
Write down early which actions AI coding agents may take without asking, such as committing and opening pull requests, and which wait for a person, such as merging and deploying.
Give every written instruction file an AI agent works from a named owner, a version number and the date it was last reviewed.
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.
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.
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.
Make one person responsible for each AI agent: its instructions, its review rules and the quality of its work.
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.
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.
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.
Reread the written instructions an AI agent follows when it builds interface screens, each time the task changes or the AI model is upgraded.
Evals before the build
Before an AI feature is built, the team writes down what a good output looks like, so that the result can be tested against it.
Have the agent add sliders and other live controls to a prototype, so that its colours, sizes and motion can be adjusted while it runs.
Before trusting one AI model to grade another's output, label a set of examples by hand and measure how often the grader agrees.
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.
Give the AI coding agent a short instruction file that makes it question the person requesting a build about the plan before any code is written.
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.
Do not count tests that an AI model wrote for existing code as verification, because they record what the code already does, errors included.
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.
Ask the people who approve AI-written changes whether the automatic test results alone would convince them, and add tests until they would.
Decision records
A written record of what was decided and why, kept with the work so that someone who did not build it can review it.
Keep a visible list on the team's planning board of each customer problem the team chose not to solve and each solution it rejected.
Add a deliberate review step whenever research findings are copied into a new document, such as a ticket or a brief, and record what changed.
Show the design options rejected during discovery beside the option carried forward, so that a reviewer can see that alternatives were compared.
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.
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.
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.
Changing roles
How the jobs of product managers, designers, engineers and their managers change when AI agents do more of the building.
Before pausing work done with AI agents, share its files, write down the next step and list open questions, so a colleague can continue it without the person who started.
Set stricter automated checks for test coverage and code complexity on AI-written code than on hand-written code, and run them on every change before merging.
Have product leaders record, for each product, whether its product managers and designers may deploy their own changes to production, rather than one rule for all teams.
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.
After the prototype
AI makes a working prototype quick, so the effort moves to choosing a direction and finishing a reliable product.
Place several prototype directions side by side where the team can compare and discuss them, instead of judging one prototype on its own.
Have someone with strong design knowledge review an AI-generated prototype before anyone treats it as ready to ship.
Remove any named solution, such as generative AI, from a design workshop's problem statements, so that the team does not choose the answer in advance.
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.
Understanding the work
A team checks on purpose that its people can still explain work that AI agents produced.
Before requiring a team to use an AI tool, agree in writing which tasks it is for, so that nobody feels they must fake enthusiasm for it.
When AI tools draft research findings, have a second researcher work through the interpretation with the first, so that someone can disagree and catch what was missed.
Put the rules an AI coding agent keeps forgetting into the instruction file it reads with every request, such as CLAUDE.md or AGENTS.md, instead of relying on its memory feature.
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.
Work cut to size
Before an AI agent starts, the work is split into pieces small enough for a person to review one at a time.
Run automated checks, such as behaviour tests and independent code reviews, before a person approves agent-built work, so that each piece reaches the person already checked.
Define the visual reference for each agent-built screen, such as the existing app or approved designs, and require the comparison to pass before a designer reviews it.
Cut each agent-built feature into thin slices that each work end to end, and review the agent's implementation plan as a group before any code is written.
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.
Ground truth for review
A set of correct answers or expected results, prepared by someone other than the builder, that a reviewer uses to check work made with AI.
Write down the problem a feature solves and the benefit it should bring before building its AI prototype, and judge the prototype against that statement.
Start each review of an AI prototype by reading out the problem and benefit written before it was built, and judge the demo against them.
When an AI agent analyses data, save the steps it followed in a tool the whole team can use, so that anyone can repeat the analysis and check the answer.
Training juniors
How people new to a craft build judgement when AI tools do the work that used to teach it.
Pair each junior designer who works with AI tools with a senior who reviews the output beside them, and put the teaching time in the project plan.
Run incident reviews that ask what the team believed that turned out to be untrue, so that junior engineers practise judging their own assumptions.
Write critical thinking into career frameworks as specific behaviours, such as validating assumptions before implementation, so that managers can see a junior engineer's growth that shipped tickets no longer show.
Interfaces for agents
Product pages and data designed so that an AI agent, not only a person, can use them.
Replace checkmarks in comparison tables with specific values that name their source and date, so that an AI assistant can copy them and a person can check them.
Give AI agents the same actions and forms that people use in the interface, and show an agent only the actions that are possible at the current step.
Workshops that ratify
A workshop that confirms rules a team has already drafted while reviewing real work, instead of trying to invent them in the room.
Write down a design principle whenever a review catches AI-generated work drifting from the product's existing patterns, and share the list with the other design leaders.
Check in design critique whether an AI feature's loading state describes more steps than the system runs, and use a plain spinner for a single quick call.
Other practices
Practices from links that are not filed under a topic.
Design what a person sees while an automated action runs and just after it ends, such as a saving indicator, before the feature ships.
Add the question of whether users understand and trust a feature to every product review, beside the question of whether it works.
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.
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.
Design the first screen of an AI feature around the result the user came for, and offer the underlying tool as a second step.
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.
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.