Ways to build it with AI
When you have a sharp decision and need working code, there are a few ways to build it with AI. They are not on-ramps to one tool like Sharpen. They are approaches you pick between, by the size and risk of the change. Whichever you pick, the decision you sharpened is the spec.
vibeCode
Fast and loose. Describe what you want and let AI build it in small steps. Good for small, clear, low-risk work where you can eyeball the result.
Say it another way
vibeCoding just means describing what you want in plain words and letting the AI build it, without planning it out first. It is the quick, loose mode, great for a small experiment or a change you can check at a glance. The catch is that quick work put live as if it were finished becomes the mess you are later stuck maintaining, so vibeCode the throwaway parts and build the parts that matter with more care.
Doing this with Claude Code: vibeCode
Reach for this when the task is small and clear enough to skip planning. There is no design to settle, so you describe the change in plain language, let Claude do it directly and eyeball the result. It fits quick asks and a small clear code change, where a single step is often enough. It is the natural mode when you vibeCode a prototype and want a quick result. The skill is yours, spotting when a task is clear enough that there is nothing to plan, then going straight to building.
vibeCode fits a few cases: a quick ask, a small clear change and a prototype you want fast.
A quick ask. Count something, check if it was committed, spell-check this, there is no design to settle so you just do it.
A small clear change. One validation check in one place, where a single step is often enough.
A prototype you want fast. When you vibeCode a prototype for a quick result, eyeball it and move on.
The skill is spotting it. Knowing when a task is clear enough that there is nothing to plan is your call, then go straight to building.
Plan first
Explore and design before you write code. Have AI map the relevant parts of the codebase and propose an approach, agree it with you, then switch to building. Good AI coding tools have a plan or design mode for exactly this: a phase where AI investigates and lays out the approach with nothing committed yet.
Reach for it when the change is large, spans several files, touches the architecture, or has more than one sensible design and you want to choose before you commit. Planning first turns "I am not sure how this should go together" into a decision you made on purpose, rather than one the first draft of the code made for you.
The shape is two phases: plan to settle the approach, then execute to build it. When the exploring gets long and noisy, push it into a separate pass so its output does not crowd the main thread. You keep the plan in front of you and pull in only what matters.
Doing this with Claude Code: Plan first
Reach for plan mode when the work matters, a change that is large, spans several files, touches the architecture or has more than one good approach you want to choose between first. It also suits work that has to fit decisions written down elsewhere, like a knowledge base. Plan mode makes no changes, it produces a plan. Because nothing is touched yet you explore safely and settle the design before any risk, which avoids costly rework later. Expect open questions about the approach before any code. When the discovery is verbose and would fill the context with noise, push it into a separate Explore subagent. It runs in its own context, does the reading over there and hands back a summary, so the main thread stays lean. Then the plan settles the approach and the steps that carry it out are just direct execution.
Plan first earns its keep when the work matters: knowing when it fits, settling the design with nothing touched yet, pushing noisy discovery aside, spotting the signals and planning then executing.
When it fits. Large, multi-file or architectural changes, or more than one good approach you want to choose between first.
Nothing touched yet. Plan mode makes no changes, it produces a plan, so you settle the design before any risk and avoid costly rework.
Push discovery aside. When the exploring is verbose, hand it to a separate Explore pass that reads in its own context and returns a summary, so the main thread stays lean.
Spot the signals. Restructuring, a migration across many files or a choice between approaches, that is the cue to plan rather than start coding.
Plan then execute. Plan the investigation, settle the approach, then switch to direct execution to build it.
Test first
Write the tests, or have AI write them, then let AI iterate until they pass. Good when you can pin the behaviour down up front and want a safety net as you go.
Doing this with Claude Code: Test first
Write the test that checks what the user expects of the outcome, and write it first, before the code exists, so the target is set up front. It builds straight on your examples, the 'then' in a Given/When/Then becomes the thing the test checks. Once it exists the test is a rule Claude has to meet, not a suggestion. It runs, it fails, you hand the failures back and Claude keeps trying until it passes. The catch is that it meets exactly what you wrote down and not what you meant, so keep each test concrete and focused or it passes while still being wrong. Drive the coverage yourself, because the happy path is not enough. Ask for the edge cases and the slow paths too, the null, the empty, the huge input, or it tests the obvious case and stops. The suite checks the change now and becomes the net that catches it later when a new change breaks something old.
Test first works when you can pin the behaviour down: set the target up front, make it a rule, drive the coverage, keep each test concrete and let the suite become the net.
The target up front. Write the test before the code so the behaviour is set, the then in a Given, When, Then becomes what the test checks.
A rule, not a suggestion. Once it exists Claude has to meet it, it runs, it fails, you hand back the failures until it passes.
Drive the coverage. The happy path is not enough, ask for the edge cases too, the null, the empty, the huge input.
Keep each test concrete. It meets exactly what you wrote and not what you meant, so a vague test passes while still being wrong.
It becomes the net. The suite checks the change now and catches it later when something new breaks it.
Build carefully
Smaller steps, review each one. Good for risky or far-reaching changes, or anything close to production. Slower, but you keep your hands on the wheel.
Doing this with Claude Code: Build carefully
Keep Claude on a short leash. Work in small steps and review each change before moving on, rather than letting it run ahead. Good for risky or far-reaching work, or anything close to production, where you want your hands on the wheel and a clear diff to check at every step.
Build carefully when the work is risky: small steps, a clear diff each time, close to production and your hands on the wheel.
Small steps. One change at a time rather than letting it run ahead.
Review each diff. Check the change before moving on, a clear diff at every step.
Close to production. Good for risky or far-reaching work where a mistake costs.
You stay in control. Slower on purpose, you keep your hands on the wheel.
More ways Claude helps you build
The four approaches are how you build. A few more pieces make building with AI work well. We will add a short note on each here over time.
- Refine it iteratively. Keep looping with Claude, tightening the result each pass rather than expecting it right first time.
- Work in a large codebase. Have Claude explore and map unfamiliar code first, so a change fits what is already there.
- Set Claude up to your conventions. Project memory and rules, so Claude builds the way your codebase already does.
Pick by the task
There is no single right way to build with AI. You pick the approach by the task in front of you and mix them within one piece of work. The decision you sharpened is the spec, whichever way you build it.
In plain words
This page is about the different ways to build something with AI, where AI means a tool that writes and changes code for you when you describe what you want (Claude and Claude Code are the specific tools used in the examples). It covers four approaches, from quickly describing what you want and letting the AI run, to planning or testing first when the work is bigger or riskier. The aim is to match the approach to how big and risky the change is, rather than doing everything the same way.
Part of Working with AI.
These approaches run across the Build ideas.
The soft skills behind them: The soft skills of working with AI.
Why Claude. We use Claude Code in the notes above because it is one of the most widely used AI tools for building software. It is also what we build with day to day. The approaches themselves are general and carry across to other capable AI coding tools.