Building an application with AI needs a verification process alongside the brief. Adding functions without understanding changes makes faults harder to trace. These six steps follow the vibe coding risks and show how to verify work throughout.
The right process with AI tools has six steps: 1) brief and scope including what the application does not do, 2) design and its critique before the first line of code (plan mode, design review), 3) a plan broken into small steps with tests, 4) code review and a security checklist, 5) production readiness, monitoring, backups, limits, error states, permissions, API costs and dependency updates, 6) deciding when to bring in a professional. Tools like Claude Code or Codex are not "just a model": they are a model plus a structure of rules, tools and checks around it, and quality depends on the model, inputs and that structure.
Step 1: Brief and scope, above all, what the app does not do
The best brief for an AI is the same as the best brief for a person: who uses the application, what problem it solves, how you'll know it works. Write it on one page and add three things people leave out:
- What the application does not do. "It doesn't do invoicing, it doesn't take payments, there's no mobile app." Without that sentence, the AI will happily add everything it can think of, and every extra feature is another place for things to break.
- Who may do what. Roles and permissions described upfront, not improvised halfway through.
- Data. What entities exist (order, client, item), what is mandatory, what must never be lost.
Separate the essential first process from other ideas. Evaluate deferred features against usage and business needs; their count does not predict how many you will eventually use.
Step 2: Design and its critique, still without code
This is where most later problems are decided. Before you let the AI write, let it design: the data structure, the main screens, the flow of one typical operation, what runs where. Then have that design critiqued, ideally by a different context than the one that wrote it.
Planning and review can use an ordinary instruction or an available mode. Claude Code documentation distinguishes built-in commands and extensions. A command from someone else's plugin may be unavailable in your installation. Check its description, permissions and stopping conditions; no mode promises completion of every application.
The essence is the same regardless of the tool: separate the "think and design" phase from the "write" phase and put a critique between them. Critiquing a design is cheap; critiquing a finished application is expensive.
A brief note on the "harness"
Quality depends on the model, brief, context and harness: tools, rules, checks and permissions. Compare configurations on identical tasks rather than product names. See agents and harnesses.
Worked example: A harness around one form fix
ORIGINAL EXAMPLE · FICTIONAL DATA
| Action | Input / output | Boundary |
|---|---|---|
| Task | Empty email must be rejected. | Form only |
| Read | contact.tsx + validation rule | No secrets |
| Change | Add server-side validation | No deployment |
| Verify | Empty input should be rejected. | The test must actually run. |
Illustrative flow, not evidence of a successful test.
Step 3: Plan → small steps → tests
The approved design turns into a plan: numbered steps, each with a "done means" description. A step should be small enough to verify within minutes, one screen, one operation, one database migration. Then you work in a cycle:
- Give the AI one step, not the whole plan.
- Have it write the code and a test for it, or at least describe the test.
- Run it. Read the diff, you don't have to understand every line, but you must know what changed and why.
- Commit. Only then the next step.
Small verified changes make causes and rollback easier to trace. Define budgets, checks and stopping conditions for longer tasks. Passing tests verify covered cases; they do not prove the whole application is error-free.
Imagine a simple job tracker. The first step need not be a "finished app", but creating one job and checking that it remains saved after refreshing the page. Only then add another status, filter or role. This makes it easier to trace a failure to the change that introduced it.
Step 4: Review and a security checklist
Before you deploy anything, two passes:
Code review. Have the AI go through its own work with different eyes, in a different context, with a different instruction ("look for bugs, don't confirm it's fine"). Tools have commands for this; more important than the specific command is that the reviewer must not be the same context that wrote the code. If you have a person who programs at hand, it's the best-invested hour of the whole project.
Security checklist. Protect secrets on the server, validate untrusted inputs and test data access for different roles. Administration needs authentication and server-side authorization for every protected operation; an obscure URL is not protection. See the vibe coding article.
Worked example: Review catches access to another order
verified example test
| Check | Specific change or result |
|---|---|
| Before repair | return order |
| Rule after repair | user.id == order.ownerId |
| Test: user U-1 | status 200, id O-17 |
| Test: user U-2 | status 403 |
Actual local test of an illustrative function; not a full application audit.
Step 5: What to verify before production
A working journey on a development computer does not cover operational situations. Check the following areas for the actual application; the label "prototype" does not tell you which are already addressed.
- Monitoring and logs. When an error occurs, do you find out, or does the customer? The application must report errors and have readable logs you can get to.
- Backups and restore. Not just "we back up", but "we've tested that the backup can be restored". An untested backup is a wish.
- Limits. Verify proportionate request, file and input limits according to abuse risks and costs.
- Error states. Test unavailable payments, email and databases. Confirmations must reflect reality; define retries, monitoring and fallback procedures.
- Permissions and environments. Separate test and live environments, separate keys, no shared accounts.
- API costs. Applications calling AI or other paid services need budget caps and alerts. Without them, the first successful marketing push turns into a surprising invoice.
- Dependency updates. Libraries age and holes get found in them. Someone has to watch and update them, and that means having tests that tell you after an update whether something broke.
Complexity depends on the application. Specify implementation, ownership and completed checks for each item. An unresolved critical risk is a reason to postpone deployment.
Being able to save a job does not tell you what happens during a database outage or when another user signs in. Before launch, also check situations that an ordinary click-through never exercises.
Step 6: When to bring in a professional
A small prototype with test data can be a useful beginner exercise. User count alone does not establish readiness to operate it safely. Consider expert help when:
- the company's income or customer data depends on the application,
- you need payments, integrations with accounting or inventory, multiple roles,
- more people will use it than you can personally phone when something goes wrong,
- you cannot verify a critical area such as permissions or data recovery.
That doesn't have to mean they build the whole thing. Often it's enough for them to design the architecture, set up the project structure and checks, and you then build with AI within guardrails that hold. That's exactly how I build custom applications, and some clients keep developing the app with AI themselves after handover, because they know how it's built.
Summary
- Start with a one-page brief including what the app doesn't do, what roles it has and what data.
- Have the design created and critiqued before the first line of code, use plan mode and an independent review.
- Work in small steps: one step, code + test, read the diff, commit.
- Before deployment, a review in a different context and a security checklist.
- Production means monitoring, backups with a verified restore, limits, handled error states, separate environments, cost caps and dependency maintenance.
- Quality depends on the model, brief, context, tools and checks; assess demonstrated outcomes.
Frequently asked questions
Do I need to know how to program to build an app with AI?
A prototype can be created without previous programming experience, but deployment requires appropriate understanding and review. For data, payments and permissions, involve someone who can inspect the code. A short architecture explanation does not replace that work.
Which tool is better, Claude Code or Codex?
Try available modes on the same task. Compare correctness, corrections, tools and cost. A sound process helps but does not remove the differences or limitations of a particular service.
How do I know the application is production-ready?
Go through the list from step 5 and write down concretely for each item how it's handled: who gets alerted on an error, when you last restored a backup, what the limits are, what happens when the payment gateway is down. Where an answer is missing, it's not done.
When is it worth calling a developer?
When income or customer data depends on the application, when you need payments and integrations, or when more people will use it than you can personally support. Often it's enough for a professional to design the structure and checks, and you then build with AI within safe guardrails.
Sources and links
- Claude Code, commands reference, available commands and extensions
- OpenAI Codex CLI, OpenAI's local coding agent
- Vibe coding: 7 mistakes that turn amateur AI apps into disasters, what to avoid