How to build an application with AI the right way (Claude Code, Codex): from brief to production

I build applications with AI every day – my own tools, client applications and practice projects on my course. And I see one thing over and over: people starting out with Claude Code or Codex jump straight into writing code. "Build me an app for tracking orders." An hour later something runs, a day later it has twenty features, and a week later it can't be fixed. I wrote about the mistakes that creates in Vibe coding: 7 amateur mistakes. This article is the other half – not what to avoid, but how to proceed so that the result is an application you can hand over, run and grow.

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.

Write the scope pessimistically. The first version should do one thing properly; put every additional feature on a "later" list. You'll find you never need half of it.

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.

Modern AI tools have modes and commands for exactly this. In Claude Code there is plan mode (/plan), in which the tool explores the project and prepares an approach without changing files; a goal-oriented mode (/goal), where you define a measurable done condition and the tool keeps working until it's met or shown to be impossible; commands for code review (/code-review, /security-review); and extensions through plugins – for example an interface design critique like /design:design-critique, which goes through a design from the point of view of hierarchy, usability and consistency. Codex has similar settings – degree of autonomy, approval of changes, review – but the exact names change with versions, so check the current documentation of your tool.

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"

When people wonder why the same model gives them such different results in different tools, the answer is the harness. Claude Code, Codex and similar tools are not just a model you type to. They are a model plus the structure around it: project rules the tool loads, available tools (reading and editing files, running tests, a browser), memory across sessions, checks and permissions for who may run what. That structure decides quality more than you'd expect – two people with the same model and different harnesses will get two different applications. I won't go into detail here (it's know-how I've been building for months and teach on courses), but take away the principle: invest in the rules and checks around the model, not just in better prompts. More on this in AI agents and the harness.

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:

1. Give the AI one step, not the whole plan.
2. Have it write the code and a test for it, or at least describe the test.
3. Run it. Read the diff – you don't have to understand every line, but you must know what changed and why.
4. Commit. Only then the next step.

Why so pedantic? Because AI changes code fast and broadly, and the only reliable way to stay in control is to have a verified state after every step that you can return to. Goal-oriented modes like /goal help with this – you state "all tests pass and lint is clean" and the tool iterates until that's true – but they only work when tests exist and when something other than the model that wrote the code evaluates them.

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. I won't repeat the details from the article on vibe coding mistakes, just a reminder of the items to tick off before deploying: secrets outside the code, every input validated on the server, database access rules on and tested, login and roles checked on every request, dependencies from verified sources, admin off the public URL.

Step 5: Why most "finished" vibe-coded apps aren't production-ready

An application that works on your computer is not an application ready for operation. This is the list of things that are almost never in prototypes – and without which your app will one night stop working and nobody will know:

• 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. Limits on requests per endpoint, size of uploaded files, length of inputs. Without them, one bot is enough and the infrastructure bill explodes.
• Error states. What happens when the payment gateway is down, when an email doesn't send, when the database doesn't respond? A prototype crashes or silently loses data at that moment. A production app records it, retries or reports it clearly.
• 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.

None of this is technically difficult. It's work that gets skipped in a prototype because "it works". Before deployment go through this list item by item and write down for each how it's handled. Where there's no answer, it's not done.

Step 6: When to bring in a professional

Not always. An internal tool for three people, a calculator for your website or a prototype to validate an idea you can do yourself – and I recommend trying, that's exactly what I teach on the vibe coding course. Bring in a professional 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 had to write "I don't know" against more than two items on the list from step 5.

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 is determined by the harness – the rules, tools and checks around the model – more than by the prompt itself.

Frequently asked questions

Do I need to know how to program to build an app with AI?

Not for a prototype or an internal tool. But you must understand what you've built: how data flows, what runs where, where the logs are. That's not programming, that's an hour of explanation – and it's exactly what the course is about. For an application the business stands on, you want someone who can read code.

Which tool is better – Claude Code or Codex?

Both are capable and both change quickly. More important than the choice of tool is the process: separate design, small steps, tests, independent review. A bad process ruins the result in any tool; a good process works in all of them.

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 – /plan, /goal, /code-review, /security-review and more
• OpenAI Codex CLI – OpenAI's local coding agent
• Vibe coding: 7 mistakes that turn amateur AI apps into disasters – what to avoid