Stop Saying "Looks Good" to Plans You Can't Read

You ask Claude to build something in Laravel. It comes back with a plan. "Create a migration for the tasks table. Add a route that points to a TaskController. Use Eloquent to query incomplete tasks."

You stare at it. You don't know if this is a good plan or a terrible one. So you do what everyone does. You say "looks good" and hope for the best.

This is building blind. And it's the most common trap in AI-assisted development. Not that the tool gives bad answers, but that you can't tell the difference between a good answer and a bad one. You skip straight from idea to code without ever reading the blueprint.

Some people try to fix this by watching tutorials. They sit through hours of content that introduces 40 new terms per video, all presented as equally important. They retain nothing. They go back to saying "looks good."

The problem was never the tool. It was the vocabulary.

You don't need 200 terms. You need about 16, enough to read the blueprint before construction starts. This article gives you those 16 words, in the order you'll actually encounter them while building.

Why These 16 Words Change Everything

You don't need to become a developer to build with AI. But you do need enough shared language to have a conversation.

Think about it this way. If you walked into a restaurant kitchen and said "make the food hot," you'd get a confused look. But if you said "grill the steak, medium-rare," the kitchen knows exactly what to do. You didn't go to culinary school. You just learned the words that matter.

Laravel vocabulary works the same way. When you tell Claude "add a route that points to a controller which queries the model," it produces clean, conventional code. When you say "make a page that shows stuff from the database," it guesses. Sometimes it guesses well. Sometimes it doesn't.

The difference isn't skill. It's vocabulary.

Every term below will show up the first time you ask Claude to build something in Laravel.

Where Does a URL Go?

Every web app starts here. Someone types a URL. Something has to catch that request and decide what to do with it.

A route is the connection between a URL and the code that handles it. When a user visits /dashboard, a route says "this URL goes to this piece of code." That's it.

A controller is where that code lives. It receives the request, does whatever work is needed (load data, check permissions, process a form), and sends back a response.

Together, they're the traffic system of your app.

When you ask Claude to add a new page, the first thing it writes is a route.

Route::get('/dashboard', [DashboardController::class, 'index']);

When someone visits /dashboard, run the index method inside DashboardController. One line. You already know what it means.

The controller is just as readable.

class DashboardController extends Controller
{
    public function index()
    {
        return view('dashboard');
    }
}

It receives the request and returns a view (the screen the user sees). The names are descriptive on purpose. Laravel's convention is that code should read like English.

Every web framework has routes and controllers. Express calls them routes and handlers. Next.js uses file-based routing. Django calls them URLs and views. The words change. The concept doesn't.

But a route that catches a request is useless without data to show. Where does that data live?

Where Does Your App Remember Things?

Your app needs to remember things. Users, posts, orders, tasks, whatever your app tracks. That data lives in a database, and Laravel gives you three terms for working with it.

A model is the shape of your data. A User model represents a user. A Task model represents a task. Each model maps to a table in your database.

A migration is how you build and change that table. Instead of manually editing a database (which is fragile and hard to undo), you write a migration that describes the change.

Schema::create('tasks', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->boolean('completed')->default(false);
    $table->foreignId('user_id')->constrained();
    $table->timestamps();
});

This creates a tasks table with a title, a completed flag, and a link to the user who owns it. When Claude generates this, you can read every line.

Eloquent is how you talk to the database. Instead of writing raw SQL, you write something like this.

$tasks = Task::where('completed', false)->get();

That says, get all tasks where completed is false. Eloquent translates it to SQL for you.

You'll also see relationships in Claude's output. A user has many tasks. A task belongs to a user. Eloquent expresses that directly:

// In the User model
public function tasks()
{
    return $this->hasMany(Task::class);
}

Now you can write $user->tasks and get every task that belongs to that user. The code reads like the sentence you'd use to describe it.

Every framework has an ORM (Object-Relational Mapper), the layer that lets you talk to a database using code instead of SQL. Prisma does this for Node.js. Django has its own ORM. ActiveRecord does it for Rails. Eloquent is Laravel's, and it's one of the most readable.

Now you have data. But the user is still staring at a blank screen. Something has to turn rows into a page.

