Az AI nem tett 5x gyorsabbá. Csak arrébb tolta a szűk keresztmetszetet.

Manapság két fajta fejlesztő létezik: aki már vibe-codeolt valamit, és aki hamarosan fog. Az első alkalom olyan, mint valami bűvésztrükk. Beírsz egy promptot, vársz egy percet, és bumm! - ott áll egy működő alkalmazás, meglepően jó UI-val.

Pontosan ez az a rész, amit minden konferencia-demó megmutat, és ezért teszi fel ugyanazt a kérdést minden PM, CEO és befektető: ha az AI ilyen gyorsan épít szoftvert, akkor a csapatunk miért nem szállít ötször gyorsabban? A fejlesztők ennek a kérdésnek egy pár fokkal nehezebb verzióját teszik fel. Egy éve a „hogy néz ki valójában a generált kód" kérdésre igen egyszerű volt a válasz: inkább meg se nézd. Ma, a jelenlegi modellekkel, ellenben gyakran tényleg jó. Ez pedig egy még élesebb kérdést vet fel: ha a kód is rendben van, a csapat miért érzi úgy, hogy csak alig gyorsabbak?

A script, amiből service lett

Idézzünk fel egy automatizálást, amit szinte mindenki megírt már valamikor. Pár száz sor bash vagy Python, egyetlen problémára fókuszálva, talán még README is van hozzá, hogy hogyan kell konfigurálni. Erre senki nem nyitott ticketet, mert nem egy projekt - csak egy tool, ami valakinek valamikor megkönnyítette a hetét.

Megemlíted a standupon, és mindenki imádja. Aztán valaki felteszi a veszélyes kérdést: ebből nem lehetne egy valódi service? Na, innentől minden megváltozik. Mert akkor már kell hozzá repo, CI pipeline, deployment, authentication, monitoring, logging, egy rendes UI, belső domain, firewall szabályok, security review, dokumentáció és egy owner. Maga a script ettől nem lett bonyolultabb. Ellenben körülötte minden más az lett. Egy száz soros tool hirtelen szoftverré vált, a szoftver pedig drága - nem azért, mert a megírása nehéz, hanem mert minden, ami körülveszi, az.

Az agent ezt nem szünteti meg - örökli

A kézenfekvő ellenvetés, hogy ezt is megoldják az agentek: felhúzzák a repot, átmozgatják a scriptet, beállítják a buildet, megnyitják az első pull requestet. Rendben, tegyük fel, hogy tényleg így van. Most tegyél öt backlog itemet öt, egyszerre dolgozó agent elé. Függenek ezek a feature-ök egymástól? Szinte biztos. Ugyanazt a fájlt módosítja két agent? Valószínűleg. Mi történik, ha az egyik agent pár perc alatt végez, de várnia kell, mert egy másik PR még mindig review-ban ül, vagy mert valaki tegnap megváltoztatta az API-t, és a generált kód fele már egy olyan verziót céloz, ami nem is létezik többé?

Ezek közül egyik sem modellminőség-probléma. Ugyanaz a koordinációs probléma, amivel a csapatok mindig is küszködtek - csak most gyorsabban és nagyobb volumenben érkezik.

A szűk keresztmetszet egy CI runner volt

Ez bizony nem elmélet - egy korábbi projekten, ahol dolgoztam, pontosan ez történt. Egy agent pár perc alatt legenerált egy feature-t, aztán tétlenül várt - nem egy reviewerre, hanem arra, hogy felszabaduljon egy GitLab CI runner. Az AI gyorsabban gyártott működő kódot, mint ahogy azt a pipeline egyáltalán el tudta volna kezdeni validálni.

Persze ezt a részt egyetlen demó sem mutatja meg. Valakinek muszáj átnéznie a változtatást, mert a policy ezt írja elő. A linter elhasal, vagy a build bukik, vagy egy integration test kifog valamit, vagy a reviewer észreveszi, hogy a generált kód figyelmen kívül hagy egy architekturális határt, amit sosem írt le senki olyan formában, amit a modell olvasni tudott volna. Így újragenerálódik, és a kör - review, merge conflict, CI run, jóváhagyás - kezdődik elölről. A kód másodpercek alatt megérkezik.

Minden, ami körülötte van, továbbra is órákig tart, néha napokig.

Minden valódi áttörés ezt csinálta

A fordítóprogramok nem tették feleslegessé a szoftverfejlesztőket. A magas szintű keretrendszerek sem, és a felhőre költözés sem. Mindegyik megszüntetett egy költséget, ami addig a látható korlát volt, és mindig volt egy másik korlát, ami már ott várt alatta: architektúra, review-kapacitás, deployment folyamat, szervezeti jóváhagyási láncok. Az AI pontosan ugyanezt csinálja a kódgenerálással. Nem tette olcsóvá a szoftvert. A kód megírását tette olcsóvá, ami sosem volt ugyanaz az állítás, és a kettő közti rés pontosan az a hely, ahonnan a maradék 4x-nek jönnie kéne - csak nem jön.

Ez az 5x itt van velünk a szobában?

Azok a csapatok lesznek érdemben gyorsabbak, akik tényleg megkeresik, hogy hol van most az új korlát, ahelyett hogy azt feltételeznék: még mindig a generálási sebesség. Néha tényleg az infrastruktúra a gond - egy CI rendszer, amit egy olyan világra méreteztek, ahol a PR-ek egyesével érkeztek.

Néha a review: egy reviewer fájlonkénti negyvenöt(!) másodperce nem elég a kódra egy olyan szerzőtől, akinek nincs felismerhető stílusa, - így a review ideje pont akkor nő, amikor mindenki azt várta, hogy majd csökken.

Néha az ownership hiányzik - senki nem írta le, milyen architekturális határokat kell az agentnek betartania, így minden generálási kör ugyanazt a violationt fedezi fel újra.

Ezek egyikét sem oldja meg egy gyorsabb modell, mint a Composer vagy Grok. Azzal oldódnak majd meg, hogy a code review-t architekturális ellenőrzésnek tekinted, nem formalitásnak, hogy a pipeline-t arra a volumenre méretezed, amit az AI ténylegesen termel, és hogy leírod azokat a határokat, amiket a csapat betartatna, ahelyett hogy elvárnád a reviewertől, hogy fejből kapja el őket minden alkalommal.

Azok a csapatok, akik ezt csinálják, észreveszik, hogy hova mozdult a valódi bottleneck, és ott javítják ki. Mindenki más csak ötször gyorsabban fog kódot generálni, miközben pontosan ugyanabban a pull request sorban várnak.