What should the prototype do?
Describe the behaviour before you ask an AI tool for any code. Who is the user, what are they trying to do, what do they enter and what result do they expect? A small, concrete example helps a great deal: “a visitor enters a name, an email address and a short message; the message is saved and the visitor sees a confirmation” is far easier to build and to check than “make a contact form”.
Say straight away which input counts as invalid and what the program should do when something goes wrong: an empty field, a mistyped email address, an external service that does not respond. If you leave this out, the generated code will usually cover only the case where everything goes smoothly.
Ask for one limited change at a time, small enough to inspect, instead of an ever-growing list of features. Keep the prototype under version control so that you can return to the last working state when a change breaks something. And label sample data and interface demos clearly, so that nobody mistakes a demo screen for a working feature.
How do you check the whole journey and the code?
Test the complete journey, not just the screen you happened to be working on. Go through normal completion first, then try leaving inputs empty and repeating actions: what happens if someone submits the same form twice, or reloads the page halfway through?
Then look beneath the surface. Find out where the data is stored, which external services the code calls and how access is checked. Passwords, API keys and other secrets must never end up in code that runs in the browser or in the repository. Generated code needs an independent review, particularly around authentication, input from outside and anything that changes records. The OWASP guidance on secure coding with AI, listed below, is a good starting point for that review.
Finally, check the actual result. A “Done” message on the screen does not mean the data was really saved or the email really sent. Open the database, the inbox or the target system and confirm that the intended operation completed.
Is the prototype ready for real use?
A prototype can answer a usability or product question without being ready for production. These are two different kinds of readiness, and it is worth keeping them apart explicitly. A prototype that shows users understand the journey has done its job, even if it would not cope with real traffic or a careless user.
Write down what you have learnt: the known limitations, the tests you ran and their results, and the changes needed before real operation. If the prototype moves forward, plan deployment, monitoring, recovery and support before launch: at this point it becomes MVP development. These are the parts that are easiest to overlook when a prototype has been put together quickly with AI tools.
For learning purposes, keep the goal explicit: understanding a user journey and being able to review a small implementation. That is a realistic and valuable outcome. Promising that every generated application is ready to launch is not.
Checklist: prototype review
- Describe a small behaviour, including invalid input and failure states.
- Ask for small changes and keep a version you can return to.
- Review the generated code, permissions, secrets and external calls.
- Check the real result in the database or target system, not only the message on screen.
- Record the limitations and what is needed for real operation.
A worked example
Example: a prototype collects a project brief and saves it as a file. Before it can send real enquiries, the team adds a server-side integration, error handling and spam protection, and tests each one.
