This page covers how AI is changing how we work, and where it adds value at each stage of the development lifecycle. It is for every engineer at Human Made, whatever your experience with these tools.
Foundational Principles #
It is worth being clear about how we want to work with AI. The work here uses the company AI Principles and the 5 levels of AI as its foundations.
At level 3, think of AI less as a pair-programming partner, and more as an engineer you are delegating to. You set the direction; AI generates the code. You take on the role of full time code reviewer.
- Own what you ship. Treat an agent’s output the way you would treat a junior engineer’s work. Stay close enough to it that you understand it, and are happy to stand behind it. Remember that you are responsible for any output that AI creates.
- Keep asking why. You can hand off the typing, but not the understanding. Keep asking “why did it do that?” until the answer makes sense to you.
- Keep it reviewable. The thing people consistently dislike about AI output is when it pushes the work of untangling it onto the reviewer. Favour short, decodable diffs and docs over long specs, comments or mega-PRs.
- Teach it to mark its own homework. Point it at your tests, linters and coding standards, and get it checking a sample before it runs at scale. This will save you review time later.
- Experiment, and share what works. Everyone’s setup will differ. Build skills and prompts that suit you. Share the ones that work, so the team can level up together.
- Expect this to keep evolving. Try new things as the tools change, and expect this page to change with them.
These principles apply at every stage of the lifecycle below. What changes from stage to stage is how much AI can take on. Your role stays the same throughout: you are the reviewer, and you own the outcome.
1. Plan and spec #
Good planning gets to the heart of the need, not just what has technically been asked for. Having a clear understanding, and a strong grasp on the context of the problem allows us to focus on creating solutions that answer the need directly. It makes it easier for all to understand the outcome required.
Iit is important that you do not delegate understanding. It is your job to make sure the design, architecture and spec speak clearly to the need. An agent with a clear brief, visibility into prior tickets and the parameters of an SoW, and context about related prior art will invent less unnecessary work from scratch, for the same reasons that a human engineer will make fewer wrong guesses if they have been properly briefed instead of thrown onto a project cold.
Sharing context as a project allows one person’s efforts to be turned into something valuable to the whole team. Writing an ADR while you are planning, rather than afterwards, fits naturally here too; you are already talking the plan through, so you might as well write down why.
AI makes bulk ticket creation easy, which is especially useful at the beginning of a project. Do keep an eye out for it creating scope creep, or non-specific tickets. It is better to prompt it to ask you what to do when it finds gaps in information, so that you can ask for more clarity from the client.
2. Build #
Build is where AI has had the biggest impact so far. There is a wide spectrum of AI usage across the team depending on the need, focus, and confidence. The right point on the spectrum depends on the task and how much you can trust the output for it, not on how advanced you are.
It is important to pick the right tool for the right job; but also to hold the space to experiment. People have successfully used AI to learn alongside building with AI, whilst others have given AI enough clarity during the planning phase, to leave AI to build fully on its own.
AI makes code cheap, but the amount of code it produces says nothing about its quality, so be selective about what you accept. Cheap code also means test suites and documentation are quicker to create. Keep documentation brief, simple and clear: it should be written for people to read.
Test suites and documentation are a non-negotiable, expected part of submitting work to a project. You should give AI details of your local environment and deterministic checks, so it can verify its own work as it goes and show you the proof.
Make sure the type and style of testing match the work produced. Not every change needs every kind of test; choose the ones that make sense for the work. Remember that testing isn’t only about proving the code does what it should; it’s also about checking that it can’t do what it shouldn’t.
3. Code Reviews #
The single most useful review habit, agent-written code or not, is asking whether it actually solves the problem; not just whether it matches the ticket.
If work is not reviewable, it is fair to give that critique back. Be wary of “review fatigue” and accepting long PRs because it’s too much effort to properly review. Pull requests that are too long make it hard to be able to pin down any issues. Ask for oversized PRs to be split. This keeps code reviewing manageable.
The point of using AI is to shrink the total effort a piece of work takes, not to shift that effort onto whoever reviews the work. Before reviewing manually, instruct AI to check for things such as test suites, documentation, coding standards, security vulnerabilities, translatable and accessibility labeling. The author should have already done this, but it is worth sending your AI agent to do a second pass.
Remember that code reviews are an opportunity for learning. It is an opportunity for you to critique and test the boundaries of the work, and for your teammates to do the same. You are responsible for solutions created with or without AI, and you are also responsible for what you approve.
4. Deployments #
Deployments are generally already actioned through other dedicated tooling. Most of what AI does here is trigger deployment tooling that already existed: such as pushing a change through a deployment pipeline, or running a CLI command. There is no need to force it to do more.
What matters more than who or what presses the button is what happens after. AI is genuinely useful for the review and testing that follows a release: running smoke tests and checks against the live site once It is out, watching logs and error tracking for anything new that correlates with the release, checking for things like unexpected 404s or broken pages, and comparing performance and response times against what you would expect. Doing this continuously with AI ensures that regressions in scaling or speed do not sit unnoticed.
None of that replaces your judgement. You decide whether what AI is flagging is real, and what to do about it. It is the same reviewer role, extended past the moment of shipping. It is important that you own the outcome as a whole piece, and not just the diff that produced it.
5. Debugging #
Debugging is methodical, detective-style work, ruling possibilities in and out, which suits how AI operates. By describing the bug, and giving AI the ability to explore the codebase, you are able to let AI work through the possibilities faster than you would get through them manually.
Your job is to judge what is useful, and whether the benchmarks and data it returns reflect the scenario your project or feature is in. Beware that AI can speak with a lot of confidence, and can produce outcomes that are plausible-sounding but do not hold up under scrutiny. As the reviewer, make sure everything it is telling you makes sense before you accept it as a fix.