When we started building Boost Benchmarks, we had one simple question: can an AI coding agent actually write correct Laravel code? Not syntax poetry, not beautiful code, just a real Laravel app doing the right thing, with real Pest tests to keep everyone honest.
For a while, the answer was up in the air. When we published our last blog post on which AI model is best for Laravel, the leading models cleared 16 of our 17 evals with 99.4% test accuracy using Boost. That was impressive, but the hardest tasks still caught them out.
Well, the number moved. With Laravel Boost supplying the framework context, today's frontier models GPT-5.6, Claude Fable 5 and Mythos 5, Gemini 3.x, and the rest now stroll through those same 17 tasks at or near 100%. The tests pass. The app works. We have our answer: yes, agents can write correct Laravel code.
That is a real milestone, and it means the old finish line has become the new starting line. So this post is really the story of where Boost goes after "can it pass?", and why the question on the other side is much more interesting. If you want to follow along, the Boost repo is the place to start.
AI coding benchmarks are saturating
It would be tempting to think this is just a Boost story, but it is not. The entire coding-benchmark world seems to have arrived at roughly the same place at roughly the same time. Usually, that is a good sign that it is time to ask a better question.
SWE-bench Verified, the headline coding benchmark for the field, has effectively saturated. The leading models now sit within a point or two of one another near the human-expert baseline, after hovering around 60% a year ago. Older suites like HumanEval stopped separating the leaders a long time back.
When every frontier model lands in the same narrow band, "did it pass?" no longer tells you very much. And, honestly, that is great news. The industry cleared the bar. Benchmarks have shelf lives, and when one reaches the end of its useful life, that is not an indictment of the benchmark. It means the problem got solved.
Our 17-eval suite has reached the same point. It did the job we built it to do. Now we get to raise the bar.
Why passing tests isn’t enough for AI coding agents
There is another part of the story worth saying out loud: a green test suite was always a proxy for "this is good code." It is a useful proxy—one I would much rather have than not have—but it has limits.
OpenAI stopped reporting SWE-bench Verified after an audit found that a large share of the problems had flawed test cases. Cursor showed that plenty of "successful" fixes came from models finding the known answer in GitHub or .git history instead of working it out, and scores fell sharply once that history was sealed away.
Boost is less exposed to those problems than most benchmarks. Every run starts with a fresh Laravel app; we do not tuck answers into .git, and we use architecture tests alongside the usual behavioral tests. Still, the broader lesson applies to us: passing our Pest suite proves that a model can satisfy it. It does not necessarily prove that the model writes Laravel the way an Artisan would.
That little gap between "works" and "belongs in this codebase" is where things start getting interesting.
The real work left in coding
Once framework correctness becomes the easy part, what is left for a coding agent to get really good at? The same thing engineers spend most of their time wrestling with: the business logic.
The hard, long-horizon work is rarely "please add a route" or "please make me another CRUD API." It is configuring a legacy system without knocking anything over. It is reimplementing a research paper, tracking down a gnarly failure, applying a security fix, or learning a domain with no neat framework convention waiting to save you.
The industry has started measuring that frontier more directly. Suites like Terminal-Bench use difficult, real command-line tasks where even the best models still fall well short. A focused Laravel eval cannot cover that ground, and it does not have to.
Boost has the same job it always had, but that job matters even more now: help the agent begin in the right place. Give it enough Laravel context so it can focus on the actual problem rather than rediscovering the framework on every run. That is the work we want to lean into.
The pivot: Correct code per token, and idiomatic Laravel over correct
Here is the pivot: once passing becomes table stakes, there are still two things that separate one agent from another. Conveniently, they are also the two things that determine whether an agent is actually pleasant to work with.
The first is correct code per token spent. If every model reaches the right answer, I want to know what it cost to get there. The spread is enormous: one model can spend an order of magnitude or two more than another on the same task and end up with nearly identical results.
Boost already records tokens and cost for every run. We are now pulling those numbers out of the footnotes and treating them as first-class metrics. The new north star is not only "did the agent pass?" It is "how little context did the agent need to pass?"
That changes how we think about everything we put into Boost. Every guideline, every MCP tool call, and every indexed document has to earn its keep. Did it reduce the number of tokens needed to produce correct code? If it did, great. If it did not, we should take a harder look. That gives us a way to make Boost measurably leaner with each release, and the whole ecosystem benefits.
The second is idiomatic Laravel, not merely correct Laravel. Imagine a controller that passes every test but drops in a raw query, ignores Route::resource(), hand-rolls its validation instead of using a form request, and skips $fillable. It works, but I still would not call it good Laravel.
Our architecture tests already catch some of this. Reference-free LLM-as-judge scoring is now good enough to catch much more, which means we can start asking "is this idiomatic?" without needing a golden answer to diff against. That opens up an entirely new kind of signal.
And "idiomatic" does not have to mean one person's mysterious sense of taste. Boost's official best-practices skill describes 19 concrete areas of convention: Cache::remember() instead of hand-rolled caching, form requests instead of inline validation, with() for eager loading, Route::resource(), and plenty more. Its very first rule is "Consistency First": before reaching for a supposedly better pattern, match the sibling files already in the application.
That is specific. It is checkable. And it gets us much closer to what we actually want: code an experienced Laravel Artisan would merge, produced with the least context necessary. Not simply code that passes, but code that belongs.
What’s next for Boost Benchmarks
We are experimenting. This is not a finished scoring system wrapped up with a bow.
The old question, "can an AI agent write correct Laravel code?", has been answered. Frontier models can already produce code that passes and works. Our experiments are now aimed at the harder, more useful version of that question: how efficiently can an agent get there, and how good is the Laravel it leaves behind?
The existing 17 evals are not going anywhere. They remain a valuable regression suite, telling us whether we broke something that used to work. Over the coming releases, we are exploring a new layer on top of that foundation:
- Token and cost as a headline metric, reported per eval and per model right alongside pass rate, so a guideline change gets judged on the efficiency of correctness, not just correctness.
- Idiomatic scoring layered on top of the existing Pest and architecture checks, a rubric pulled from the Laravel best-practices skill, scored so that gaming one axis cannot paper over the rest.
- Context tightening as the main engineering effort inside Boost itself: dropping redundant guidelines, tightening tool outputs, and indexing only what an agent actually needs. The original blog called this out as a goal, and the cost lens now makes it the goal.
We do not yet know the final shape of all this, and that is half the fun. We do know the principle: whatever we build next should measure something the frontier can still meaningfully improve, and it should reward the honest path instead of the shortcut.
The bottom line
We built Boost Benchmarks to find out whether AI agents could write correct Laravel code. With Boost, they can. I am proud that we got to watch that question turn from an open problem into a solved one.
Now we get to ask the fun question.
Not simply, "did the test go green?" But, "how many tokens did it take, and did the agent build this the way an Artisan would?" Correctness is the baseline. Efficiency and idiomatic Laravel are the new frontier. That is the next version of Boost we are experimenting toward, and I cannot wait to see where it takes us.
If you haven’t tried Laravel Boost yet, read the docs to get started.