The Prototype Trap

When we use AI coding tools we have to be careful that we do not fall into the prototype trap. Then just because we can prompt a prototype in a few hours does not mean we can take a few additional sessions and turn it into an application. Let us see what I mean by that.

What is a prototype?

Prototypes come in all forms and shapes. They have in common that we create them to answer a specific question and we only build enough to get an answer. We can do that to test if an interaction on a user interface works better this way or another. Or we try to see if a certain algorithm is robust enough to handle real data. Or we want to figure out if the latency is neglectable when we host the application at a remote location.

All those prototypes will be focused on a single problem and ignore everything else. There will be no authentication, no audit trail, only basic logging (if at all), no nice user interface or even enough of an application that you could run it outside of an IDE.

By skipping everything that we do not need to answer a question, we massively reduce the amount of code we need to write, and by thus save a lot of time.

What is the trap?

Prototypes fulfil a purpose, how can there be a trap? The trap comes from not knowing when you build a prototype and when you build an application. Just because a certain part of the application could be tested with a prototype does not mean we can extrapolate the time it took to build that slice to get to the full application. There is much more to be put into an application that what we put into the prototype. That skipped over features (and basic necessities) are neglected over and over again, leading to all sorts of problems when we try to grow a prototype into an application.

It may look like an artificially created problem, but unfortunately that is not the case. If you ever had a nice user interface mock-up to show to the management to explain what the application could look like, you noticed the disbelief that this screen is not the whole application. The mask they were focused on was there, so how could it take months to build it?

If you use vibe coding or a more structured approach, the AI coding tool looks the same. Even worse, you do most of the things the same way. That makes it so hard to keep prototypes separate from applications.

What could go wrong?

The prototype you only run on your developer machine does not need authentication and it does not matter where you put your API keys. They never leave your machine, and you are the only one who uses it. If you do the same things to your application and ship it, you could expose your API keys to the world. Should that happen you have a big problem. You may go to sleep with your world in order and wake up a few hours later with a fee so high that you are bankrupt. Just google for incidents in which bills of $80’000 or more happened in just a few hours because of misused keys.

Another way to get to the same financial problems is if your tools constantly make requests to paid endpoints. If you do not put any checks in place, your bill can run into the thousands in no time.

Even worse if the secrets you expose are business secrets or private personal information (PPI) - this could result not only in a hefty fine but also in legal proceedings.

How can we prevent this?

The first thing to do is to be clear on what you create. Do you want to build a full-scale application? Or do you want to build a prototype to check a tiny bit of the functionality? Do not start prompting before you can answer this question!

When you know the answer to this question, act accordingly. If you need a prototype, do not add a fancy layout that matches your corporate identity guidelines. Make it visually clear that this thing should never see the light of day. The worse it looks, the better it shows that this thing here is a prototype.

If you write a readme file, make it clear at the top of the file that this is a prototype and what it is for. Write down your questions, and even more importantly, write down the limitations. The more specific this text is, the simpler it is to use it in your AI coding tool as requirements or part of your prompt.

Follow some basic safety rules even when you just write a prototype. Do not write down passwords in your application. Use .env files, environment variables or for SQL Server, authenticate your Windows user to access your developer database. Should your prototype land in production, those precautions give you a little bit of protection against the most basic attack vectors.

If it is an application you need, make sure that those security considerations are part of your initial design. It will take a lot more time to get to your first line of code, but that is a small price to pay considering the potential disastrous outcome.

Next

A prototype is not an application. For a prototype we can skip most of the things we need in an application. That gives us speed, what is great when we want to figure out a specific design detail. It is an invitation for a disaster when we then put this prototype into production without spending any time on making it production ready. That is a certain way for a costly mistake. Next week we take a deeper look at requirements and how they matter even more when it comes to AI coding tools.