They’ve created a GPT Web App Generator and realized AI is not going to replace developers
![](https://shiftmag.dev/wp-content/uploads/2023/08/GPT-Web-App-Generator.png?x73249)
![](https://shiftmag.dev/wp-content/uploads/2023/08/GPT-Web-App-Generator.png?x73249)
Don’t worry; developers are not getting replaced with AI, and there is still a lot of programming to be done by humans. It may only be done faster in some instances.
What’s especially reassuring is that these words come from the co-founder of a dev tool startup that recently launched a GPT Web App Generator. It works almost like magic – you describe the web app you’d like to create in plain English, and in a matter of minutes, a full-stack web app codebase written in React, Node.js, Prisma, and Wasp is generated, available for you to download, run it locally and deploy with a single CLI command.
But it’s not magic, nor an attempt to make developers obsolete. It’s just an experiment created by the team behind Wasp, an open-source, full-stack framework for React & Node.js.
Developers do more than just programming
Although Wasp is also in the business of automating and speeding up a lot of the developers’ work, its co-founder Matija Šošić says there is no such tool that can fully replace developers:
First, developers do much more than programming – planning, communication, architecture, etc. Many things have to happen, and decisions have to be made before we can finally fire up our favorite code editor and start typing.
Another thing is that the code isn’t going away – it still needs to be written, understood, and maintained and serves as a unique specification of how your app works. Also, the libraries and frameworks need to keep progressing – we can’t stay forever on, e.g., React 18, and that’s it.
The challenges of creating a GPT Web App Generator:
1) The first challenge was to become better at writing prompts. Since GPT is a black box from the usage perspective, it took time to try it out for our use case (building web apps) and learn what is too little and what is too much information. After a few days of experimenting, we figured out the correct approach and started seeing pretty consistent results.
2) Another way to battle GPT’s non-determinism is to provide some fixed boundaries for it to operate within, reducing search space and minimizing the amount of errors. It’s where the simplicity and declarative nature of Wasp framework came in handy. With the basic setup of a new Wasp app, we could ensure the app has the whole, full-stack architecture correctly in place, along with the authentication system.
3) App generation is divided into three main phases:
- Generating an implementation plan (from the user’s input)
- Implementing the files that are part of the implementation plan
- Fixing errors
Initially, we would use GPT-4 for all the phases, but then we discovered it was unnecessary. The first step, plan generation, is the most complex, and using GPT-4 for it makes a difference. On the other hand, file implementation and error fixing are straightforward enough to be performed well by GPT-3.5 (GPT-4 still provides better results, but only marginally).
With that approach, we managed to reduce the cost of the generated app to $0.10 – $0.20. For the comparison, some of the other GPT coding agents we tried took up to $10 to generate the same kind of application.
![](https://shiftmag.dev/wp-content/uploads/2023/05/Shift-Miami_conference-1024x538.png?x73249)
Frameworks and LLM will keep advancing together
Matija and his co-founder (and twin brother) Martin have been building web apps for nearly 15 years before creating Wasp and have gone through pretty much all the major stacks, starting from PHP/Java to jQuery/Backbone/Angular and finally React/Node.
Every time they would start a new major project, there was a new stack to learn to figure out the best practices of that particular stack, and it would just get more complicated each time.
That motivated us to start experimenting with the idea of Wasp – we wanted a solution that wouldn’t drastically change with every new library/framework. Thus, the config language, which is very “human readable”, pretty much a specification of your app and isn’t dependent on the specific technology.
![](https://shiftmag.dev/wp-content/uploads/2023/08/martin-matija-sosic-1024x538.png?x73249)
They wanted to simplify the whole DX, reduce the boilerplate code, and make sure best practices were set and enforced from the start. Also, the key was to make sure their solution was not reinventing the wheel and that it still works with the dev’s favorite technologies, such as React and Node.js. That would be, Matija says, crucial for adoption.
Ever since they’ve set out to build Wasp, Matija and Martin got the same question:
Why are you bothering to create a new language for web app development? Isn’t Github Copilot soon going to generate all the code for developers?
Matija says they believe Wasp is what’s the future of web development. For humans and machines alike:
Wasp’s declarative nature and higher-level abstractions is what make it easy for LLMs to work with it and produce better, more consistent results. The same goes for humans.
This is the future of web development that goes hand-in-hand with the LLM-powered development. You can read more about our thesis on how both frameworks and LLMs will keep advancing together and power each other here.