8 Years With Laravel: What AI Coding Still Gets Wrong

AI can write Laravel controllers, generate migrations, build APIs, and even troubleshoot complex applications. But after eight years of working with Laravel, I believe the most important things AI gets wrong are rarely about syntax. They're about understanding the software it's building.

Imagine asking an AI coding assistant to build an API endpoint for retrieving customer invoices.

Within seconds, it generates something like this:

public function show(int $id)
{
    return Invoice::findOrFail($id);
}

The code is valid. Laravel understands it. The endpoint works.

Ask AI to write a test, and it can probably generate one that passes.

There's just one problem.

What happens when a logged-in customer changes the invoice ID in the URL?

If nothing else restricts access, the endpoint may return another customer's invoice.

AI didn't necessarily misunderstand Laravel. It misunderstood—or was never told—the business rule that customers must only access their own financial information.

And that's the distinction I've become increasingly interested in.

After approximately eight years working with Laravel, I don't think the most dangerous AI-generated code is code that throws an exception.

It's code that works perfectly while doing something the business never intended.

We're entering an era where generating software is becoming easier. Understanding what that software must protect, how it should behave under pressure, and how its decisions affect real people remains considerably harder.

AI Is Getting Better. That Makes Its Mistakes More Interesting.

We need to acknowledge something before criticizing AI coding tools: they have become genuinely useful.

They can explain unfamiliar code, propose refactoring strategies, generate test cases, assist with framework upgrades, and accelerate implementation.

And adoption is no longer limited to a small group of developers experimenting with new tools.

According to the 2026 Stack Overflow Developer Survey, approximately 66% of respondents use AI coding assistants or agents in their work.

But the same survey reveals something more interesting.

While 48% of respondents trust AI outputs when they can easily verify them, only 6.6% trust AI for many tasks that include important work decisions.

Developers are becoming comfortable using AI without becoming equally comfortable trusting it.

That is a meaningful difference.

Laravel itself is adapting quickly.

Laravel 13, released on March 17, 2026, introduced first-party AI capabilities, including the Laravel AI SDK, alongside improvements such as JSON resources and semantic search functionality.

On September 23, 2026, Laravel announced AI SDK v1.0, adding more mature functionality around agents, conversations, tool approvals, streaming, and usage reporting.

Laravel Boost has also evolved to help coding agents understand Laravel-specific and project-specific conventions.

These are significant improvements.

But better tools don't automatically eliminate bad engineering decisions.

In fact, as generated code becomes more convincing, developers may find the remaining mistakes harder to notice.

Here are the areas I think deserve much more attention.

1. AI Understands Laravel Conventions Better Than Business Boundaries

Let's return to the invoice endpoint.

An AI assistant understands that findOrFail() retrieves an Eloquent model or throws an exception.

What it doesn't automatically know is how ownership works in your application.

Maybe users belong to companies. Maybe a user can access multiple organizations. Maybe finance administrators have broader permissions. Maybe invoices must never cross tenant boundaries, even for internal users.

Those rules cannot be inferred reliably from a generic request to build an invoice API.

In a simple single-tenant-per-user application, a safer approach might look like this:

public function show(Request $request, int $id)
{
    $invoice = Invoice::query()
        ->where('tenant_id', $request->user()->tenant_id)
        ->findOrFail($id);

    Gate::authorize('view', $invoice);

    return new InvoiceResource($invoice);
}

Illustrative Laravel 13-compatible controller code. It assumes an authenticated route, non-null authorized tenant membership, a correctly configured policy, and an InvoiceResource class.

The query restricts which tenant's invoices can be retrieved. The policy verifies whether the user may view the particular invoice.

In an application supporting multiple company memberships, the tenant must be resolved from an independently authorized active-tenant context rather than trusting a tenant ID supplied by the request.

Laravel already provides excellent authorization mechanisms through policies and gates.

The difficult part is knowing which business rules the authorization must represent.

AI might generate authorization code when asked.

But a developer should recognize that authorization is necessary even when nobody explicitly mentions it.

The mistake isn't always what AI writes. Sometimes it's what AI never asks about.

