AI może błyskawicznie przygotować kod, który później ktoś będzie godzinami sprawdzał. Bidhan Baruah, dyrektor operacyjny firmy tworzącej oprogramowanie dla przedsiębiorstw, opisuje wdrożenie agentów w całym cyklu rozwoju aplikacji. Największe korzyści znalazł w rutynowych zadaniach. Najpoważniejsze problemy pojawiły się tam, gdzie szybkość zaczęła zastępować zrozumienie.
- Według relacji Bidhana Baruaha AI pomagała przede wszystkim w tworzeniu testów, dokumentacji i powtarzalnych fragmentów kodu
- Czas zaoszczędzony na generowaniu rozwiązania bywał tracony podczas jego późniejszej weryfikacji
- Zespół przyjął zasadę, że programista musi rozumieć i uzasadnić logikę kodu zaproponowanego przez model
- Ocena wdrożenia powinna obejmować jakość gotowej aplikacji i koszt utrzymania, a nie samą liczbę wygenerowanych zmian
Baruah opisuje presję, z którą mierzą się liderzy technologiczni: mają pokazać, że ich organizacje stawiają AI w centrum rozwoju. Postanowił skonfrontować ją z codzienną pracą nad aplikacjami dla klientów biznesowych.
Zapisz się na newsletter BGR. Otrzymuj najlepsze informacje i porady, a także zaproszenia na eventy.
Klikając „Zapisz mnie”, potwierdzasz, że przeczytałeś i zgadzasz się z naszą Polityką prywatności.
Zapisz się na newsletter BGR. Otrzymuj najlepsze informacje i porady, a także zaproszenia na eventy.
Klikając „Zapisz mnie”, potwierdzasz, że przeczytałeś i zgadzasz się z naszą Polityką prywatności.
Wdrożenie objęło cały cykl tworzenia oprogramowania, od przygotowania rozwiązania po jego sprawdzanie i utrzymanie. Baruah wyróżnia trzy obszary: automatyzowanie powtarzalnych czynności, dodatkową weryfikację logiki oraz wyszukiwanie wiedzy. W ostatnim przypadku korzyść wynika z ograniczenia czasu, który programista poświęca na przerywanie pracy i przeglądanie dokumentacji.
Najbardziej naturalnym początkiem okazały się zadania o przewidywalnej strukturze. AI pomaga tworzyć szkielety interfejsów, przykładowe dane i testy jednostkowe, które sprawdzają działanie niewielkich fragmentów programu.
W organizacji Baruaha korzystanie z niej przy testach i dokumentacji stało się obowiązkowe. Dzięki temu doświadczeni inżynierowie mieli więcej uwagi na projektowanie systemów i ich wydajność.
Czytaj też: Cicha automatyzacja. Jak małe firmy używają AI tam, gdzie klient jej nie widzi
Szybkie pisanie kodu może wydłużyć jego sprawdzanie
Problemy zaczęły się po pierwszym zachwycie nad tempem generowania. Narzędzie potrafi wyprodukować dużo kodu, ale objętość nie mówi, czy rozwiązano właściwy problem. Błędne założenie biznesowe pozostaje błędne nawet wtedy, gdy model bardzo sprawnie zamieni je w działającą funkcję. W efekcie zespół może wyglądać na niezwykle zajęty, choć produkt niewiele zyskuje.
Baruah wyraźnie oddziela przygotowywanie fragmentów programu od projektowania architektury całego systemu. Ta druga praca wymaga rozumienia zależności, przyszłych zmian i konsekwencji utrzymania. Przyspieszenie pojedynczego programisty może więc współistnieć z narastaniem długu technicznego, czyli kosztu uproszczeń i zaniedbań, które trzeba będzie naprawić później.
W projektach, nad którymi pracowała firma Baruaha, oszczędność na napisaniu kodu niejednokrotnie znikała podczas przeglądu. Działo się tak, gdy inżynier przyjmował wynik bez zachowania kontroli nad jego logiką.
Zespół wprowadził prostą zasadę: autor zmiany musi potrafić wyjaśnić, dlaczego rozwiązanie działa. Jeśli nie rozumie propozycji AI, nie może skierować jej do wdrożenia.
To zabezpieczenie nie sprowadza się do sprawdzenia składni. Program może uruchamiać się poprawnie, a mimo to nie obsługiwać nietypowych danych, naruszać założenia innego modułu albo utrudniać przyszłą rozbudowę. Test przygotowany przez AI także wymaga oceny i może jedynie potwierdzać zachowanie wygenerowanego kodu, zamiast sprawdzać rzeczywiste wymagania klienta.
Efekt wdrożenia trzeba mierzyć na gotowym produkcie
Kolejną zmianą było odejście od ogólnych poleceń na rzecz wewnętrznej wiedzy o projektach. Agenci otrzymywali kontekst związany z logiką biznesową aplikacji. Model powinien rozumieć, do czego służy dana funkcja i jakie ograniczenia obowiązują w systemie. Samo polecenie, aby napisał kod szybko lub zgodnie z dobrymi praktykami, nie dostarcza tych informacji.
Z punktu widzenia zarządu oznacza to konieczność oceny całego przepływu pracy. Warto porównywać czas od zgłoszenia potrzeby do bezpiecznego wdrożenia, nakład na poprawki oraz błędy wykrywane już przez klientów. Liczba zmian wysłanych do repozytorium może wzrosnąć, mimo że odbiorca aplikacji nie otrzyma jej ani wcześniej, ani w lepszej jakości.
Baruah nie podaje pełnych pomiarów pozwalających wyliczyć zwrot z inwestycji. Jego relacja wskazuje, gdzie pojawiały się korzyści i dodatkowa praca, ale nie uzasadnia obietnicy określonego procentu oszczędności w każdej firmie.
W polskim software house taki rachunek powinien uwzględniać również model rozliczeń z klientem. Przy stałej cenie projektu mniej poprawek może poprawić marżę, a przy rozliczeniu godzinowym potrzebne może być inne pokazanie wartości usługi. W obu przypadkach warto mierzyć koszt całego zlecenia, wraz z przeglądami kodu i późniejszym utrzymaniem aplikacji.
Baruah proponuje zaczynać od rutyny i zachować odpowiedzialność inżynierów za rezultat. Jeśli AI tylko przyspiesza produkowanie materiału do sprawdzenia, może przesunąć przeciążenie do następnego etapu projektu.
Czytaj też: AI potrafi świetnie programować. Szef Replit: teraz ważniejsze jest wiedzieć, co warto zbudować
