Free & open · no paywall, ever

IntegrAuth Academy

Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.

20 tracks 241 lessons 242 hands-on labs 230+ diagrams 100% free

English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.

How?
  • Chrome on phone: ⋮ menu → Translate
  • Chrome on computer: right-click → Translate to …
  • Edge: the translate icon in the address bar
Practical AI Track 4 · Coding with AI
0/75 lessons read
CODING WITH AI · LESSON 3

Plan before it codes

Priya asked an agent for a CSV export and left for tea. She came back to 11 changed files and 4 broken pages. Your goal: fix the plan before any file changes.

🧪 Interactive lab — enable JavaScript to play with this one.

1 · Exploreread-only2 · Planyou review and fix it3 · Implementone small step at a time4 · Verifytests, checks, your reviewnext stepcost of fixing a wrong assumption, by where you catch ita questionone sentencerevert files,re-prompt, re-reviewdebug, redo, maybe an incidentillustrative, not to scale
Figure — Fix it where it is cheap. The later you find a wrong idea, the more it costs you. The bars are not real data.
Key points
  • A wrong idea costs one sentence in the plan. Later, it costs much more.
  • Write a short spec first. Say how you will check "done".
  • Check the plan against the spec. Look for guesses, broken rules and extra work.
  • Can you describe the change in one sentence? Skip the plan.

Explore, plan, implement, verify

First, the agent reads the code and changes nothing. Next, it writes a plan: which files change, in what order, and how to test each step. You read the plan and fix it. Then it works in small steps. Last, tests check each step, and you read every change. Think of a house drawing. Moving a wall on paper costs nothing. Moving it after building costs a lot.

Many tools have plan mode for the first two steps. The agent can read and ask, but can't edit files. No plan mode? Say, "Don't write code yet. Propose a plan." That is only a request. So also set the tool to ask before every change.

Write a short spec

A spec is a short written plan of what to build. It has 6 parts: goal, context, constraints, out of scope, acceptance criteria and how to verify. Constraints are rules the agent must follow. Out of scope lists what to leave alone. The key part, the acceptance criteria, says what "done" means, as checks you can test.

Now walk 3 tasks through the 4 steps.

🧪 Interactive lab — enable JavaScript to play with this one.

Go deeper: plan mode by tool

As of October 2026, most coding agents have a plan mode or something like it. Examples are Claude Code, Antigravity CLI, Cursor, GitHub Copilot in VS Code, Codex CLI and Cline.

In plan mode, the agent changes none of your files until you approve. Some tools still run commands to look around, or save the plan as a file.

Go deeper: a sample spec
PartPriya's CSV export
GoalAdmins can download the order list they see as a CSV file.
ContextThe list is in admin/orders/. Copy the pattern in reports/pdf-export.ts.
ConstraintsNo new packages. Don't change the shared orders query.
Out of scopeScheduled exports. Other admin pages.
Acceptance criteriaWith the filter "refunded", Export gives only refunded orders. 50,000 orders export without timing out. Amounts show 2 decimals.
How to verifyNew tests pass. Open one real export in a spreadsheet.

Let the agent ask first. Say, "Before you plan, ask me the questions you need answered." It finds gaps you missed. Priya's agent asked which time zone to use for dates. She had not thought about it.

A tip from Claude Code's guide: save the answers as a spec file. Then start a fresh session to build it.

Some tools build the whole process around the spec. This is often called spec-driven development. Examples are GitHub's open-source Spec Kit and Kiro, an AI coding tool from Amazon Web Services.

Go deeper: checking a plan

Read the plan like a proposal from a coworker. Compare it with the spec. Common problems:

  • Wrong ideas about the code. A file or function that does not exist, or works differently. Check the 1 or 2 claims the plan rests on.
  • Broken rules. A new package you said not to add. Code you said not to touch.
  • Extra work. "While we are here, let's restyle every page." This is scope creep.
  • Missing criteria. No step handles the 50,000-order case.
  • Guesses. The plan picks an answer the spec left open. It should ask you.
  • Risky steps. Deleting files or changing data, with no backup or check.
  • No tests. Steps that never say how they will be checked.

Then fix it in plain words: "Drop step 7. Use the existing CSV helper in step 2." Ask for the new plan before you approve it.

Go deeper: small steps and when to skip

Ask for small steps that you can test and save one at a time. Say, "Do step 1 only, run the tests, stop." Agents can drift from the plan. So compare each change with its step (Tests, checks and debugging).

For hard problems, many tools let the model think longer first. This is its effort level. More effort often helps, but it is slower and costs more (Choosing a model). Some teams plan with a stronger model and build with a cheaper one.

Planning takes time too. Claude Code's guide gives a simple test. Could you describe the change in one sentence? Then skip the plan. For a typo, a log line or a rename, just ask. Plan when you are unsure how to do it. Also plan when the change touches several files, the code is new to you, or a step can't be undone.

Watch out

A plan can sound sure and still be wrong. Check the facts it rests on.

🧪 Try it free

Ask any AI, "Ask me 5 questions about my feature. Then write a spec." Then get a plan in plan mode. Check it.