For businesses, this distinction is critical.

An incorrect label in an interface is inconvenient. An incorrect tenant-access rule can become a serious privacy incident.

2. AI Often Solves the Request, Not the Actual Problem

Imagine a client asks:

"Add a refund button to the admin dashboard."

AI can produce that feature quickly.

A route, controller, form, database update, and confirmation message might all be generated in one session.

But the real engineering questions begin after the button appears.

Should refunds be allowed after 30 days? What happens when an order has already been partially refunded? Can support staff issue refunds without financial approval? Does the payment provider support the requested currency? What happens if the request is submitted twice?

These are not advanced Laravel questions.

They are business questions.

And each one may change the technical implementation.

A naive solution might simply update an order's status to refunded.

A production implementation may need to calculate the remaining refundable balance, enforce role-based permissions, coordinate with a payment gateway, and record an audit trail.

Even money representation matters.

For many financial applications, storing minor currency units as integers avoids common binary floating-point issues. But that convention needs to account for currency-specific decimal precision and business rounding rules.

A confident AI-generated implementation can still be wrong if the underlying requirements are incomplete.

This is where I think experienced developers deliver disproportionate value.

We don't just translate requirements into code.

We identify the requirements that haven't been expressed yet.

The strongest question is often not "How should we implement this?"

It's "What must never happen when someone uses it?"

3. AI Can Write Tests That Prove the Wrong Thing

I like AI-assisted test generation.

It's useful for generating boilerplate, exploring edge cases, and making repetitive test-writing less tedious.

But there's a problem when AI generates both the implementation and the tests.

It may test its own assumptions rather than the actual requirements.

Return to the invoice example.

An assistant might write a test that creates an invoice, requests it by ID, and expects a successful response.

The test passes.

But that doesn't prove the endpoint is secure.

I would want an additional test that checks the access boundary:

public function test_user_cannot_view_another_tenants_invoice(): void
{
    $user = User::factory()->create([
        'tenant_id' => 1,
    ]);

    $invoice = Invoice::factory()->create([
        'tenant_id' => 2,
    ]);

    $this->actingAs($user)
        ->getJson("/api/invoices/{$invoice->id}")
        ->assertNotFound();
}

Illustrative PHPUnit feature test. It assumes the specified factories, imports, authenticated API route, tenant setup, and a query that hides out-of-tenant invoices with a 404 response.

A policy-only implementation might intentionally return 403 Forbidden instead. The test should reflect the application's actual access-control contract.

What matters is testing the boundary, not merely checking that the endpoint responds.

For important business workflows, I want tests that answer questions such as:

• Can someone access another customer's data?

• Can the same transaction run twice?

• Can an unauthorized user approve a sensitive action?

• Does an interrupted workflow recover safely?

• Will invalid data be rejected before an external operation?

AI can help generate these tests once the risks have been identified.

But I wouldn't let the model's own implementation become the only specification for correctness.

A passing test is evidence that certain expectations were met. It isn't proof that the right expectations were chosen.

4. AI Doesn't Always Respect the Boundaries Between Transactions, Queues, and External Services

Laravel queues are powerful.

They help applications process emails, notifications, imports, reports, and other background tasks without making users wait for everything to finish inside an HTTP request.

AI knows how to generate queued jobs.

But it may not fully account for when those jobs should execute.

Consider creating an order and dispatching a confirmation job inside a database transaction.

Without the correct configuration, a queue worker may attempt to process the job before the transaction has committed.

The record might not yet be visible to that worker.

Laravel addresses this with after-commit dispatching.

For example:

DB::transaction(function () use ($order) {
    $order->update([
        'status' => 'confirmed',
    ]);

    SendOrderConfirmation::dispatch($order)
        ->afterCommit();
});

Illustrative Laravel 13-compatible code. It assumes the order has already met the business conditions for confirmation and that the job is implemented.

The job is dispatched after the database transaction commits.

But this doesn't solve every reliability problem.

What if the same operation is initiated twice? What if the job fails after an external service has already accepted a request? What if a payment succeeds but the application's database update fails?

