How to build an MVP with AI agents

Building a minimum product has become faster with AI agents that write, test and fix code. But coding speed does not answer the main question of an MVP: does anyone have this problem and want this solution?

This tutorial organizes the path into seven steps. It draws on methodological references (Eric Ries’s idea of the MVP), official documentation for agent tools and OWASP security guides. It does not report the newsroom’s own experience. The example that runs through the steps is hypothetical and serves only as an illustration.

If you don’t yet know how an agent decides on and executes steps, first read what AI agents are.

What an MVP is, and what it is not

Eric Ries, author of The Lean Startup, defined the MVP in an August 2009 post as the version of a new product that allows a team to collect the maximum amount of “validated learning” about customers with the least effort.

The core point is learning, not size. In the same post, Ries says the MVP has no formula and requires case-by-case judgment. The Lean Startup principles page describes the build, measure, learn loop: turning ideas into products, measuring how customers respond and deciding whether to persevere or pivot, a change of course to test a new fundamental hypothesis.

This changes the role of the AI agent. It lowers the cost of “building”. Measuring and learning still depend on you and your users.

Hypothetical example. Throughout the article, imagine someone who wants to create a simple appointment reminder system for small clinics.

Step 1: define the problem and the success metric

Before opening any tool, write three sentences:

1. Who has the problem: for example, receptionists at small clinics.
2. What the problem is: patients miss appointments because they forget them.
3. What result would show the solution works: an observable metric, with a deadline.

In the hypothetical example, the metric could be: “of the clinics that test it for four weeks, how many keep using it without anyone asking them to”. The number that counts as success is your decision, made before the test, to avoid moving the goalposts afterward.

The Lean Startup calls this discipline innovation accounting: measuring progress, setting milestones and prioritizing work based on what you learn.

Step 2: cut the scope until the hypothesis fits

List everything the product “should” have and strike out what is not needed to test the hypothesis. Social login, a reporting dashboard and a mobile app can wait.

One question helps: if this feature disappears, can I still measure the metric from step 1? If the answer is yes, it stays out.

A small scope also helps the agent. The Claude Code best practices guide recommends specific requests and, for larger features, asking the agent to interview you and write a specification before implementing. According to the guide, the most useful specifications state which files and interfaces are involved and what is out of scope, and end with an end-to-end verification.

Step 3: choose the stack and the level of autonomy

The stack is the product’s set of technologies: language, framework, database and hosting. For an MVP, prefer established technologies that you can maintain and debug without the agent. If only the agent understands the code, you depend on it for any fix.

There is a second choice: does your product need an agent inside it, or will you only use agents to build it? These are different things.

For those considering putting an agent in the product, Anthropic, in Building effective agents (December 2024), recommends starting with the simplest possible solution and only increasing complexity when needed. Often, according to the piece, a single well-prepared call to a model is enough. Agentic systems usually trade latency and cost for better performance, and autonomy can compound errors across steps.

In the hypothetical example, a reminder sent at a fixed time needs no agent at all. An agent would only be justified if the task required deciding on unpredictable steps.

Step 4: use coding agents with tests and review

This is where the coding agent actually comes in. Three practices appear in Claude Code’s official documentation and apply, in spirit, to similar tools.

Give the agent a way to verify its work. The best practices guide notes that the agent stops when the work “looks done”. With automated tests, a build or a script that compares the output with what is expected, it runs the check, reads the result and iterates until it passes. The guide is blunt: if you can’t verify it, don’t ship it.

Explore, plan and only then implement. The suggested workflow separates reading the code, a written plan, implementation and commit. For small, obvious changes, the guide itself says the plan can be skipped.

Ask for independent review. The guide suggests that a second session, or a subagent with a clean context, review the change against the plan, because whoever wrote it tends to be biased in favor of their own code. The same passage warns against overdoing it: a reviewer instructed to find problems almost always finds some, and chasing all of them leads to unnecessary complexity.

In practice, work in short tasks, one feature at a time, with version control (git) so you can undo. To understand how one of these agents works in detail, see how Claude Code works.

Step 5: address security from day one

An MVP with real customer data is already exposed to real attacks. There are two sides to take care of.

The agent that builds the code. It runs commands on your computer. Claude Code’s permission modes documentation, consulted on October 8, 2026, recommends the mode that allows everything without asking (bypassPermissions) only for isolated containers and virtual machines. Never give the agent production credentials it doesn’t need.

The product you deliver. The OWASP Top 10:2025, the reference list of web application risks, starts with broken access control (A01) and includes authentication and injection failures. Agent-generated code must go through the same checks as handwritten code.

If the product has a language model inside it, also consult the OWASP Top 10 for LLM Applications, 2025 edition. Three items weigh heavily on an MVP with an agent:

• Prompt injection (LLM01): malicious text, including text hidden in websites or files the model reads, alters its behavior. The risk page says no foolproof prevention is known and recommends least privilege, human approval for high-risk actions and segregating external content.
• Excessive agency (LLM06): the system has more tools, permissions or autonomy than it needs. The risk page suggests narrow tools instead of generic shell access, credentials with minimal permissions, human approval for actions such as sending messages or deleting data, and authorization checked outside the model.
• Unbounded consumption (LLM10): see the next step.

In the hypothetical example, the reminder system should never let the model decide on its own whom to send messages to; that rule stays in the code, with permissions checked.

Step 6: control costs

Agents charge by usage, usually in tokens, the units of text the model processes (see tokens in AI models). There are two costs to watch.

The cost of building. Claude Code’s costs page, consulted on October 8, 2026, states that spending varies widely depending on the model, codebase size and usage pattern. It recommends clearing the context between unrelated tasks, choosing a smaller model when the task allows, writing specific requests and using plan mode on complex tasks to avoid rework. On API accounts, you can set spending limits per workspace.

The cost of operating. If the product calls a model on every user action, spending grows with usage, and also with abuse. OWASP’s page on unbounded consumption describes the denial of wallet attack, in which someone fires off calls in volume to generate costs. The defenses listed include rate limiting and per-user quotas, input size validation, maximum time per operation and monitoring for abnormal patterns.

Before opening the MVP to the public, estimate the cost per active user and set a ceiling you are willing to pay if something goes wrong.

Step 7: validate with real users

Working code is a prerequisite, not a result. Go back to the metric from step 1 and put the MVP in the hands of people who have the problem.

Some precautions:

• Measure behavior (usage, return visits, payment), not just praise.
• Keep a log of what you changed and why, so you know which change caused which effect.
• Decide in advance what you will do if the metric is not met: adjust, pivot or stop.

Ries notes in his 2009 post that learning something from an MVP takes real effort, such as talking to customers or analyzing data. An agent speeds up building, but it does not replace those conversations.

Key takeaways

• The goal of an MVP is validated learning; define the problem, hypothesis and metric before coding.
• Cut the scope until the test fits, and only put an agent inside the product if the task really requires unpredictable steps.
• Use coding agents with small tasks, tests they can run and independent review.
• Apply least privilege, human approval for high-impact actions and usage limits, following OWASP’s references.
• Tool costs and features change frequently; check the official documentation on the date you make your decision.