AI-assisted, human-reviewed: how we ship faster without shipping slop

The short version

We use AI coding tools every day. They help us draft, test and refactor faster. They do not merge code. A senior engineer reviews every change before it merges, and that engineer owns the change from then on: if it breaks, they fix it, and if you ask why it works that way, they answer without opening a chat window.

That single rule does most of the work. “Slop” is code nobody really understands, written because it was cheap to generate. The cure is not to avoid the tools. It is to make sure nothing reaches your main branch that a person has not read, tested and taken responsibility for.

Where AI genuinely saves time

The gains are real, but they sit in specific kinds of work: tasks where the shape of the answer is well known and checking it is much faster than typing it.

• Scaffolding. Controllers, form requests, resources, DTOs, Go handlers and their wiring. The patterns already exist in the codebase, so the tool follows them and we check it did.
• Tests. Given a function and a list of cases we care about, a draft test file appears in seconds. We still decide which cases matter, and we read every assertion.
• Mechanical refactors. Renaming a concept across fifty files, splitting a large class, moving to a newer API. The test suite tells us whether behaviour stayed the same.
• Migration drafts. A first version of a schema migration from a description of the change. Drafts only: see the next section for what happens before one touches real data.
• Documentation. Handover docs, README sections, API descriptions and changelog entries, written from the code and then corrected by the person who wrote the code.
• Reading unfamiliar code. When we take over an existing app, asking “where is this value set” or “what calls this job” across a large codebase is faster with a tool. We confirm the answer in the code before we act on it.

In all of these, the engineer already knows what good looks like. The tool saves typing and searching, not thinking.

Where AI does not make the call

Some work looks like a good fit for generation and is not. The output can be fluent and still wrong, and here being wrong is expensive.

• Architecture. Where the boundaries go, what is synchronous and what is queued, which service owns which data. These choices depend on your business, your team and your budget. A tool can list options. A person who knows your constraints picks one and writes down why.
• Security-sensitive code. Authentication, authorisation, payments, tenant isolation, file uploads, anything that builds queries or shell commands from input. We write and review this by hand, line by line, whoever typed the first draft.
• Data migrations on production data. A schema change can be drafted. A migration that rewrites millions of real rows is planned by an engineer: tested on a copy of the data, with a backup, a rollback path and a check of the results.
• Anything the reviewer cannot explain. If the owner of a change cannot say why a line is there, the line does not merge. This rule catches most of the subtle problems: invented helper functions, outdated APIs, config keys that do not exist.

If nobody can explain a line, it is not ready to merge, however it was written.

The review rules we follow

We do not run a separate, lighter process for AI-assisted work. The rules are the ones we apply to every change, written down so nobody has to guess.

1. A named human owner. Every pull request has one engineer responsible for it. They can explain what it does, why, and what they checked.
2. The same review. A senior engineer reviews every change before it merges. “The tool wrote it” is never a reason to review less.
3. The same CI. Tests, static analysis and code style checks run on every pull request. Nothing skips them.
4. Tests are required. New behaviour comes with tests. Generated tests are read like production code, because a test that asserts the wrong thing is worse than no test.
5. Small pull requests. Generation makes large diffs cheap to produce and hard to review. We split work so each pull request can be read properly in one sitting.

A short checklist in the pull request template keeps this visible. The owner ticks it before asking for review.

## Owner checklist
- [ ] I can explain every line in this diff
- [ ] New behaviour is covered by tests I have read
- [ ] No secrets, credentials or client data in code or prompts
- [ ] Security-sensitive paths reviewed by hand
- [ ] Migrations tested on a copy of real data (if any)

The checklist does not prove anything on its own. It makes the owner stop and look, and it gives the reviewer a clear question to ask when something does not add up.

Your data, your NDA and your AI policy

Speed is only useful if it does not create a confidentiality problem. These rules apply on every project.

• Your code stays in your repositories. We work in your repos, not in copies on our side.
• Business terms only. We use Claude and ChatGPT, and only under business terms, never on consumer accounts.
• No secrets or client data in prompts. No API keys, passwords, production database dumps or personal data. We use fixtures and anonymised samples when a tool needs an example.
• Your policy wins. Some clients do not allow third-party AI tools on their code at all, or only approved ones. We ask at the start, follow the answer, and sign an NDA and DPA on request.

Licence and provenance awareness

Generated code can resemble code from public projects, and those projects come with licences. We treat suggestions the way we treat a snippet found online: if a block looks like it was lifted from a specific library, we use the library properly, with its licence, or we write our own version.

Dependencies go through the normal process too. A tool suggesting a package is not a reason to add it. We check that it exists, that it is maintained, and that its licence fits your project, because tools do sometimes suggest package names that do not exist.

What you get out of it

For you, the result is more of the budget going into the decisions that matter and less into boilerplate. It is part of how we get a first release out in 2 weeks. You get the same review, the same tests and the same senior engineers on the parts that carry risk. You can see the results in our recent work.

The same thinking applies when we build AI features into your product rather than use AI to build it: evaluations on real examples, a source for every answer and a person who approves what matters. That is the core of our AI automation service.

Summary

AI tools make good engineers faster at the parts of the job that were never the hard part. The hard parts stay with people: architecture, security, production data and ownership. Keep one rule, that every change has an owner who can explain it, and the speed comes without the slop. If you want a team that works this way on your product, send us a short brief.

Frequently asked questions