Those scenarios require additional design decisions, including idempotency keys, uniqueness constraints, retries, recovery procedures, and sometimes transactional outbox patterns.

Laravel provides the building blocks.

AI can assemble them.

But developers must decide what guarantees the workflow actually needs.

For a newsletter notification, an occasional duplicate may be manageable.

For a financial transaction, duplicate execution can have immediate consequences.

The architecture should reflect that difference.

5. AI Can Produce Fast-Looking Code That Becomes Slow Under Real Traffic

One of Laravel's strengths is how naturally Eloquent expresses relationships.

Consider:

$orders = Order::latest()->paginate(50);

Nothing is inherently wrong with this query.

But imagine the frontend renders each order with:

$order->customer->name

If the customer relationship has not been loaded, this can produce additional database queries as each order is processed.

It's the familiar N+1 query problem.

For this scenario, the query could be improved:

$orders = Order::query()
    ->with('customer')
    ->latest()
    ->paginate(50);

Laravel already provides eager loading and mechanisms to detect unintended lazy loading.

AI assistants can explain and often identify these issues.

The problem is that performance requirements are frequently missing from the original task.

A feature can work perfectly with five records and behave very differently with hundreds of thousands.

Before accepting AI-generated database code, I'd want to understand the expected data volume, relevant indexes, filtering strategy, pagination, and query behavior.

Sometimes the answer is eager loading.

Sometimes it's a better database index.

Sometimes it's cursor pagination, caching, or moving expensive processing outside the request lifecycle.

And sometimes the simplest existing query is already good enough.

Performance engineering is about understanding workload and tradeoffs, not automatically introducing whichever optimization looks most impressive.

A slow endpoint affects more than a benchmark.

It can increase infrastructure costs, frustrate customers, and complicate operations as a business grows.

6. AI Sometimes Adds Architecture Instead of Reducing Complexity

Ask an AI assistant to design a maintainable Laravel application and you may receive a sophisticated proposal involving repositories, interfaces, services, actions, events, DTOs, and multiple abstraction layers.

None of those patterns is inherently wrong.

But they aren't automatically necessary either.

Laravel already includes an expressive ORM, service container, queues, event system, authorization tools, and other useful abstractions.

Adding a repository interface around every Eloquent model simply because it resembles an enterprise design pattern may create more files without meaningfully improving maintainability.

On the other hand, a dedicated integration boundary around a payment provider may be extremely valuable.

The difference is the reason the abstraction exists.

Does it isolate external behavior? Protect a business invariant? Reduce duplication? Make testing or replacement easier?

Or does it simply make the architecture look more elaborate?

I would rather maintain a straightforward Laravel application with clear responsibilities than a complicated system built to satisfy an abstract definition of clean architecture.

This is an area where context-aware AI tools can make a real difference.

Laravel's own engineering team has discussed how coding agents can repeat unwanted project patterns, including unnecessary repository layers.

Its September 2026 article, Semantic Memory or Just Markdown?, explains an approach to preserving project-specific conventions using concise, scoped rules.

That's an important direction.

Because the best architectural suggestion isn't necessarily the most sophisticated one.

It's the one that fits the application.

7. AI Can Misread What's Current, Supported, or Appropriate

Laravel evolves quickly.

Packages change. PHP versions advance. Framework APIs improve. Documentation gets updated. New capabilities become available while older approaches remain scattered across tutorials and repositories.

Laravel 13 requires PHP 8.3 or newer. Laravel's official release notes also document the support policy and framework changes.

An AI model may nevertheless recommend code or dependencies based on an older Laravel version, particularly when it lacks access to the project's actual environment.

It might suggest an outdated package, assume an API exists in the installed version, or recommend a migration path without checking dependency constraints.

This is partly why Laravel Boost is useful.

Boost provides Laravel-aware tools and version-specific guidance, helping coding agents work with the application rather than relying only on general training knowledge.

But even with better context, upgrades require verification.

I would still check the actual installed versions, official upgrade documentation, Composer constraints, test results, and deployment environment.

Tools such as composer audit, composer outdated, and composer check-platform-reqs can assist with dependency reviews.

