Dwa lata temu, gdybyś powiedział większości liderów inżynierii, że AI będzie pisać funkcje produkcyjne, refaktoryzować przestarzałe moduły i wyłapywać błędy, zanim człowiek w ogóle na nie spojrzy, nazwaliby to cudem produktywności w drodze. I w wąskim sensie tak właśnie było. Asystenci kodowania AI są naprawdę świetni w szybkim pisaniu kodu.
Oto więc pytanie, nad którym warto się zatrzymać: jeśli najwolniejsza część tworzenia oprogramowania stała się radykalnie szybsza, dlaczego nie wygląda na to, że zespoły dostarczają dwa razy szybciej?
Bo pisanie kodu nigdy nie było wąskim gardłem. Wąskim gardłem była koordynacja wszystkiego wokół niego.
Część, której nikt nie zautomatyzował
Pomyśl, co dzieje się naprawdę między „mamy pomysł" a „działa na produkcji". Ktoś określa zakres prac. Programista to pisze. Zmiana czeka w kolejce na review. Czeka w kolejnej kolejce na QA. Ktoś musi napisać dokumentację, zwykle po fakcie i w pośpiechu. Ktoś konfiguruje pipeline wdrożeniowy. Ktoś obserwuje rollout. Każdy z tych kroków wiąże się z przekazaniem pracy, a każde przekazanie oznacza utratę kontekstu, renegocjowanie priorytetów i to, że zgłoszenie, które wymagało czterech godzin faktycznego kodowania, spędza cztery dni w oczekiwaniu między ludźmi.
Asystenci kodowania AI przyspieszyli najszybszą stację na tej linii montażowej. Wszystkie pozostałe stacje (i kolejki między nimi) zostawili tak samo wolne i ręczne jak wcześniej. Dlatego „nasi programiści kodują teraz szybciej" tak często nie przekłada się na „wydajemy teraz szybciej". Przyspieszenie jednego kroku w łańcuchu przekazań oznacza tylko, że praca dłużej czeka na następnym.
Przemyślenie, co powinno oznaczać „AI w tworzeniu oprogramowania"
To problem, który AITM miał rozwiązać, i dlatego nie zbudowaliśmy kolejnego narzędzia do autouzupełniania.
AITM to platforma AI do inżynierii oprogramowania, która zarządza pełnym cyklem życia oprogramowania: planowaniem, kodowaniem full-stack, automatycznym code review, testami end-to-end, dokumentacją, CI/CD i wdrożeniem w chmurze, wszystko z jednego żądania. Pomysł jest prosty do opisania i naprawdę trudny do zbudowania: zgłoś zadanie raz, a AITM zaprojektuje, zakoduje, przetestuje, udokumentuje i dostarczy oprogramowanie gotowe na produkcję, bez konieczności ręcznego prowadzenia go przez sześć osobnych narzędzi i cztery osobne zespoły.
To inny rodzaj automatyzacji niż „pomóż mi szybciej napisać tę funkcję". To automatyzacja samych przekazań, tej części cyklu życia, którą narzędzia do zwiększania produktywności inżynierów w większości ignorowały, bo jest trudniejsza do zautomatyzowania niż autouzupełnianie i mniej efektowna w demo.
Co się zmienia, gdy własnością jest cały pipeline, a nie tylko jeden krok
Gdy code review, testowanie, dokumentacja i wdrożenie nie są osobnymi ręcznymi kolejkami, lecz częścią jednego, stale zarządzanego procesu, pojawia się kilka naturalnych konsekwencji. Kod przychodzi już przetestowany i udokumentowany, zamiast przychodzić jako surowy diff, który potem czeka, aż ktoś zajmie się resztą. Decyzje architektoniczne zapadają z myślą o bezpieczeństwie i skalowalności od samego początku, a nie są doklejane po incydencie ze skalowaniem. A cykl wydawniczy się skraca, nie dlatego, że ktoś pisał szybciej, ale dlatego, że oprogramowanie spędzało znacznie mniej czasu w kolejce.
Dla inżynierów ta zmiana znaczy więcej, niż mogłoby się na początku wydawać. Oznacza mniej czasu na narzut koordynacyjny związany z przeprowadzeniem zmiany przez review, QA, dokumentację i wypuszczenie jej w świat, a więcej czasu na pracę, która naprawdę wymaga ludzkiego osądu: co budować, jak to zaprojektować, jakie kompromisy mają znaczenie dla tego produktu i tych użytkowników. AI nie powinno próbować zastąpić tego osądu. Powinno usuwać wszystko, co przeszkadza w jego stosowaniu.
Prawdziwe pytanie konkurencyjne
Przez lata branża oprogramowania mierzyła produktywność tym, jak szybko pojedynczy inżynier potrafi napisać linijkę kodu. To był rozsądny zastępnik, kiedy pisanie kodu było kosztowną częścią. Już nie jest. Zespoły, które wysuną się naprzód, to nie te, których inżynierowie piszą najszybciej, lecz te, które skróciły dystans między „mamy pomysł" a „działa, jest przetestowane, udokumentowane i bezpiecznie chodzi na produkcji".
Na to stawia AITM i właśnie o takiej zmianie, naszym zdaniem, będą naprawdę dotyczyć najbliższe lata AI w tworzeniu oprogramowania - nie o mądrzejszym autouzupełnianiu, ale o AI, które odpowiada za rezultaty w całym cyklu życia, od początku do końca.
Jeśli to problem, z którym zmaga się także Twój zespół, chętnie usłyszymy, jak o tym myślisz.