AI je ubrzao pisanje koda. Zašto razvoj softvera nije brži?

Ubrzanje pisanja koda uz pomoć AI alata slavimo kao povećanje produktivnosti, no Olena Babenko, Staff softverska inženjerka u Aivenu, tvrdi da mjerimo krivu stvar. Pisanje koda nikad nije bio problem u razvoju softvera, no pregledavanje istog tog koda je, a upravo taj dio AI nije ubrzao.

Paradoks

U zadnje vrijeme sve češće viđamo isti obrazac, tvrdi Olena s kojom smo razgovarali na marginama konferencije Devoxx. Spominje američke i kineske AI gigante koji svako malo najavljuju “najmoćnije” nove AI modele te obećavaju brda i doline. I onda kad napokon otvorimo taj famozni novi model i damo mu jednostavan, ali domenski specifičan zadatak, rezultat često budu halucinacije i netočna rješenja.

No najveći problem koji Olena vidi je to da danas developeri uz pomoć AI-ja mogu proizvesti ogromne količine koda u vrlo kratkom vremenu, ali pregled tog koda ne prati taj tempo te je ostao na razini prije “AI revolucije”.

Danas možemo generirati tisuće linija koda nevjerojatno brzo, ali pritom često ne razmišljamo kako će drugi ljudi taj kod doživjeti koliko je čitljiv, kvalitetan i jednostavan za razumjeti. S druge strane, alati i procesi za pregledavanje koda, njegovo skaliranje i automatizaciju još uvijek nisu pratili taj tempo

Zbog toga se sve češće događa paradoks, tvrdi naša sugovornica:

Može se dogoditi da pull request napišete za vrlo kratko vrijeme, a osoba koja ga pregledava potroši znatno više vremena na njegovu provjeru nego što je vama trebalo da ga napravite.

Nevidljiv posao

Prema Oleni, razlog toga nije samo tehnologija nego način na koji su organizirani razvojni timovi. Većina tvrtki i dalje nagrađuje količinu isporučenog koda, broj zatvorenih Jira zadataka ili broj otvorenih pull requestova. Pregledavanje tuđeg koda, iako jednako važno za kvalitetu proizvoda, često ostaje gotovo nevidljiv posao.

Današnji sustavi i mnogi menadžerski alati temelje se na KPI-jevima koji nagrađuju individualni doprinos kroz pisanje koda. Ako pogledate GitHub doprinose ili Jira tickete, vrednuje se pisanje koda, zatvaranje zadataka i otvaranje pull requestova, dok se posao ljudi koji pregledavaju taj kod puno manje cijeni.

Kad se tome pridoda činjenica da AI često generira opširniji kod nego što je potrebno, posao osobe koja pregledava taj kod postaje još zahtjevniji.

Osnivač Instagrama pojasnio nam na AI Engineer konfi što je sad posao developera

AI povećava problem

Olena naglašava da preopterećenost ljudi koji pregledavaju kod, odnosno reviewera nije nova pojava. Prisjeća se primjera iz prethodne tvrtke gdje bi developeri dva tjedna radili na jednom zadatku, a zatim kolegi poslali pull request od tisuću linija koda koji bi ovaj trebao pregledati i odobriti. AI, kaže, samo dodatno povećava taj jaz.

Rješenje vidi u manjim pull requestovima, ranijoj komunikaciji unutar tima i odvajanju refaktoriranja od stvarnih funkcionalnih promjena:

To je prije svega problem načina na koji se upravlja timovima. Odgovornost je na menadžerima.

Još jedan problem koji Olena vidi je pisanje unit testova. Kako su testovi mnogima dosadan dio posla, sve ih češće prepuštaju AI-ju.

No modeli, upozorava, mogu proizvesti testove koji izgledaju uvjerljivo, a zapravo ne provjeravaju ispravnost sustava. Umjesto stvarnog testiranja ponašanja aplikacije, modeli ponekad prilagode implementaciju ili unaprijed definiraju očekivane rezultate samo kako bi testovi prošli, a posljedice tog pristupa se ne vide odmah:

Sustav se neće raspasti preko noći. To je postupan proces koji ga malo po malo nagriza, sve dok jednog dana ne shvatite da je postao nepouzdan i da ga zapravo ne biste trebali koristiti u produkciji.

Takav kod može imati visoku pokrivenost testovima, ali istovremeno biti sve manje pouzdan za produkcijsko okruženje.

Preduvjet da čovjek ostane u petlji

Najveći dugoročni rizik Olena ipak vidi u ljudima. Kako svi mi, uključujući developere, sve više delegiramo razmišljanje AI-ju, postoji opasnost da s vremenom izgube upravo one vještine koje bi trebale biti posljednja linija obrane kada model pogriješi.

Olena podsjeća kako modeli ne stječu iskustvo, ne uče iz projekata i nemaju dugoročno pamćenje kao ljudi.

Ako developeri postupno prestanu razvijati vlastito kritičko razmišljanje, ideja da će “čovjek uvijek biti u petlji” gubi smisao. Sigurnosna mreža vrijedi samo ako osoba koja je drži još uvijek zna prepoznati kada nešto nije u redu, zaključuje.