AI kódolás: amikor az eszközök túl okosak lesznek

A csendes pillanat a standup után

Emlékszel még, amikor az AI kódoló eszközökről volt szó? Gyorsabb PR-ek, kevesebb review, rövidebb release ciklusok. A CTO is lelkes volt, bevezettétek a Cursort vagy a Claude Code-ot, és pár hétig tényleg működött. A csapat tempója nőtt, a hangulat is jobb lett.

Aztán valaki kimondta: „Na de ez most ennyi?”

Nem a tool a hibás, és a csapat sem lustult el. Egyszerűen elérkeztetek ahhoz a ponthoz, amit sokan AI coding plateau-nak hívnak. Innen már nem elég csak használni az eszközt – át kell gondolni, hogyan használjátok.

Mi látszik ebből a plafonból?

A legtöbben úgy kezelik ezeket az eszközöket, mint egy okos autocomplete-et. Chat, néha generált kód, utána manuális ellenőrzés. Ez hoz is 27% körüli sebességnövekedést. Viszont azok a csapatok, akik már agentic coding felé mozdultak el, inkább 38% körül mozognak. A különbség nem tűnik soknak, mégis ez választja el a „hasznos segédeszközt” a valódi szervezeti változástól.

A 27%-os plafon nem technológiai korlát. Hanem szervezeti.

Mi tart vissza?

Három terület szokott megakadni:

• Gyakorlati érettség. Van-e közös kép a csapatban arról, mikor bízhatunk meg a generált kódban, és mikor kell jobban utánajárni? Aki ezt nem tisztázza, az hamar visszaesik a régi tempóra.
• Kódstruktúra. A kusza, rosszul tagolt kódbázisokba az AI agentek is nehezen látnak bele. A tiszta interfészek, jó tesztek és moduláris felépítés viszont lehetővé teszik, hogy az agent tényleg önállóan dolgozzon.
• Szervezeti háttér. Ki dönt a merge-ről? Ki gyűjti az AI hibáiból származó tanulságokat? Aki ezt nem szervezi meg, az egyéni trükknek tekinti az egészet – és soha nem lép túl a 27%-on.

Hogyan tovább?

Három lépés visz előre:

1. Közös elvárások. Írjátok le, mit jelent nálatok a jó AI használat. Mikor kell review-zni, mikor lehet elfogadni? Ez nem bürokrácia, hanem viszonyítási pont.
2. Kódminőség mint alap. Erős típusosság, jó tesztek, világos határok – ezek nélkül az AI agent semmire sem megy. Ezek már nem „szép dolog”, hanem az automatizálás feltétele.
3. Valódi visszacsatolás. Ha az agent hibázik, az adat. Rögzítsétek, hogy mit akart csinálni, hol tévedett, és mit lehetne másképp csinálni legközelebb.

Hol álltok most?

Két tengelyen érdemes elhelyezni magatokat:

• Milyen a kód minősége és modularitása?
• Mennyire szervezett a használat (szabványok, visszacsatolás, tudásmegosztás)?

Ebből négy helyzet jön ki:

• Mindkettő erős → lehet bővíteni az agent szerepét.
• Jó kód, gyenge szervezet → először a közös szabályokat és visszacsatolást kell kiépíteni.
• Gyenge kód, erős szervezet → a refaktorálás a következő lépés.
• Mindkettő gyenge → kezdjetek egy kisebb projekttel, és onnan építkezzetek.

Mit mondjatok a CTO-nak?

„Most 27%-os javulást látunk. De van még 11 pont a láthatáron – ha beépítjük a közös szabályokat, a jobb kódminőséget és a visszacsatolási rendszert. Itt tartunk, és ezt kellene még megcsinálni.”

Aztán húzzátok fel a négyzetet, és jelöljétek be, hol vagytok. Így már nem elmélet a beszélgetés.

Egy utolsó megjegyzés

A legjobb gyakorlati tapasztalatok azoktól jönnek, akik már végigmentek ezen. A modellek változnak, de a szervezeti problémák ugyanazok maradnak. És pont ezek oldhatók meg anélkül, hogy új eszközt kellene venni.

A következő 11 pont már látszik. A kérdés csak az, hogy elindultok-e feléjük – vagy megálltok a 27%-nál.