How To Use AI In Website/App Development

Every team is now using AI to build software. Very few are using it well. The difference is not the tool you pick — it is how much of the thinking you hand over with it.

AI has stopped being a novelty in software work. In Google’s 2025 DORA research, 90% of technology professionals said they use AI at work. That is close to everyone. But the same research found something less comfortable: teams were shipping more code and also breaking production more often. AI turned out to be an amplifier. It makes a disciplined team faster, and it makes a messy team messy faster.

This guide is a practical walk through how to actually use AI when you build a website or an app — which parts to hand over, which parts to keep, and how to tell whether it is helping. No jargon that is not explained, and no pretending the risks are not real.

First, the five places AI shows up in a build

People say “we use AI” and mean five completely different things. It helps to separate them, because each one carries different risk.

1. Writing code — the part everyone thinks of first.
2. Designing screens — turning a description into layouts, or a layout into working markup.
3. Testing — writing test cases, and repairing tests when the interface changes.
4. Reviewing and shipping — checking each change for bugs, leaked keys and security holes.
5. Features inside your product — a chat assistant, smart search, summaries, classification. This is a different job from the four above, and it comes later in this guide.

Here is how the first four fit into a normal build, and — the important column — where a person still has to make the call.

Read that figure twice, because it contains the whole method. AI is very good at the first draft of almost anything. It is not accountable for anything. Every stage therefore has two rows: what the machine produces, and what a human signs.

The four kinds of AI tools — and which one you need

The tool market looks chaotic, but it sorts into four groups by how much work you hand over in one go. Most working teams use two or three of these together.

A simple way to choose:

Sort the work before you prompt

This is the habit that separates teams getting real value from teams generating expensive rework. Before you open a tool, decide which of three buckets the task sits in.

The line between column two and column three is worth being strict about. AI can propose a database schema, an authentication flow or a pricing calculation. It cannot be responsible for one. If a regulator, a customer or an on-call engineer asks why the system does what it does, “the model wrote it that way” is not an answer anyone accepts.

How to actually use AI on a real build, step by step

Here is the workflow we would recommend to a team of any size. It works for a marketing site and it works for a multi-tenant SaaS product; only the depth of each step changes.

1. Write the spec first — with AI, not instead of it

   Dump your rough notes, voice memos and screenshots into a model and ask it to produce a short specification: what the thing does, who uses it, the main screens, the data it stores, and what happens when things go wrong. Then rewrite it yourself. The value is not the document; it is that you now notice the twelve decisions you had not made.

   Human checkpoint — you fix the goal, the edge cases, and the list of things the product must never do. Never delegate this list.

2. Design the screens with generation, then curate hard

   Describe a screen and you will get several layouts back in seconds; hand over an existing design file and you will get a first pass at markup. Use it to explore more directions than you would have had time to draw. Then throw most of them away. Generated interfaces look plausible and often ignore empty states, error states, loading states, keyboard use and screen readers — the parts that actually decide whether the product feels good.

   Human checkpoint — pick the direction, walk the whole flow yourself, and check colour contrast and keyboard navigation before anyone codes it.

3. Set up the project so an agent can work in it safely

   This is the step almost everyone skips, and it is the one that decides whether AI helps. Before you generate a single feature: put the repository under version control with small, reviewable commits; write down your conventions in a file the agent reads; add linting, formatting and type checking; make sure the test suite runs with one command; and keep secrets out of the codebase and out of prompts. An agent in a tidy repository is a strong junior engineer. The same agent in an undocumented repository invents its own conventions on every task.

   Human checkpoint — give the tool the narrowest permissions that let it work. It does not need production credentials to write a form.

4. Build in small, reviewable slices

   Ask for one thin vertical slice at a time — one route, one component, one endpoint, with its tests — instead of “build the dashboard”. Small slices are the whole trick: you can read a 200-line diff properly, and you cannot read a 4,000-line one. If a diff is too big to review, that is not a review problem, it is a prompting problem. Break it up and go again.

   Human checkpoint — you own the architecture and the boundaries between modules. Ask the agent for options and trade-offs; make the choice yourself.