For agencies and businesses maintaining multiple applications, an incorrect dependency recommendation can become expensive.

The lesson is simple:

AI-generated technical confidence is not a substitute for checking the actual installed software.

8. AI Doesn't Know What a Mistake Will Cost the Business

A coding assistant can optimize a function, suggest a refactor, and generate a complete implementation.

But it doesn't automatically know the consequences of a particular failure.

Consider two hypothetical bugs.

One causes an incorrectly formatted date in an internal dashboard.

Another sends customer information to the wrong organization.

Both are software defects.

Their consequences are very different.

This changes how much validation, monitoring, and review each feature deserves.

The same principle applies to AI-powered features inside Laravel applications.

Laravel AI SDK v1.0 supports human tool approvals and other controls that help developers build more carefully governed agent workflows.

But enabling an approval mechanism is only part of the solution.

The application must still decide which operations require approval, whose approval is valid, what data an agent can access, and how completed operations are audited.

For example, an AI agent that classifies support tickets may be allowed to recommend priorities automatically.

An agent capable of issuing large refunds or deleting customer records should operate under much stricter controls.

The OWASP Top 10 for LLM Applications provides useful guidance on risks such as prompt injection and excessive agency.

This isn't an argument against automation.

It's an argument for designing automation around the consequences of failure.

Clients don't buy software because its code is elegant.

They buy software because they expect it to deliver a business outcome reliably.

That distinction should influence every important engineering decision.

What Eight Years of Laravel Development Has Taught Me

One of the most valuable things experience gives a developer is a different understanding of what deserves attention.

Early in development, it's easy to focus on implementation.

How do I write this controller? Which Laravel method should I use? How do I make the API return the right response?

Those skills still matter.

But as applications grow, the more difficult questions often exist outside the immediate code.

Who is allowed to perform this action? What happens when the process fails halfway through? What existing behavior depends on this change? Will another developer understand this implementation? Is the complexity justified?

These are the questions I think AI-assisted development should make us ask more often, not less.

After eight years working with Laravel, my perspective is that writing code is only one part of software engineering.

The larger responsibility is making choices that remain reasonable when requirements change and the application becomes more important to the business.

That means knowing when to introduce an abstraction and when to avoid one.

When to trust a framework convention and when business rules require something more specific.

When a passing test is sufficient and when the test itself needs to be questioned.

And when a feature is technically complete but not yet ready for production.

AI changes how quickly we can implement decisions.

It doesn't remove the responsibility for making them.

The Review Process I'd Use for AI-Generated Laravel Code

I don't think every AI-generated line needs the same amount of scrutiny.

A text formatting helper and a payment-processing workflow should not require identical review processes.

Instead, I'd use a risk-based approach built around six questions.

1. Does the code respect our business rules?

Check the assumptions AI made. Look especially for missing requirements around permissions, ownership, financial limits, and state transitions.

2. Does it fit our existing architecture?

Make sure it uses established project conventions rather than introducing unnecessary patterns.

3. What happens when something fails?

Review retries, transactions, duplicate execution, invalid inputs, timeouts, and external service failures.

4. Does it behave correctly at realistic scale?

Inspect database access, eager loading, pagination, caching, queue usage, and possible performance bottlenecks.

5. What proves the implementation is correct?

Run meaningful tests. Add negative scenarios and boundary cases. Don't rely only on tests generated from the same assumptions as the implementation.

6. Can another developer maintain it?

Review names, dependencies, documentation, operational visibility, and the complexity introduced by the change.

AI can participate in all six steps.

But the review should be based on the application's needs, not the model's confidence.

The Counterargument: AI May Get Much Better at All of This

There's a legitimate argument that many of these weaknesses are temporary.

Coding agents are improving their ability to inspect repositories, use external tools, run tests, understand project conventions, and perform multi-file changes.

Laravel Boost's project-aware guidance is one example of that progress.

And we should be careful about drawing sweeping conclusions from productivity research.

A 2025 METR randomized study found that experienced open-source developers completed certain repository tasks 19% more slowly when allowed to use early-2025 AI tools.

