AI-assisted software development: why human review makes the difference

Anyone can buy an oven, flour and a sourdough starter. Not everyone bakes good bread.

Software development is living through exactly that moment. AI coding assistants are available to everyone, often for a monthly subscription, and any agency can now say it "builds with AI". That is true, and it tells you nothing. The question is no longer who owns the oven. It is who knows how to use it, and above all, who tastes the bread before selling it.

This article sets out the method we follow at LPR Studio, step by step, and the questions worth asking any software supplier that talks to you about AI.

What AI really changes, and what it does not

An AI coding assistant writes code quickly, often well, and sometimes completely wrong with the same confidence. In a few minutes it can produce a screen, a pricing rule or a set of tests that would have taken half a day. It can also call a function that does not exist, weaken a security check to make a test pass, or fix one bug by creating another three screens away.

None of that shows up in a demo. All of it shows up in production, when the software handles your real data, with your real users, on a Monday morning.

So the core of the job has not changed: understanding the need, deciding what should be built, and checking that what was built is right. AI has made writing code abundant. It has made verification the scarce part, and that is now where a supplier's value lies.

Research points the same way. A study of 278,790 code review conversations across 300 open source GitHub projects, Human-AI Synergy in Agentic Code Review (Zhong, Noei, Zou and Adams, 2026), found that AI reviewers' suggestions were adopted significantly less often than human ones, that over half of the unadopted AI suggestions were wrong or fixed differently by developers, and that reviews of AI-generated code needed 11.8% more rounds. The authors' conclusion: AI can scale defect screening, but human oversight is still needed for quality and context.

What AI does well in a project

Being clear about where AI helps avoids both hype and dismissal. In our projects it earns its keep on:

• first drafts of screens, forms and data models, which a developer then shapes;
• repetitive changes across many files, such as renaming a field or applying a new convention everywhere;
• tests, which it writes quickly once the expected behaviour is stated;
• reading unfamiliar code, for example an old application to be replaced, and summarising what it really does;
• prototypes, where speed matters more than polish and nothing goes to production.

It is weaker at deciding what matters to your business, judging trade-offs between two valid designs, and noticing what nobody asked for. Those stay with people.

Our method: write fast, check three times

1. Scoping stays human

No AI knows what your business needs. Every project starts with a conversation with you, then a visual prototype presented within 5 working days, free and with no commitment. You use that prototype to validate the screens, the user journeys and the business rules. AI helps us build it fast; you decide whether it is right.

2. The agent works within written rules

A developer joining a team first reads its house rules: conventions, mistakes already made, things never to do. We impose the same on AI agents. Every project carries a rules file, read at the start of every working session, which fixes the architecture, the prohibitions and the errors already made once. A corrected mistake becomes a rule, so it does not come back on the next project.

That is the baker's recipe. On its own it does not guarantee good bread, but without it every batch is a gamble.

3. Machines check the machine

Every change then goes through a chain of automated checks that do not negotiate: static analysis, strict typing, end-to-end tests that drive a real browser, and a full build of the application. One failing check, and the change goes no further. These checks run on our own continuous integration servers, on every change, without exception.

Automated checks are cheap to run and impossible to talk round. They are the first line of defence against the confident mistakes AI makes.

4. A second AI reviews the first

A model reviews its own work poorly: it repeats, while reviewing, the blind spots it had while writing. So every change is reviewed by a second model, from a different vendor, whose only job is to find what is wrong: missed edge cases, security flaws, inconsistencies with the rest of the codebase. Its comments are dealt with one by one before anything moves on.

That is our double check. It replaces nobody; it hands the developer code already cleared of the most visible defects.

5. A human decides, and checks production

No change goes live until a developer has read it, understood it and approved it. They answer for the result, not the tool. After every release, the pipeline is followed to the end and the site or application is checked in production. The baker tastes the bread before opening the shop, not after the first complaints.

What the method means for you

Short timelines without shortcuts. AI writes fast; the checks make sure speed is not paid for later. That is what lets us show a prototype in five working days, then deliver the application on timelines that traditional development struggles to meet.

The time saved goes to you. Under time and materials (T&M), a faster developer simply bills fewer days, so the agency has little incentive to speed up. We do not sell hours or staff. Under a fixed price or a subscription, the price is agreed before the first line of code, and AI productivity pays for more testing and more review, not more invoices. The trade-offs between the two models are covered in fixed price vs time and materials.

Code that can be maintained. Code generated without rules quickly becomes unreadable, even for the AI that wrote it. The conventions imposed on the agent and the human review produce code any developer can pick up, which matters from the first year of maintenance onwards.

A method proven on our own products. We apply it first to the software we publish and run ourselves, such as Izi-Devis and Tubissime, before applying it to client projects. We also contribute to Hermes Agent, an open source AI agent, where every proposal goes through review by demanding maintainers.

Where AI-assisted development goes wrong

Most failures we see in AI-built software come from skipping one of the steps above, not from the AI itself.

• No rules, no memory. Each session starts from scratch, so the same mistake is made on Monday and again on Thursday.
• Tests written by the same AI, to pass. An agent asked to make a test pass will sometimes change the test rather than the code. Tests need to be reviewed like any other code.
• Review by the author. Asking the model that wrote the code whether it is correct mostly returns "yes".
• No production check. The change passed the pipeline, so nobody looked at the live site. The first person to notice is a customer.
• Security as an afterthought. Access rules, secrets and personal data need a human eye on every change that touches them. Our security checklist for AI-built apps lists the usual gaps.

Questions to ask a supplier that "does AI"

Whether you work with us or with someone else, these questions quickly separate the baker from the oven reseller.

• Who reviews the code before it goes to production? If the answer is "the AI is very reliable", walk away.
• Which automated checks block a change? Tests that run "now and then" block nothing.
• What happens when the AI gets it wrong? A serious team has a precise answer, because it happens every week.
• How are you paid? If it is by the hour or the day, ask who benefits from the time saved.
• Can I see the software before I sign? With AI, showing a prototype costs almost nothing. A supplier who refuses has no excuse.
• Who owns what is delivered? Ownership of code, including code written with AI, should be settled in writing; with us, rights are defined case by case in the contract.

In the end, AI has not changed what you should expect from a good craftsman. The oven has become more powerful, and within everyone's reach. The bread is still judged by tasting it, and that is exactly what the free prototype offers you.