De afgelopen maanden hebben we dankzij Disrupt en andere tech-evenementen op Bay Area de kans gekregen om met veel technische topmensen, ingenieurs en managers van verschillende grote techbedrijven te praten. Heel wat mensen uit het grote publiek zijn vertrouwd met de term broncodegeneratie en hoe software gewoonlijk wordt gebouwd. Maar als we praten met techmensen, vooral degenen die de moderne softwareontwikkeling bijhouden, krijgen we de vraag hoe AppMaster verschilt van GitHub Copilot. Dat is best een interessante vraag.
Als u mijn bericht leest, hebt u waarschijnlijk gehoord over Copilot - een AI-tool voor geavanceerde broncode-aanvulling en -generatie. Copilot is al een behoorlijk goed hulpmiddel voor ondersteunend programmeren wanneer de ontwikkelaar slechts een deel van de broncode schrijft, en AI biedt code-aanvulling, zelfs hele functies. Bijzonder goed is Copilot in het aanvullen van patronen en woordenboeken: schrijf een paar items, en de rest wordt automatisch gegenereerd. Volgens de feedback van de gemeenschap en recente berichten van de CEO van GitHub groeit Copilot in een goed tempo.
In tegenstelling tot Copilot is AppMaster gericht op het genereren van het volledige softwareproject in plaats van de stukken. AppMaster verzamelt vereisten voor het volledige project: serverapplicaties (backend), webapplicaties, mobiele applicaties, en alle aanvullende zaken. In het algemeen verzamelen we van engineer datamodellen schema, applicatielogica, endpoints, UI-elementen, en alle standaard vereisten voor de toekomstige applicatie in het visuele drag-and-drop formaat. De alles-in-één aanpak laat software ingenieurs minder doen om meer te krijgen.
Voor een beter begrip geef ik een klein voorbeeld.
Een API-aanroep doen vanuit de web- of mobiele applicatie naar de server/backend is een van de meest voorkomende taken. Gewoonlijk moet de ingenieur de API-documentatie van de server inkijken en de structuur van het verzoek/antwoord en alle bijbehorende code maken. Dezelfde taak kan worden uitgevoerd met één dran&drop actie in AppMaster. Aangezien het platform alles weet over datamodellen en endpoints, genereert het automatisch vooraf visuele blokken om pijnloos API-verzoeken te doen, inclusief bijbehorende objectenstructuur. En nog meer: na elke wijziging van de datamodellen, werkt het business logica of endpoints platform automatisch de afhankelijke UI-elementen bij zonder tussenkomst van de ingenieur.
Vanaf de zijkant lijkt het alsof AppMaster en Copilot verschillende problemen proberen op te lossen, we werken aan hetzelfde software engineering probleem, maar onze benaderingen zijn heel verschillend. Terwijl Copilot besloot software-ingenieurs te helpen sneller en gemakkelijker meer code te schrijven, richtten wij ons op het verschuiven van het softwareontwikkelingsparadigma van het maken van software door het schrijven van programmacode naar het definiëren van vereisten op hoog niveau. Het hebben van de eisen geeft ons het enorme voordeel van de mogelijkheid om de hele projectcodebasis vanaf nul te regenereren. Wij kunnen de regeneratie om elke reden doen: wanneer de eisen zijn veranderd, wanneer verbeterde algoritmen voor het genereren van code beschikbaar zijn, om de programmeertaal of bibliotheken bij te werken, of zelfs om de hele technische stapel te veranderen!
Wij geloven in de toekomst met de"Don't touch the source code" aanpak en hoge eisen voor software engineering.
Wat denkt u? Te mooi om waar te zijn? Utopia?
P.S. Als u geïnteresseerd bent in het veld, bekijk dan de laatste Lex Fridman podcast met Andrei Karpathy, Tesla's ex-directeur van AI, over Software 2.0 en codegeneratie.
