Vibe coding vs agentic engineering

By the end of this lesson: you will be able to explain why "just prompt it" stops working once an app has real users and real data, and you will know the plan → small step → check loop we use for every change in this course.

Why "just prompt it" breaks on real apps

Vibe coding is typing what you want, accepting whatever comes back, and pasting errors in until it runs. For a throwaway demo that's fine. I've done it, and it's fun.

It breaks on a real app for a few boring reasons:

• The AI forgets. Each Claude Code session begins with a fresh context window. Decisions you made yesterday are gone unless they're written down in a file like CLAUDE.md.
• Big prompts hide big guesses. "Add subscriptions" has a hundred small decisions in it. The AI makes all of them silently, and you find out which ones were wrong in production.
• Working code is not correct code. The page loads, so you assume it's done. Meanwhile it may be skipping a permission check, storing something it shouldn't, or breaking a feature you didn't touch.
• Big diffs can't be reviewed. If one prompt changes twenty files, you will not read them. Nobody does. You just hope.
• There's no way back. If the last working version was never saved, "undo" means starting over.

None of this is the AI being bad. It's you handing over decisions you didn't know you were handing over.

What we do instead: agentic engineering

The AI still does most of the typing. You stay in charge of what gets built, in what order, and whether it's right. The loop is short:

1. Plan. For anything bigger than a small tweak, ask for a plan first. Read it. Fix it. Approve it.
2. Small step. Implement one piece at a time, with a commit before each AI change.
3. Check. Read the diff, run the app, run the tests. Then commit and go to the next step.

That's the whole idea. The rest of the course is this loop applied to a Laravel app, a server, payments, and so on. Rules that should apply every time (stack, coding style, "never touch .env") go in a CLAUDE.md file at the project root. You'll write your first one in the next chapter, and the official memory docs explain how Claude Code loads it.

Step 1: Plan before you build

Claude Code has a plan mode for this. /plan switches into plan mode before a large change. You can also turn it on with Shift+Tab, the /plan slash command, the --permission-mode plan flag, or the permissions.defaultMode setting. In it, Claude reads your code and proposes changes without editing your source files. The command list is in the Claude Code commands reference.

One caution. Plan mode is a safeguard, not a vault. It is a workflow safeguard, not an enforced security boundary. Your real safety net is the commit you make before each change (Step 2).

Here's a prompt for a typical first feature, a waitlist signup form. Start in plan mode, then paste:

Prompt for Claude Code:

I want to add a waitlist signup form to this app: a visitor enters their email, we store it, and show a thank-you message.

Do not write any code yet. First read CLAUDE.md and the existing code, then give me a plan with:
1. What you understood the feature to be, in two or three sentences.
2. The questions you need answered before starting (list them, don't guess).
3. The files you would create or change, and why.
4. Any database changes.
5. The steps in order, each small enough that I can review it on its own.
6. How I can check each step works.
7. What could go wrong, and anything you are assuming.

Keep the scope as small as possible. If something is not needed for a first version, say so and leave it out.

Now read the plan like a skeptical manager. Look for:

• Features you didn't ask for. Cut them.
• Assumptions you disagree with. Correct them in plain English.
• Steps that are too big. Ask for them to be split.

Only when the plan looks right do you approve it. If you want to edit the plan itself, Ctrl+G opens the plan in your editor.

Step 2: One small step at a time

Before the AI touches anything, save the current state. Git gets a full lesson later in this chapter, so for now just know the shape of it:

git status
git add -A
git commit -m "Before: waitlist step 1"

If git status shows files you don't recognise, stop and find out why before committing. And never commit your .env file. Secrets stay out of Git.

Then ask for exactly one step from the approved plan:

Prompt for Claude Code:

Implement step 1 of the approved plan only: the database migration and the model for waitlist signups.

Rules for this step:
- Do not start step 2.
- Do not change files that are not needed for this step.
- Do not run the migration. Show me the migration and tell me the command to run.
- When you are done, list every file you changed and explain each change in one sentence.

Small steps are not about being slow. A step you can read in a few minutes is a step you'll actually review. A step you can't read is a step you're trusting blindly.

Step 3: Check the work

The AI saying "done" is a claim, not proof. Check it three ways.

Read the diff. This shows exactly what changed since your last commit:

git diff
git status

You don't need to understand every line yet. You do need to notice the unexpected: files you didn't expect, deleted code, anything that looks like a key or password, and changes unrelated to the step.

Make the AI explain it. If something looks odd, ask:

Prompt for Claude Code:

Walk me through the diff you just made. For each file: what changed, why it was needed for this step, and what could break because of it. Point out anything you changed that was not strictly required.

Run it. Open the page, submit the form, look at the result. Try something silly, like an empty email or the same email twice. Real users will. Later you'll write tests so the AI can't quietly break this again, and there's a whole lesson on that.

If it's good, commit with a clear message and move to the next step:

git add -A
git commit -m "Add waitlist model and migration"

If it's bad, you have options. Ask the AI to fix it, or throw the change away and try again with a better prompt. Because you committed first, throwing it away is cheap. Check git status and git diff first so you know what you're discarding.

When you can skip the plan

You don't need a plan for everything. If you can describe the whole change in one sentence ("change the button text", "fix this typo in the footer"), just ask. Still commit first and still read the diff.

Plan first when a change touches several files, touches the database, involves money or login, or when you're not sure how it should work. If you're unsure whether it qualifies, it does.

Common mistakes

• Approving a plan you didn't read. A plan you skim is just a longer prompt. The point is that you catch the wrong assumption before it becomes code.
• Letting the AI do three steps because the first one worked. That's how you end up with a diff you can't review. One step, one check, one commit.
• Forgetting to commit first. Without it, "undo" is guesswork. Commit before every AI change, even tiny ones.
• Pasting error after error without reading them. If the third fix doesn't work, stop. Revert, go back to the plan, and find out what the AI misunderstood.
• Putting repeated rules in your prompts instead of CLAUDE.md. If you've said the same thing three times, it belongs in the file.

Checklist

• I can explain why a big, vague prompt is risky on a real app.
• I know the loop: plan → small step → check.
• I know how to start plan mode (Shift+Tab or /plan).
• I commit before each AI change.
• I read the diff before I accept a step.
• I know which changes need a plan and which don't.