Can AI Agents Write Production Laravel? A Code-Review Policy for AI-Assisted Teams

Can AI write production code is the wrong question, and it is the one boards keep asking. AI is already writing code in your Laravel codebase, because your developers are using it, and a policy of disapproval simply means it happens without review discipline.

The useful question is narrower: what does it get wrong on this specific framework, and what must a reviewer therefore check? Laravel is a good case study, because its conventions are strong, its documentation is excellent, and its training representation is enormous — which produces a distinctive pattern of confident, idiomatic, occasionally dangerous output.

Where It Reliably Helps

Being specific matters, because a blanket policy in either direction is wrong.

• Boilerplate with a strong convention — resource controllers, form requests, factories, seeders, API resources. Laravel's conventions are so well represented that output here is usually correct and stylistically consistent.
• Test scaffolding. Generating the cases you would have written but might not have bothered with, especially edge cases around validation.
• Mechanical refactors applied across many files — renaming, extracting, updating a deprecated call. Tedious, low-judgement, easy to verify.
• Explaining unfamiliar code. Genuinely valuable on an inherited codebase, and it carries no shipping risk at all.
• Migrations and schema definitions from a described model — verifiable by reading, and wrong in obvious ways when wrong.

Where It Fails, Predictably

These are the patterns we see repeatedly, and they are what a review policy needs to target.

1. Query Patterns That Work and Do Not Scale

N+1 queries are the signature failure. Generated code that loops a collection and accesses a relation inside the loop is correct, readable, passes its tests against a factory-built dataset of ten records, and falls over on production data. The model has no way to know your orders table has nine million rows.

2. Authorisation Assumed Rather Than Enforced

Generated controllers frequently omit the policy check, or place it where it is easy to bypass. This is the single highest-risk category, because the code works perfectly for the developer testing it as an administrator.

3. Old Idioms From Old Training Data

Training data skews towards what has been written most, which is not the same as what is current. On a framework with a decade of blog posts behind it, that means output written against conventions from several major versions ago — deprecated helpers, outdated validation syntax, patterns replaced by first-party features. It looks plausible because it was correct, once.

4. Mass Assignment and Input Trust

Generated code passes request input straight into model creation more often than it should. Laravel's guarding makes this survivable, but only if the model is actually configured, and generated models are frequently not.

5. Multi-Tenant and Scoped Contexts

If your application scopes data per tenant, per organisation or per brand, generated code will not know unless the surrounding code makes it structurally impossible to forget. This is a strong argument for enforcing scoping in the database or the base model rather than by convention — a point we make at length in multi-tenant Laravel architecture.

6. Confident Invention

Method names on your own classes that do not exist, package APIs that were never released, config keys that sound right. Fast to catch — it fails immediately — but it wastes review time and it erodes the reviewer's attention for the failures that do not announce themselves.

The Review Policy

Short enough that people follow it.

1. Authorship is disclosed. A pull request states whether it was substantially AI-generated. Not to shame anyone — to tell the reviewer where to look.
2. The author has read every line. This is the whole policy in one sentence. Submitting code you have not read is the failure mode; the generator is incidental.
3. Four mandatory checks on generated code: query behaviour against production-scale data, authorisation, input validation and mass-assignment, and tenant or scope context.
4. Static analysis is not optional. PHPStan or Psalm at a level your codebase actually holds, in CI, blocking. Machine-generated code deserves machine-enforced standards.
5. Tests must be written or verified by a human. An agent that writes both the code and the test can produce a matched pair that agree with each other and disagree with the requirement.
6. Nothing generated goes near the security boundary unreviewed by a second person. Authentication, authorisation, payment handling, anything touching personal data.
7. Migrations and destructive operations get a human author. A generated migration that drops a column is exactly as convincing as one that adds one.

Make the Codebase Easier to Get Right

The most effective intervention is not reviewing harder. It is making the wrong thing hard to write, which helps human contributors identically.

• Enforce authorisation structurally, so a controller action without a policy check fails rather than silently permits.
• Enforce tenant scoping in the base model or the database, so an unscoped query throws.
• Keep strict types and a high static-analysis level. Both dramatically narrow the space of plausible-but-wrong code.
• Maintain real conventions documentation in the repository. Agents read the repository; a codebase that documents its own patterns gets better output, and so do new hires.
• Keep the codebase idiomatic. Consistency is now a machine-legibility property as well as a human one — an unusual pattern gets unusual output.

That last point is the genuinely new argument. Conventional code and good documentation used to be a nicety justified by onboarding speed. They are now a direct input to the quality of a substantial share of the code being written, which makes them an economic argument rather than a stylistic one.

Measuring Whether It Actually Helps

Vendors sell a productivity multiple. Measure your own, because the honest answer varies enormously by task type.

• Cycle time from first commit to merged, not lines produced. Lines are an anti-metric here.
• Review burden — time spent reviewing, and iterations before approval. If review time rises more than authoring time falls, you have moved cost, not saved it.
• Defect rate per merged change, tracked separately for AI-assisted and human-authored work.
• Rework rate — how often merged code is materially rewritten within a month.
• Where the gains are concentrated. Our experience is that they are real and large on boilerplate and tests, small on domain logic, and occasionally negative on anything requiring knowledge of your specific system.

Track it for a quarter before you let it change your capacity planning. A team that has assumed a productivity multiple and staffed against it has made an expensive bet on a number nobody has measured.

This is the governance work our Laravel team applies on client codebases, and it sits alongside the broader question of where AI genuinely earns its place in delivery — the subject of our AI integration practice and AI engineering team. The same failure pattern shows up more sharply on older code: see why AI coding agents are fluent in PHP 7 idioms.

Adopt the Policy, Then Measure

We will help you put the review policy and the structural guardrails in place, and set up the measurement that tells you whether any of it is paying. Talk to our team; we reply within a business day.