How Does Data Become a Page?

The user needs to see something. All the data you fetched, all the logic you ran, eventually has to become a screen.

A view is that screen. In Laravel, views are typically written with Blade, Laravel's templating language. It looks like HTML with a few extras.

<h1>Your Tasks</h1>
@foreach ($tasks as $task)
    <p>{{ $task->title }}</p>
@endforeach

@foreach loops through the tasks. {{ $task->title }} prints each title. If you can read HTML, you can read Blade.

Every framework needs a way to render HTML. React uses JSX. Django uses Django Templates. Rails uses ERB. Blade is Laravel's version, and it's intentionally simple.

You can show data now. But what stops someone who isn't logged in from seeing it? What happens when they submit garbage into a form?

What Stops Bad Requests?

Before a request reaches your controller, it passes through gatekeepers.

Middleware checks things before the request arrives. The most common one is simple. Is this user logged in? If not, redirect them to the login page. You'll see this in Claude's output constantly:

Route::get('/dashboard', [DashboardController::class, 'index'])
    ->middleware('auth');

That ->middleware('auth') at the end means that only logged-in users can access this page. One word, and your route is protected.

Middleware handles other checks too. Rate limiting (don't let someone hit this URL 1,000 times per second). CORS headers (let other websites talk to your API). Maintenance mode (show a "we'll be right back" page). These exist out of the box. You don't install them. They're already there.

Validation checks the data itself. When a user submits a form, you need to make sure their input is acceptable before you do anything with it. Laravel ships with over 90 built-in validation rules.

$request->validate([
    'title' => 'required|max:255',
    'email' => 'required|email|unique:users',
]);

The title is required and can't exceed 255 characters. The email is required, must be a valid email format, and can't already exist in the users table. If anything fails, Laravel automatically sends the user back with error messages.

When Claude writes form-handling code, it will usually create a Form Request, a dedicated class that holds all the validation rules for a specific form. Instead of cluttering the controller with validation logic, the rules live in their own file. You'll see Claude generate classes like StoreTaskRequest or UpdateUserRequest. Now you know what they're doing.

Your app can catch requests, load data, show pages, and enforce rules. But what about work that can't happen while the user waits?

What Happens When the User Isn't Waiting?

Not everything happens while the user waits.

Think of a restaurant during the dinner rush. A waiter takes your order and walks it to the kitchen. The waiter doesn't stand at the stove and cook your meal. They drop off the ticket and go take the next table's order. The kitchen works through tickets in order, in the background.

That's exactly how queues work. When your app needs to send a welcome email, process an uploaded image, or call an AI to summarize a document, it doesn't make the user wait for that work to finish. It drops a job into the queue and responds immediately. A background worker picks up that job and handles it.

dispatch(new ProcessUploadedImage($image));

One line. The image gets resized and optimized in the background. The user sees a confirmation instantly instead of staring at a loading spinner.

The moment you ask Claude to handle file processing, generate PDF reports, or call an AI to summarize a document, it will write a job class with implements ShouldQueue and a dispatch() call. Now you know why.

The scheduler is the timer. Instead of "do this when a user triggers it," the scheduler says "do this every day at midnight" or "do this every hour."

$schedule->command('reports:send')->daily();

Daily reports. Weekly cleanups. Hourly data syncs. One line each.

In Next.js, background jobs mean choosing between BullMQ, Agenda, or a custom Redis setup. Scheduling means installing node-cron and wiring it up yourself. In Laravel, both are built in. One word: queue. One word: schedule.

Every serious web app eventually needs background processing and scheduled tasks. The concept is universal. Laravel just gives it a name and a clean API instead of making you assemble it from parts.

That's the last piece of the day-to-day vocabulary. But you'll use two tools so often they deserve their own section.

What Will You Type Every Day?

Two things you'll use every single day.

Artisan is Laravel's command line tool. You'll run it in your terminal to create files, run migrations, start the development server, and dozens of other tasks.

php artisan make:model Task -m    # Create a model and its migration
 
php artisan migrate               # Run all pending migrations
 
php artisan serve                  # Start the development server

When Claude gives you instructions, half of them will start with php artisan. It's how you talk to Laravel outside of the browser.

The .env file is where your app's secrets live. Database passwords, API keys, mail credentials. Instead of hardcoding these values into your code (which would be a security disaster if anyone saw your files), you put them in .env:

DB_DATABASE=vibemastery
MAIL_MAILER=resend
OPENAI_API_KEY=sk-...

Your code reads from this file. The file never gets committed to version control. Different environments (your laptop, the production server) have different .env files with different values.

Claude will reference .env regularly. When it says "add your API key to your .env file," you now know where that is and why it matters.

You've now met every term one by one. But how do they fit together?

How Everything Connects: MVC

You already understand this. You just didn't know the acronym.

MVC stands for Model-View-Controller. It's the name for the pattern you've been reading about for the last few sections:

• Model = the data (your database tables and how you interact with them)
• View = the screen (what the user sees)
• Controller = the logic in between (receives requests, works with models, returns views)

A user visits a URL. The route sends that request to a controller. The controller asks the model for data. The model fetches it from the database. The controller passes that data to a view. The view renders it as HTML. The user sees a page.

That's the entire flow. Every Laravel request follows this path. Once you see it, you can't unsee it.

MVC isn't a Laravel invention. It's a pattern that shows up in frameworks across every language. Django uses it (they call it MTV: Model-Template-View, same idea). Rails uses it. Learning this pattern in Laravel means you've learned it everywhere.

How Do You Install Packages and Get a Head Start?

Two more terms, and then you're done.

Composer is how you install packages in PHP. It's the equivalent of npm in JavaScript or pip in Python. When Claude tells you to run composer require some-package, it's adding a tool to your project.

composer require laravel/sanctum

That installs Sanctum, a package for API authentication. Composer manages it, tracks its version, and handles its dependencies. You run the command and move on.

Starter kits give you a running start. Instead of building authentication, user profiles, and basic layouts from scratch, Laravel offers kits that set all of it up:

• Breeze is the simple one. Authentication pages, basic layout, minimal decisions. Good for learning.
• Jetstream is the full setup. Teams, two-factor authentication, API tokens, profile management.

When you create your first Laravel project, you'll pick one of these. They're not separate frameworks. They're a head start within Laravel.

What to Do Next

You just met about 16 terms. You don't need to memorize them.

Bookmark this page. The next time Claude generates a plan and you see a word you don't recognize, come back here, or just ask Claude directly. "What does middleware('auth') do in this route?" is a perfectly good prompt. Now you have enough context to understand the answer.

That's how vocabulary actually sticks. Not by reading a glossary front to back, but by encountering a word in context, looking it up, and recognizing it the next time it appears.

The next time Claude writes a plan with routes, controllers, and migrations, you won't nod along and hope for the best. You'll read the blueprint. You'll know what you're looking at. And you'll know when something's wrong before a single line of code gets written.

Frequently Asked Questions

Do I need to memorize all these terms before I start building?

No. You'll learn them faster by building. When Claude writes code that includes a word you don't recognize, come back to this article. Context is a better teacher than repetition.

What about terms like API, endpoint, or CRUD?

If you've followed the previous articles in this series, you've already encountered these. API is how apps talk to each other. An endpoint is a specific URL that an API responds to. CRUD (Create, Read, Update, Delete) describes the four basic things you do with data. They're general web terms, not Laravel-specific.

Is this all the vocabulary I'll ever need?

No. But it's enough to start. Terms like Facade, Service Provider, and Event will show up as your apps get more complex. By then, you'll have the foundation to understand them in context. You won't need another walking tour. You'll just look them up.

How is this different from reading the Laravel docs?

The Laravel docs are a reference manual. They're complete and accurate, but they assume you already know the vocabulary. This article teaches the vocabulary so the docs stop feeling like a foreign language.

Why are these terms in this specific order?

Because this is the order you encounter them when building. You start with a URL (route) and the code that handles it (controller). Then you need data (model, migration, Eloquent). Then you show it to the user (view). Then you add rules (middleware, validation). Then you handle background work (queues, scheduler). Then you zoom out (MVC). The order mirrors the building process, not the alphabet.