W ciągu ostatnich kilku miesięcy mieliśmy okazję rozmawiać z wieloma osobami z najwyższego szczebla technicznego, inżynierami i menedżerami z różnych dużych firm technologicznych dzięki Disrupt i innym wydarzeniom technologicznym na Bay Area. Całkiem sporo osób z ogółu społeczeństwa zna pojęcie generowania kodu źródłowego i tego, jak zwykle buduje się oprogramowanie. Ale kiedy rozmawiamy z ludźmi techniki, zwłaszcza tymi, którzy śledzą nowoczesny rozwój oprogramowania, otrzymujemy pytanie o to, jak AppMaster różni się od GitHub Copilot. To dość interesujące pytanie.
Jeśli czytasz mój wpis, to prawdopodobnie słyszałeś o Copilot - narzędziu AI do zaawansowanego uzupełniania i generowania kodu źródłowego. Copilot jest już całkiem dobrym narzędziem do programowania wspomagającego, gdy deweloper pisze tylko część kodu źródłowego, a AI oferuje uzupełnianie kodu, nawet całych funkcji. Szczególnie dobrze Copilot radzi sobie z uzupełnianiem wzorców i słowników: napisz kilka elementów, a reszta zostanie automatycznie wygenerowana. Według opinii społeczności i ostatnich postów CEO GitHub, Copilot rośnie w dobrym tempie.
W przeciwieństwie do Copilot, AppMaster skupia się na generowaniu kompletnego projektu oprogramowania, a nie jego fragmentów. AppMaster gromadzi wymagania dla całego projektu: aplikacji serwerowych (backend), aplikacji webowych, aplikacji mobilnych i wszystkich dodatkowych rzeczy. Ogólnie rzecz biorąc, zbieramy od inżyniera schemat modeli danych, logikę aplikacji, punkty końcowe, elementy UI i wszystkie standardowe wymagania dla przyszłej aplikacji w wizualnym formacie drag-and-drop. Podejście all-in-one pozwala inżynierom oprogramowania robić mniej, aby uzyskać więcej.
Aby lepiej zrozumieć, podam mały przykład.
Wykonanie połączenia API z aplikacji internetowej lub mobilnej do serwera / backendu jest jednym z najczęstszych zadań. Zazwyczaj inżynier musi zajrzeć do dokumentacji API serwera i stworzyć strukturę żądania/odpowiedzi oraz cały odpowiadający jej kod. To samo zadanie można osiągnąć za pomocą jednej akcji dran&drop w AppMaster. Ponieważ platforma wie wszystko o modelach danych i punktach końcowych, automatycznie wstępnie generuje bloki wizualne do bezbolesnego wykonywania żądań API, łącznie z odpowiednią strukturą obiektów. I jeszcze więcej: po każdej zmianie modeli danych, logiki biznesowej lub punktów końcowych platforma automatycznie aktualizuje zależne elementy UI bez interwencji inżyniera.
Z boku wygląda na to, że AppMaster i Copilot próbują rozwiązać różne problemy, pracujemy nad tym samym problemem inżynierii oprogramowania, ale nasze podejścia są zupełnie inne. Podczas gdy Copilot postanowił pomóc inżynierom oprogramowania w szybszym i łatwiejszym pisaniu kodu, my skupiliśmy się na zmianie paradygmatu tworzenia oprogramowania z tworzenia oprogramowania poprzez pisanie kodu programu na definiowanie wymagań wysokiego poziomu. Posiadanie wymagań daje nam ogromną korzyść w postaci możliwości regeneracji całej bazy kodu projektu od podstaw. Regeneracji możemy dokonać z dowolnego powodu: gdy zmienią się wymagania, gdy dostępne będą ulepszone algorytmy generowania kodu, gdy zaktualizujemy wersje języka programowania lub bibliotek, a nawet gdy zmienimy cały stos technologiczny!
Wierzymy w przyszłość z podejściem"Don't touch the source code" i wysokopoziomowymi wymaganiami dla inżynierii oprogramowania.
Co o tym sądzisz? Zbyt piękne, żeby było prawdziwe? Utopia?
P.S. Jeśli interesujesz się tą dziedziną, sprawdź najnowszy podcast Lexa Fridmana z Andrei Karpathy, byłym dyrektorem AI w Tesli, o Software 2.0 i generowaniu kodu.
