Vibe coding works well at first. The problems start once the project is in production and something breaks. That’s when you find:
- Code nobody remembers writing and nobody understands.
- No tests covering that code.
- Fear of touching anything, because you don’t know what will break.
Agentic engineering is the alternative. It is a set of tools and practices for using AI (artificial intelligence) in an integrated, controlled way across the whole project. Three stand out in the Laravel ecosystem: Laravel Boost, Pest 5, and Rector.
Two very different ways of using the same AI
Vibe coding is conversational. You describe what you want, accept what comes out, and iterate until it works. It is very fast for prototyping, but it uses a lot of resources: the model has to work out the code’s relationships and logic, and it rarely knows the whole project. We are not against it. At Volcanic we have used it, and that is why we know its limits.
Agentic engineering is a different thing. It is not only about writing code faster: it is about keeping the project coherent. The agent writes code within clear limits, validates its own output automatically, and leaves a person in control at every step. Even so, each team decides how much AI to use and when.
Laravel Boost: real context for the agent
When an agent does not know your project, it invents class names. Sometimes it also invents database columns or tables. This is called hallucination.
To avoid it, we use Laravel Boost, an official package that gives a generalist agent context about your application.
Boost exposes an MCP server (Model Context Protocol: the standard that connects AI agents to external tools) with more than 15 tools: Eloquent model introspection, database schema, routes, Tinker, and logs. It also includes a documentation API (a way for two pieces of software to talk to each other) with more than 17,000 snippets from the Laravel ecosystem. Search is semantic and tuned to the versions you have installed. With Boost, the agent stops guessing.
Boost also stores your team’s conventions. The record-rule tool writes them to .ai/rules,
under version control. A rule such as “amounts are stored as integers in cents, never as floats” stops being a
comment on a code review and becomes a system-level constraint. In practice, that file is the team’s memory.
Pest 5: tests that verify the agent
For tests, we use Pest 5. Pest 5 brings 3 pieces that change the workflow.
The Agent plugin gives the agent a command to check whether its change really works. The command
runs inside the real test environment, with factories, RefreshDatabase, and Laravel’s fakes.
The TIA engine (Test Impact Analysis: it detects which tests a change affects) reruns only the affected tests and replays the rest from cache. Coverage loses no fidelity. Laravel Cloud’s suite, with more than 19,000 tests, went from 3 minutes to 5 seconds.
The Evals plugin scores the output of an LLM (large language model) with the same familiar
expect() API. It combines deterministic checks with LLM-as-judge scorers, where another model evaluates
the response: toBeRelevant(), toBeFactual(), toBeSafe(),
toHaveToolCalls(), and toFollowTrajectory(). Evals only run when you pass
--evals, so they do not slow down everyday CI (continuous integration).
Rector + agent: what’s mechanical and what isn’t
On legacy projects we combine 2 tools. Rector handles the mechanical, deterministic transformations: version upgrades, typing, and syntax normalisation. The agent only steps in where Rector cannot reason. For example: extracting a service from a 900-line controller, breaking a circular dependency, or writing the missing tests before touching anything. Pest 5 already ships first-party plugins for Rector and PHPStan, so all 3 pieces live in the same command.
What a person always reviews
None of these tools replaces human review. Our rule is simple: the agent can propose any change, but 3 kinds of change need a named person’s sign-off.
- Migrations that touch existing data.
- Changes to authentication, permissions, or payments.
- Any access to personal data.
There is one more rule, less exciting but just as important: the agent has no production credentials. It always works against development environments with anonymised data. On a client project, that is not a technical preference: it is compliance.
Should you use agents in your Laravel project? 5 questions
Answer these 5 questions before you invest a single euro.
- Do you have tests? If you don’t, start there. An agent without a test suite generates technical debt very quickly.
- Do you know how long a change takes to reach production today? Measure that time before you start. Without a baseline you cannot calculate ROI (return on investment): you only have impressions.
- Who signs off on each change? Define who approves what before you give the agent access.
- What data does the agent touch? If it touches personal, health, or financial data, the agent’s working environment changes completely.
- Is this a speed problem or a clarity problem? Agents speed up execution. If the scope is poorly defined, they execute it faster and worse. Define the scope first.
Did you recognise your team in any of these questions, especially the one about scope? Let’s talk. At Volcanic, we help teams running Laravel in production decide where to use agents and where not to. If that sounds like a fit, get in touch and we’ll take a look together.