5. Let AI write the tests, but you define “working”

   Test writing is the best-value AI task in the whole pipeline: it is repetitive, it has a clear right answer, and modern tools also repair tests that break when the interface changes. But AI writes tests for the code that exists, which means it happily confirms the behaviour you did not want. So write the acceptance criteria yourself first, then let the tool fill in the coverage around them.

   Human checkpoint — add the nasty cases nobody generates: the double-click, the expired token, the 3G connection, the hostile input, the empty account.

6. Put a second AI on review — and a person on approval

   An automated reviewer on every pull request catches a lot of what a tired human misses: logic slips, missing error handling, leaked keys, known vulnerable dependencies. Run static analysis and dependency scanning in the same pipeline. Then a named human approves the merge. This matters more than it used to, because the volume of code has gone up and review capacity has not.

   Human checkpoint — no AI-approved merges. A person’s name goes on every release.

7. Measure the outcome, not the output

   Lines of code and number of pull requests are the wrong metrics; they always go up with AI. Watch the four that tell you whether you are actually faster: how long a change takes from start to live, how often you release, what share of releases cause a problem, and how long recovery takes. Add one more: rework — how much of last month’s AI-assisted code you have already had to rewrite.

   Human checkpoint — agree these numbers before the AI rollout, not after. Otherwise you will be arguing about vibes in three months.

The honest numbers

You will read a lot of confident claims about AI productivity. The research is more interesting than the marketing, and it points in a specific direction: feeling faster and being faster are not the same thing.

The centrepiece is a randomized trial by the non-profit research group METR. Sixteen experienced developers worked on 246 real tasks in codebases they already knew. They expected AI to make them roughly a quarter faster. Afterwards, they believed it had. The measured result was 19% slower.

Two honest caveats, because that number gets over-quoted. It tested early-2025 tools on senior engineers in codebases they knew intimately — close to the hardest case for AI to help. And METR’s own February 2026 follow-up concluded that developers are probably now genuinely faster with today’s agent tools, while being careful to say their new data is weak evidence for how much. So the takeaway is not “AI does not work”. It is that self-reported speed is unreliable in both directions, which is exactly why step seven above exists.

Developers themselves report the same friction. In Stack Overflow’s 2025 survey of more than 49,000 developers, 84% said they use or plan to use AI tools — while trust in the accuracy of those tools fell to 29%. The single biggest frustration, named by 45%, was answers that are almost right but not quite, because those take longer to debug than writing the code yourself. “Almost right” is the characteristic failure mode of this technology, and it is the one your process has to be built around.

The security picture is the part to take seriously. As generated code volume rises, so does the number of findings, and the flaws are shifting from trivial syntax mistakes to deeper structural ones — broken permission checks, unsafe data handling, missing validation. These are exactly the defects a quick skim does not catch. One 2026 analysis of more than 300,000 AI-authored commits found that roughly four in ten AI-introduced security issues survived review and made it into the main branch.

Putting AI inside the product

Everything so far was about using AI to build. This section is about shipping AI features — search that understands a question, a support assistant, automatic summaries, tagging, extraction from documents. It is a genuinely different engineering problem, because the output is not deterministic: the same input can produce a different answer tomorrow.

The most common and most expensive mistake here is overbuilding. Teams jump straight to a vector database and a fine-tuned model when a well-written prompt would have shipped in two days. Climb the ladder instead.

Three things that decide whether an AI feature survives

1. An eval set, written before the second feature. An “eval” is a plain test set for something that has no single right answer: 20 to 50 real inputs, each with the answer you would accept and the answers you would not. Run it on every prompt change. Without it, prompt tuning is superstition — you fix one case and silently break four.

2. Cost and latency as design constraints. Know your cost per user per month before launch, not after. Cache the stable parts of your prompts, route easy requests to a cheaper model and hard ones to a strong model, and stream responses so the interface feels alive while the model thinks.

