AI-driven development without the mess: the guardrails we use

We use AI coding agents on almost every project now. They write code, tests, migrations and documentation, investigate bugs and do the repetitive parts of upgrades. Used well, they let a small senior team deliver what used to take a much larger one.

Used badly, they produce codebases that work for a while and then become impossible to change. We see the results in our rescue and vibe code review work every week.

The difference is not which tool you use. It is the guardrails around it. These are the ones we use on client projects.

1. Make the codebase easy for an agent to understand

AI agents copy what they see. If a codebase has three different ways of doing validation, an agent will happily add a fourth. So before we scale up AI-assisted work on an existing app, we spend time on consistency:

• One way to validate input (Laravel form requests).
• One way to authorise actions (policies).
• One place for business logic (action or service classes, not controllers).
• Clear naming that matches Laravel conventions.

This pays off for human developers too, but it matters even more for agents.

2. Write the rules down

Most AI coding tools read a project instructions file, such as CLAUDE.md or AGENTS.md, before they start work. We keep one in every repository. It covers:

• the commands to run tests, static analysis and code style checks,
• the architecture and where different kinds of code belong,
• conventions the agent must follow, such as "every new endpoint needs a policy and a feature test",
• things it must never do, such as editing old migrations or adding packages without asking.

A good instructions file is short, specific and kept up to date. It is the cheapest quality improvement you can make.

3. Keep tasks small

Agents are at their best on tasks a person could review in a few minutes. "Add a CSV export to the orders page, with a test" works well. "Build the reporting module" does not.

Small tasks are easier to describe precisely, easier for the agent to get right and, most importantly, easier for an engineer to review properly. A 2,000-line pull request will not be reviewed carefully, whoever wrote it.

4. Tests first, or at least tests always

The best way to tell an agent what you want is often a failing test. The best way to check its work is a passing one. Every change we accept from an agent includes tests, and the full suite must pass before review.

For older codebases with few tests, our first job is usually to add tests around the most important behaviour. That makes every later change, by person or agent, safer.

5. Let the machines check the machines

Automated checks catch a surprising share of agent mistakes before a person ever looks:

• Static analysis with Larastan finds type errors, missing methods and dead code.
• Code style with Laravel Pint keeps formatting consistent, so reviews focus on substance.
• Dependency audits with composer audit and npm audit flag vulnerable or suspicious packages.
• CI runs all of the above on every pull request.

If the checks fail, the agent fixes them before anyone reviews the change.

6. A senior engineer owns every change

This is the rule that matters most. An agent can write a change, but a named engineer reviews it, understands it and is accountable for it. Reviews focus on what tools cannot check well:

• Does it do the right thing? Not just what the ticket literally said.
• Is it secure? Authorisation, data exposure and input handling in particular.
• Does it fit? Is it consistent with the rest of the codebase, or a new pattern in disguise?
• Will it scale? Query counts, memory use and behaviour with real data volumes.

If an engineer cannot explain a change, it does not ship.

7. Protect production and personal data

Agents work in development environments with test data. They do not get production database access, production secrets or real customer data. Where we use AI services for analysis or code generation, we check that the provider's terms fit the client's data protection obligations.

What this means for cost and speed

These guardrails take some effort to set up, but they are what make AI-assisted development cheaper over time, not just faster in the first week. A consistent, tested codebase lets agents do more of the work safely, which is how we keep our rates at £20 to £25 per hour while every change still gets senior review.

If you want to adopt AI-driven development in your own team, or want us to work this way on your project, see our AI-driven development service. If you already have an AI-built app and are worried about what is in it, start with our production checklist for vibe-coded apps.