Az AI-val kódolni olyan, mint GPS-szel vezetni: kényelmes, gyors, és közben észrevétlenül kopik a belső térképed. Több fejlesztő most azt mondja, hogy a mindennapi AI-használat mellett egyszerűen „kimegy a kézből” a kódolás.

Mi történt

A cégek egyre látványosabban tolják az automatizálást a mindennapi munkába, és ez a szoftverfejlesztésben különösen gyorsan csapódik le. Van, ahol már a használatot is mérik: például belső ranglistákon követik, ki égeti a legtöbb AI „tokent” (a token nagyjából a modell által feldolgozott szöveg egysége; minél több token, annál több kérdés-válasz és annál nagyobb költség/használat).

A fejlesztők egy része viszont arról számol be, hogy a munka jellege eltolódott: nem ők írják meg a megoldást, hanem AI által generált kódot ellenőriznek és javítgatnak. Ez elsőre hatékonyságnak tűnik, de a visszajelzések szerint pont az a „rote” (ismétlődő, gyakorló jellegű) rész tűnik el, ami élesen tartja a technikai készségeket: amikor te rakod össze a logikát, te hibázol, te debugolsz, és közben mélyül a megértés.

Konkrét példaként egy mérnök azt mesélte, hogy megijedt, amikor hirtelen nem jutott eszébe, hogyan kell összerakni egy Laravel API-t. (A Laravel egy népszerű PHP-s webes keretrendszer; az API pedig olyan „kapu”, amin keresztül rendszerek adatot és funkciókat kérnek egymástól.) Mások arról beszéltek, hogy bár nem kötelező náluk az AI, mégis „beszivárog” a munkába: például Cursor jellegű eszközökkel (AI-val megtámogatott kódszerkesztő) gyorsabbnak érződik a haladás, és könnyű rászokni.

Miért fontos

A kockázat nem az, hogy az AI segít — hanem hogy a segítségből helyettesítés lesz. Gondolj rá úgy, mint a számológépre: ha mindig ott van, egy idő után a fejben számolás képessége romlik, és amikor tényleg érteni kell a lépéseket, hirtelen nincs mihez nyúlni. A fejlesztésben ez különösen fájhat a nagyobb rendszerek „megtervezésénél” (architektúra): ott nem egy függvény a kérdés, hanem a kompromisszumok, a skálázhatóság, a hibakezelés és a hosszú távú karbantarthatóság. Ha a csapatok főleg kódrészleteket review-znak, de ritkábban gyakorolják a mély problémabontást, az később minőségi és biztonsági hibákban, lassabb döntésekben és drágább újraírásokban üthet vissza.

Mire figyelj

  1. Mérik-e a „tokenégetést”, és ez teljesítménymutatóvá válik-e? Ha a mennyiségi AI-használat KPI lesz, könnyen a gyors, felületes megoldások felé tolja a csapatot.
  2. Mi számít „kész” munkának: működik vagy érthető is? Érdemes figyelni, hogy a review-kultúra megköveteli-e a magyarázhatóságot (miért így), nem csak a futó teszteket.
  3. Van-e tudatos „AI-higiénia”? Például időszakos AI-mentes feladatok, páros programozás, vagy olyan feladatkiosztás, ahol a juniorok is megtanulják a kézi megoldást, nem csak a promptolást.
  4. Az architektúra-döntések kinek a fejében vannak? Ha a rendszertervezés is „kérdezzük meg a modellt” üzemmódba csúszik, a csapat kollektív megértése elvékonyodhat.

A Futurism AI által idézett fejlesztői élmények lényege nem az, hogy az AI rossz, hanem hogy a kényelmet ugyanúgy menedzselni kell, mint bármely erős eszközt: különben nem csak kódot, hanem gondolkodást is kiszervezel.