3. A visible way to be wrong. Show sources. Let people correct the output and log every correction — that log is your next eval set. Make the feature’s confidence legible, and never let a model take an irreversible action, such as sending money or deleting records, without a human confirming.

Six mistakes we see most often

• Shipping a prototype as a product. Prompt-to-app builders are excellent at demos. The generated app frequently has weak or missing access controls, and public examples of exposed data from AI-built apps are easy to find. Treat every generated app as untrusted until it has passed a real security review.
• No spec, then blaming the model. An agent given a vague instruction will make its own assumptions and implement them convincingly. Most “the AI got it wrong” incidents are missing-requirement incidents.
• Reviewing generated code more loosely than human code. It should be the opposite. The code is fluent, confident, and did not come from someone who understood your business.
• Letting juniors skip the understanding. The tool will happily do the learning task for them. Have them explain the generated code back, and pair on the parts they cannot. A team that cannot debug without AI is one outage away from finding out.
• Pasting secrets, customer data or client code into whatever tool is open. Pick approved tools, check the data retention terms, and make the rule explicit.
• Measuring adoption instead of outcomes. “80% of engineers use AI weekly” tells you nothing about whether your product got better, cheaper or more stable.

A 30-day starting plan

If you are introducing AI into an existing team, do it in this order. It is deliberately unglamorous.

Where this is heading

The clear direction of travel is that writing code becomes a smaller share of the job and specifying, reviewing and verifying become a larger one. That rewards a skill set that has always mattered and is now decisive: knowing exactly what you want to build, being able to describe it precisely, and being able to tell whether what came back is correct.

Which is the quiet good news for anyone worried about being replaced. The bottleneck was never typing. It was understanding the problem well enough to be sure. AI does not remove that work — it makes it the whole job.

Frequently asked questions

Can I build a whole website or app with AI and no developer?

For a prototype, a landing page or a simple internal tool — often yes. For anything holding customer data, taking payments or needing to stay up, you still need someone who can read the code, judge the architecture and own the security. The tools have made the first 70% dramatically faster; the last 30% is where products succeed or fail, and it is still engineering.

Which AI coding tool should we choose?

Match the tool to the task size rather than looking for one winner: autocomplete in the editor for small work, an editor agent for multi-file changes, a terminal agent for long refactors and test suites, and a prompt-to-app builder for prototypes. Most teams end up running two. Trial them on your own codebase for two weeks — general benchmarks tell you very little about your stack.

Is AI-generated code safe to use in production?

It is safe under the same conditions any code is safe: it has been read by someone accountable, it has tests, it has passed security and dependency scanning, and it can be rolled back. What is not safe is treating generated code as pre-reviewed because it looks polished. Review data consistently shows more logic and security defects in AI-authored changes than human-authored ones.

Will AI make our project cheaper?

Usually it changes where the money goes rather than removing it. Less time on boilerplate, tests and first drafts; more time on specification, review and verification — plus a running bill for tools and, if you ship AI features, for model usage. Teams that cut review to bank the savings tend to pay it back later as rework and incidents.

What is the single highest-value place to start?

Tests and code review. Both are repetitive, both have verifiable output, and both make everything else you do with AI safer. Starting with feature generation before you have review and tests in place is how teams get the speed without the quality.

Sources and further reading

• DORA, State of AI-assisted Software Development 2025 — near-universal adoption; AI as an amplifier of existing strengths and dysfunctions; throughput up alongside delivery instability.
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — the randomized trial behind the 19% figure.
• METR, We are Changing our Developer Productivity Experiment Design (February 2026) — the follow-up that revises the picture upward, with caveats.
• Stack Overflow Developer Survey 2025 — AI section — 84% using or planning to use AI tools, trust in accuracy down to 29%, and “almost right” answers as the top frustration.
• CodeRabbit’s comparison of AI-authored and human-authored pull requests, and 2026 application-security analyses of AI-generated code, for the defect and vulnerability rates cited in Fig. 04.