But in a February 2026 follow-up, METR explained that selection effects made its newer measurements unreliable, while suggesting that AI tools may have become more helpful.

The lesson isn't that AI is slow or fast in every situation.

It's that productivity depends on the tools, tasks, developers, and environment.

The 2025 DORA research similarly emphasizes that AI can amplify existing organizational strengths and weaknesses.

I expect coding agents to become substantially better at understanding architectural context and identifying defects over the next 12–24 months.

That is a prediction, not a guarantee.

But even if they become excellent at implementing requirements, organizations will still need to establish which requirements matter, who accepts risk, and what qualifies as a successful business outcome.

Those responsibilities may become more automated.

They won't simply disappear.

My Prediction: The Best Laravel Developers Will Become Better Decision-Makers

I don't believe Laravel developers should compete with AI on the number of controllers they can produce in an hour.

That's increasingly the wrong competition.

The more valuable skills will involve understanding software systems deeply enough to direct and validate increasingly capable tools.

Architecture. Authorization. Data modeling. Business processes. Performance. Testing. Security. Reliability. System integration.

And perhaps most importantly, communicating with clients and stakeholders well enough to uncover the requirements that a feature request leaves unsaid.

For experienced developers, that creates an opportunity.

We can spend less time on repetitive implementation and more time protecting the quality of the system.

For newer developers, it creates a challenge.

When AI can generate working code before someone fully understands the underlying framework, it's tempting to skip the fundamentals.

But understanding what Eloquent actually queries, how Laravel authorization works, when queued jobs execute, and why database transactions matter is precisely what helps developers evaluate AI-generated output.

Learning Laravel is still valuable.

The reason for learning it is becoming more important.

Frequently Asked Questions

1. Is AI-generated Laravel code reliable?

It can be, particularly for well-defined tasks. However, generated code still needs review for security, business logic, compatibility, performance, and failure handling. Correct syntax and passing tests don't automatically establish production readiness.

2. What mistakes does AI commonly make in Laravel applications?

Potential mistakes include missing authorization checks, incorrect assumptions about business rules, inefficient Eloquent queries, unsafe handling of retries, unnecessary architectural complexity, and recommendations based on incompatible package or framework versions.

3. Can AI understand an existing Laravel codebase?

Yes. Modern coding agents can inspect project files and use tools such as Laravel Boost for better framework-specific context. However, implicit business rules and undocumented architectural decisions may still be missed.

4. Should Laravel developers use AI for production applications?

Yes, when the development process includes appropriate review, testing, security checks, and deployment controls. AI is useful for implementation, refactoring, documentation, debugging, and maintenance, but its output should be validated according to the consequences of failure.

5. Will AI replace experienced Laravel developers?

AI will continue changing the work developers perform, especially repetitive implementation tasks. The extent of future automation remains uncertain. Business understanding, system design, security, reliability, and accountability are still important engineering responsibilities.

6. How can I improve the quality of AI-generated Laravel code?

Provide accurate project context, framework-version information, architecture conventions, business rules, and acceptance criteria. Use automated tests, review database behavior and authorization boundaries, and verify important implementation details against official Laravel documentation.

Final Thoughts: The Problem Isn't That AI Writes Bad Code

The more interesting problem is that AI can write convincing code for a problem it doesn't completely understand.

And sometimes we don't completely understand that problem either.

That's why I don't think the future belongs exclusively to developers who write code fastest or to those who use the most sophisticated coding agents.

It belongs to developers who can recognize what's missing.

The authorization rule that nobody mentioned.

The database query that works with ten records but struggles with ten thousand.

The retry that accidentally repeats a payment.

The unnecessary abstraction that makes future changes harder.

The passing test that validates the wrong business assumption.

AI can help solve all of these problems when they're identified and described properly.

The real skill is recognizing which problems exist in the first place.

After eight years with Laravel, that's what I believe separates writing code from engineering software.

AI is getting better at knowing how to build things. Experienced developers still need to understand what should be built, why it matters, and what must never go wrong.

And that leaves me with a question for other developers:

What's the most important thing you've learned to question in AI-generated code that you might have accepted without hesitation earlier in your career?