Durante os últimos meses, tivemos a oportunidade de falar com muitos técnicos de topo, engenheiros e gestores de várias grandes empresas de tecnologia graças a Disrupt e outros eventos tecnológicos em Bay Area. Muitas pessoas do público em geral estão familiarizadas com o termo geração de código fonte e como o software é normalmente construído. Mas quando falamos com técnicos, especialmente aqueles que acompanham o desenvolvimento de software moderno, temos a questão de como AppMaster difere de GitHub Copilot. Essa é uma questão bastante interessante.
Se estiver a ler o meu post, provavelmente já ouviu falar de Copilot - uma ferramenta de IA para o completamento e geração avançada de código fonte. Copilot já é uma ferramenta bastante boa para a programação assistida quando o programador escreve apenas uma parte do código fonte, e a IA oferece o completamento de código, mesmo funções inteiras. Especialmente bom Copilot no preenchimento de padrões e dicionários: escreva um par de itens, e o resto será automaticamente gerado. De acordo com o feedback da comunidade e os recentes postos de CEO GitHub, Copilot está a crescer a um bom ritmo.
Ao contrário de Copilot, AppMaster está concentrado em gerar o projecto de software completo em vez das peças. AppMaster acumula requisitos para todo o projecto: aplicações de servidor (backend), aplicações web, aplicações móveis, e todas as coisas complementares. Em geral, reunimos do esquema de modelos de dados do engenheiro, lógica de aplicação, pontos finais, elementos de interface, e todos os requisitos padrão para a futura aplicação no formato visual drag-and-drop. A abordagem tudo-em-um permite aos engenheiros de software fazer menos para obter mais.
Para obter uma melhor compreensão, dou-lhe um pequeno exemplo.
Fazer uma chamada API da aplicação web ou móvel para o servidor/backend é uma das tarefas mais comuns. Normalmente, o engenheiro tem de analisar a documentação da API do servidor e criar a estrutura do pedido/resposta e todo o código correspondente. A mesma tarefa pode ser realizada com uma acção dran&drop em AppMaster. Uma vez que a plataforma sabe tudo sobre modelos de dados e pontos finais, ela pré-gera automaticamente blocos visuais para fazer pedidos API indolores, incluindo a estrutura de objectos correspondentes. E ainda mais: após cada alteração dos modelos de dados, a lógica empresarial ou plataforma de endpoints actualiza automaticamente os elementos dependentes da interface de utilizador sem intervenção de engenheiros.
Do lado parece que AppMaster e Copilot estão a tentar resolver problemas diferentes, estamos a trabalhar no mesmo problema de engenharia de software, mas as nossas abordagens são bastante diferentes. Enquanto Copilot decidiu ajudar os engenheiros de software a escrever mais código mais rapidamente e mais facilmente, concentrámo-nos em mudar o paradigma de desenvolvimento de software, passando da criação de software, escrevendo o código do programa, para apenas definir os requisitos de alto nível. Ter os requisitos dá-nos o enorme benefício da capacidade de regenerar toda a base de código do projecto a partir do zero. Podemos fazer a regeneração por qualquer razão: quando os requisitos são alterados, quando estão disponíveis algoritmos melhorados de geração de código, para actualizar a linguagem de programação ou versões de bibliotecas, ou mesmo para alterar toda a pilha de tecnologia!
Acreditamos no futuro com a abordagem"Don't touch the source code" e requisitos de alto nível para engenharia de software.
O que pensa? Demasiado bom para ser verdade? Utopia?
P.S. Se estiver interessado no campo, verifique o último podcast Lex Fridman com Andrei Karpathy, ex-Director de IA de Tesla, sobre Software 2.0 e geração de código.
