For the past couple of months, we got a chance to talk with many top technical people, engineers, and managers from various big-tech companies thanks to Disrupt and other tech events across Bay Area. Quite a few people from the general public are familiar with the term source code generation and how software is usually built. But when we talk with tech people, especially those who keep track of modern software development, we get the question about how AppMaster differs from GitHub Copilot. That's quite an interesting question.
If you are reading my post, you have probably heard about Copilot - an AI tool for advanced source code completion and generation. Copilot is already a pretty good tool for assistive programming when the developer writes just a part of the source code, and AI offers code completion, even whole functions. Especially good Copilot at completing patterns and dictionaries: write a couple of items, and the rest will be automatically generated. According to the community feedback and recent GitHub CEO posts, Copilot is growing at a good pace.
Unlike Copilot, AppMaster is focused on generating the complete software project instead of the pieces. AppMaster accumulates requirements for the entire project: server applications (backend), web applications, mobile applications, and all complementary stuff. In general, we gather from engineer data models schema, application logic, endpoints, UI elements, and all standard requirements for the future application in the visual drag-and-drop format. The all-in-one approach lets software engineers do less to get more.
To get a better understanding, I'll give you a small example.
Making an API call from the web or mobile application to the server/backend is one of the most common tasks. Usually, the engineer has to look into the server API documentation and create the structure of the request/response and all corresponding code. The same task can be achieved with one dran&drop action in AppMaster. Since the platform knows everything about data models and endpoints, it automatically pre-generates visual blocks to make painless API requests, including corresponding objects structure. And even more: after each change of the data models, the business logic or endpoints platform automatically updates the dependent UI elements without engineer intervention.
From the side looks like AppMaster and Copilot are trying to solve different problems, we are working on the same software engineering problem, but our approaches are quite different. While Copilot decided to help software engineers to write more code faster and more easily, we focused on shifting the software development paradigm from creating software by writing the program code to just defining the high-level requirements. Having the requirements gives us the huge benefit of the ability to regenerate the entire project code base from scratch. We can do regeneration for any reason: when requirements are changed, when improved code-generation algorithms are available, to update programming language or libraries versions, or even to change the whole tech stack!
We believe in the future with the "Don't touch the source code" approach and high-level requirements for software engineering.
What do you think? Too good to be true? Utopia?
P.S. If interested in the field, check the latest Lex Fridman podcast with Andrei Karpathy, Tesla's ex-Director of AI, about Software 2.0 and code generation.
