There's a particular kind of disappointment in pasting "build me a booking system" into an AI agent and watching it confidently produce 600 lines of code that solves a problem adjacent to the one you have. The model didn't fail at coding. It failed at guessing. And guessing is exactly what we ask it to do when we lead with a prompt instead of a specification.

Spec-driven development flips that order. You write the intent first, in a form precise enough to be unambiguous and loose enough to stay readable, and the AI implements against it. In a Laravel 13 project with Laravel Boost wired in, this becomes less of a discipline you have to force on yourself and more of a workflow the tooling actively supports.

Why prompting alone breaks down

A one-line prompt carries almost no constraints. The agent has to invent the table schema, decide whether soft deletes matter, pick a validation strategy, guess at your naming conventions, and assume which Laravel version idioms apply. Every one of those decisions is a fork in the road, and the model takes them silently. By the time you read the diff, the assumptions are already baked into a dozen files.

The deeper problem is that the agent often doesn't know what your Laravel looks like. It can't see that you're on Laravel 13, that you use Filament for the admin layer, that your models live under a particular namespace, or that you have a BaseModel every Eloquent class is supposed to extend. So it reaches for whatever pattern was most common in its training data, which may be three major versions out of date.

A specification closes both gaps at once. It pins down the what so the agent stops guessing intent, and — paired with Boost — it grounds the how in your actual project so the agent stops guessing conventions.

What Laravel Boost contributes

Laravel Boost is an MCP server that exposes your application to an AI agent through a set of Laravel-aware tools. Instead of the agent reading raw files and inferring structure, it can query the application directly: list registered routes, inspect the database schema, read configuration, check which packages and versions are installed, search the version-specific documentation, and run Artisan commands or Tinker snippets.

Three of its capabilities matter most for spec-driven work:

Version-correct documentation. Boost ships documentation guidance scoped to the exact versions of Laravel and first-party packages in your project. When the agent needs to know how something works in Laravel 13 specifically, it isn't pattern-matching against blog posts from the Laravel 9 era — it's reading docs that match your composer.lock.

Live introspection. Tools that list your routes, models, and schema mean the spec doesn't have to redundantly describe what already exists. The agent can verify reality instead of assuming it. "Add an endpoint that follows the same conventions as the existing ones" becomes an answerable instruction rather than a hopeful one.

Tinker execution. The agent can run code against your actual application state to confirm a relationship resolves, a query returns what the spec expects, or a service binds correctly — closing the loop between "the code looks right" and "the code does the right thing."

The net effect is that your specification can stay focused on intent and behavior, because the environmental facts are something the agent looks up rather than something you have to spell out.

The shape of a good spec

A specification is not a prompt and not a PRD. It sits in between: structured enough to remove ambiguity, short enough that you'll actually write it. A practical Laravel feature spec has a handful of sections.

Start with the goal in one or two sentences — the user-facing outcome, not the implementation. Then list constraints: the Laravel version, the packages the feature must use, the conventions it must follow, and anything it must not touch. Describe the data model as the entities and their relationships, leaving Boost to confirm the existing schema. Spell out behavior as concrete scenarios, ideally in a given/when/then form that doubles as your test plan. Note non-goals explicitly, because the things you exclude prevent more wasted work than the things you include. Finally, name the acceptance criteria — the observable conditions under which the feature is done.

Here's a compact example for a rental-availability feature:

# Spec: Equipment availability check

## Goal
Let a customer see whether a piece of equipment is available
for a given date range before they request a booking.

## Constraints
- Laravel 13, existing Filament 5 admin.
- Reuse the existing `Equipment` and `Reservation` models.
- No new packages.
- Read-only; this feature must not create or modify reservations.

## Data model
- An Equipment item has many Reservations.
- A Reservation has a start_date and end_date (inclusive).
- Availability = no overlapping confirmed Reservation in the range.

## Behavior
- Given equipment with a confirmed reservation 10–15 June,
  when a customer checks 12–14 June,
  then the result is "unavailable".
- Given the same equipment,
  when a customer checks 16–18 June,
  then the result is "available".
- Given an invalid range (end before start),
  then respond 422 with a validation error.

## Non-goals
- Pricing, holds, or partial-day availability.
- Notifications.

## Acceptance criteria
- A GET endpoint returns availability for an equipment id + range.
- Overlap logic is covered by feature tests for both outcomes.
- No changes to reservation-writing code paths.

Notice what the spec doesn't say: it doesn't dictate the route URI, the controller name, or the exact query. Those are details the agent can derive from your existing conventions — conventions Boost lets it actually observe.

The workflow, end to end

The loop has four phases, and the discipline is in keeping them separate rather than collapsing them into one optimistic prompt.

1. Ground the agent. Before writing any code, have the agent use Boost to read the relevant slice of the application — the models the feature touches, the existing routes in that area, the current schema. This is where misunderstandings surface cheaply. If the agent reports that Reservation has a status enum you'd forgotten about, you fold that into the spec before a single line is written.

2. Write and refine the spec together. Draft the specification, then ask the agent to poke holes in it. A good prompt here is something like "read this spec against the actual codebase via Boost and list every assumption it makes that the code contradicts or doesn't support." The agent becomes a reviewer of your intent rather than an executor of your guesses.

3. Implement against the frozen spec. Now the agent writes code, with the instruction to follow the spec exactly and flag — not silently resolve — anything the spec leaves open. Because Boost gives it version-correct docs, the Laravel 13 idioms it reaches for are current. Because the spec's behavior section reads like a test plan, asking it to write the feature tests first is natural.

4. Verify against acceptance criteria. Run the tests. Have the agent use Tinker through Boost to confirm the behavioral scenarios against real data. The acceptance criteria from the spec become a literal checklist, and "done" stops being a matter of opinion.

When something is wrong, you usually fix the spec rather than the code, then re-run the implementation step. The spec is the source of truth; the code is a derivative of it.

A note on AGENTS.md

Specs describe individual features. The conventions that should hold across every feature — your namespace layout, your testing approach, the rule that all models extend a base class, the packages you prefer — belong in a persistent guidelines file (AGENTS.md or a Boost-generated guidelines file) that the agent reads on every task. Boost can generate a starting point for this from your project. Think of it as the standing spec: the constraints you'd otherwise repeat in every feature spec, hoisted up one level so you write them once.

What you get out of it

The honest payoff isn't that the AI writes more code. It's that the code it writes is the code you meant, on the first or second pass instead of the fifth. Specs make intent reviewable before implementation, which is the cheapest possible place to catch a misunderstanding. Boost makes the agent's picture of your project accurate instead of imagined, which is what stops it from solving last year's Laravel.

Put together, the two turn AI-assisted development from a slot machine into something closer to delegation: you describe the outcome and the boundaries, the tooling supplies the ground truth, and the agent does the work you'd have done yourself — without the silent guessing in between.