What building with AI means

Building an app with AI is not the same as telling AI to make an app and waiting for it. AI, especially a coding agent that can read files, write code and run commands on its own, does most of the typing. It writes forms, server routes, database tables and tests in minutes. Work that once needed a small team can now be started by one person.

But writing speed is not the hard part of building an app. The hard part is deciding what to build, making sure what was built is right, and keeping the app alive once other people use it. That part stays your job. In this book you are called the builder: the person who decides, reads, tests and releases. AI is the partner that writes fast, never tires, and is sometimes confident about the wrong thing, exactly as you learned in AI Foundations.

The whole book follows one loop: Plan, Build, Check, Release. In Plan you write what gets built and how you will know it is right. In Build AI writes code, one small change at a time. In Check you read that change and run the tests, not just read the AI's report. In Release you move the app to a server in a way that can be undone. AI helps in all four stages, but the decisions in each stage are yours.

Two things often get mixed up: a prototype and an app ready for other people. A prototype is a quick version to see whether an idea makes sense. Its data can be fake, only you use it, and if it breaks nobody is hurt. How to make one is covered in the making prototypes lesson, and AI is very good at making them.

An app ready for use must hold up against things that never happen in a prototype: real data that must still be there tomorrow, people who may only see their own data, empty or odd inputs, two people saving in the same second, secret keys that must not leak, and a new version that must be reversible if it breaks. The gap between the two is not about looks. A prototype and a ready app can look exactly the same on screen. The difference is in what you cannot see, and those things are what most of this book is about.

Your first app should be small, real and cheap if it fails. Pick a problem that you or your team handle today with a spreadsheet, a group chat or paper notes, for a small group of people you know and can ask. Avoid sensitive data such as health data, personal financial data or ID numbers until you have finished the security chapter. Also avoid payments and sign-up open to the public. A good size: the first version can be done in a few days, with one kind of user and one main flow. The example you will often see in this book is a team equipment-loan tool: who borrowed what, when, and when it came back.

To be honest from the start, here is what this book promises and what it does not. When you finish it, you can build a small web app with AI, read the changes it writes well enough to catch common mistakes, write tests, keep a history of your work with version control, and release the app to a server in a way that can be undone. You will also know when a job is beyond you and needs an experienced engineer.

This book does not promise that you will become a senior engineer, or that AI will make a large app without problems. A coding agent can write hundreds of tidy-looking lines and still be wrong in one place that matters. It can report tests passing when those tests were never run. It can change files you did not ask about. These things happen to us too, and the case at the end of each chapter tells some of them, including how we found out and the rule we keep now.

The order of the book: four foundation chapters (this one, the web app map, setting up your machine and from idea to spec), then core skills such as reading code and asking for small changes, then tools in practice such as the terminal, git and releases, then a more mature way of working with test-first and separate reviewers. There are four projects along the way, and each builds on the one before.