How to Build a Production-Ready Application in Two Days

Principal Data Scientist

How do you build a production-ready app in only two days?
Do it four times.

Yes, that’s technically eight days! But hear me out. In my previous post I argued that Building Software Is No Longer a Nightmare, because AI coding assistants can take care of all the annoying peripheral tasks like packaging, testing, documentation, deployment, etc.

Here I want to propose that AI-assisted coding makes it easier than ever to return to the ultimate form of software engineering: “Throwaway Prototyping”. This concept was pioneered by Fred Brooks in his classic book “The Mythical Man-Month”1, where he coined the phrase, “Plan to throw one away; you will, anyhow.” Brooks refers specifically to the first iteration of a system – the prototype. I will expand this definition to the practice of discarding code and architecture multiple times till the problem and its solution are sufficiently understood.

Discarding code, refactoring, and revising architecture is often taken to be implicitly part of Agile methodology and Extreme Programming. However, I’ve seen it rarely practiced at enterprise due to the assumed high cost of throwing away working code, and the perceived lack-of-time to rebuild from scratch. Fortunately, all of these objections have become moot thanks to AI if one is willing to bear the token expense, that is.

AI-assisted Throwaway Prototyping is one of the best ways to allow a developer to achieve what used to require a small team of dedicated experts. This requires the developer to actively attempt to go beyond their limitations, i.e. leave their comfort zone.

Using AI to develop within your comfort zone will merely accelerate your code output, developing into unfamiliar territory will accelerate your product delivery.

I’ve found that a typical project using the Throwaway Prototyping approach tends to have four distinct phases each lasting 1-3 days. Each phase advances the problem understanding and solution approach. This is crucial: Throwaway Prototyping is meant to advance your understanding of the problem, unlike Vibe Coding which absolves the “developer” from this duty entirely.

I’ll describe the four phases of Throwaway Prototyping by using an example scenario. Let’s say you are an experienced Python developer with little JS experience. You are tasked with building a real-time audio communication app.

Phase 1: Comfort Zone + Personal Bias

You start in your comfort zone using the tools you are familiar with. As a Python developer you are familiar with FastAPI backend development. You focus on building the backend of the application, taking care of implementing the right routes. The way you understand the problem, you try to solve it with websockets and real-time streaming. Your bias tells you that you should solve this problem using object-oriented programming.

After two days, you realize that your beautifully designed architecture and clean code doesn’t really work. The audio processing is unreliable, possibly due to lost packets. With a heavy heart you decide to throw away the first prototype.

Phase 2: Comfort Zone + Overcoming Personal Bias

The first prototype taught you that the real-time streaming approach is overly complex and not really necessary to make the application work.

You start anew, careful to overcome your biases. You focus on the core issue and re-design the backend communication from scratch. A much simpler approach of synchronous data exchange using the POST method is more robust while not substantially increasing latencies.

Now your focus shifts to the frontend. With little JavaScript experience, you realize you are in over your head. While the backend is rock-solid and responds reliably when tested in isolation, the frontend is brittle and sluggish. You throw away the entire frontend code base.

Phase 3: Stretch Zone + AI Bias

Your second prototype taught you that the problem can be solved using synchronous communication and that you lack FE experience.

You leverage AI to revise the frontend architecture and rebuild it from scratch. Your solid backend architecture together with the well-defined routes serve as design specifications. These can be can be used to prompt the AI to select the right frameworks and implementation approach for the frontend. However, the AI has its own biases and the code grows organically as you try to nudge it toward your envisioned user experience.

You’re impressed! The AI got much closer to building a responsive, feature-rich application than you ever could have. But the frontend codebase has evolved into a mess. The AI scattershot changes across the entire code base whenever you asked it to address issues or add new features. You are unable to keep up with the AI and start to worry about the rapidly accumulating technical debt.

You don’t know who you should be more disgusted with, the AI or yourself. How could you have let things devolve so quickly in the pursuit of rapid development? You throw away the third prototype.

Phase 4: Stretch Zone + Overcoming AI Bias

You now have a clearer picture of what the frontend architecture needs to accomplish. Working together with the AI coding assistant on the third prototype taught you a lot about frontend engineering. Your prompts are now more informed and you are able to direct the AI on choices like signals vs observer patterns, template literals vs web components, etc.

A mature backend is now joined with a clean and functional frontend. AI assistance allowed you to repeatedly throw away code and start from scratch. This way you were able to incorporate new learnings at each iteration free from the constraints of pre-existing code.

Conclusion

There is no doubt that AI-assisted coding is already transforming the industry. A tsunami of AI-generated slop will be one outcome of this development. I’m hopeful that we can also use AI to grow as engineers while building better products. My version of AI-assisted Throwaway Prototyping illustrates how this human-AI collaboration could look like:

AI-Assisted Throwaway Prototyping

1. Comfort zone +
Bias
2. Comfort Zone +
Overcome Bias
3. Stretch Zone +
AI Bias
4. Stretch Zone +
Overcome AI Bias
  • Use what you know
  • Solve problem your way
  • Use what you know
  • Solve problem based on what you learned previously
  • Use AI to extend out of comfort zone
  • Accept AI bias
  • Use AI to extend out of comfort zone
  • Direct AI to overcome its (default) bias
© 2024 talesofindustry.org