Miért mondanak nemet az AI-kódolásra egyes fejlesztők?

Az IT-világ AI-lázban ég. Minden új eszköz "forradalmasítja" a kódolást, a konferenciákon termékenységről papolnak, a startupok meg LLM-mel hencegnek. Izgalmas, de nem mindenkinek kell.

Néhány tapasztalt fejlesztő visszalépett. Feltették a kérdést: Tényleg kell ez? Nézzük meg, miért maradnak a manuális kódolásnál, és mit tanulhatunk ebből a fejlesztői eszközökről.

A pénzügyek realitása

Kezdjük a konkrétummal: költségek.

A legtöbb AI-kódoló eszköz előfizetéses. Havonta vagy évente fizetsz, cserébe IDE-be épített segítséget kapsz. Logikusnak tűnik? Csakhogy állandó kiadás egy olyan eszközre, amit csak ritkán használsz.

Sokan ezért térnek vissza a sima szövegszerkesztőkhöz. Ha csak 10%-ban segít – mondjuk sablonoknál vagy dokumentációban –, megéri az ár? Ráadásul ingyenes vagy egyszeri vásárlású eszközök régóta megoldják ugyanezt.

A régi motorosok láttak már ilyet. No-code platformok ígérték, hogy eltörlik a programozást. Low-code megoldások jöttek, de technikai adósságot halmoztak. Minden "forradalom" hozott némi gyorsulást, de sosem annyit, mint ígérték.

Nem az AI hasznosságát kérdőjelezik meg. Inkább azt látják: ha egy eszköz komplexitást ígér megoldani, lehet, rossz problémát céloz.

Kétféle bonyolultság

Itt lesz izgalmas a sztori.

Fred Brooks, az IBM-legenda "No Silver Bullet" esszéjében elmagyarázza: nem minden komplexitás egyforma.

Van a véletlen komplexitás: a kódolás felesleges súrlódása. Memóriakezelés, sablonok, API-keresés. Ezek uncsik, de nem agytrösztők.

Aztán az alapvető komplexitás: a probléma valódi nehézsége. Üzleti igények megértése, architektúra, elosztott rendszerek, hibakeresés. Ezek megmaradnak Assembly-ben vagy Pythonban egyaránt.

A mai nyelvek és keretrendszerek már legyőzték a véletlen fajtát. Nem gépi kódot verünk, std lib-eket használunk, package managerek, linterek, tesztek intézik a rutint.

A kemény igazság: az AI-kódolók főleg véletlen komplexitást oldanak meg, amit rég kipipáltunk.

Ha LLM-mel kérsz REST endpointot vagy unit tesztet, ismert, dokumentált dolgot oldasz meg. A mai szoftverfejlesztés gátja nem a gépelés vagy szintaxis, hanem hogy mit építs, és hogyan.

Az absztrakciós torony csapdája

Gondolj a fejlesztői stackre. Egy Python-sor mögött millió művelet fut: bytecode, interpreter, OS, CPU, szilícium.

Az AI-álom újabb réteget tesz rá: autonóm ügynökök kódolnak helyetted.

De minden új réteg új hibalehetőségeket szül. Ha mélyen elromlik valami, le kell menned alacsonyabb szintre. A legjobb debugghoz érteni kell alatta mi történik.

AI-generált kód? Új réteg a szándékod és a végrehajtás között. Ha baj van – és lesz –, vissza kell fejtened, mit csinált az AI. Ez nem gyorsítás, hanem rejtett karbantartási teher.

Tapasztalat mint ellenszer

Van itt generációs szál is.

Az ipar ifjúságot és gyorsaságot ünnepli, ötéves tapasztalat "senior". De a harmincas veteránok tudása túlmutat a kódon. Látták a bukásokat, ismerik a kockázatokat, emlékeznek a múlt "forradalmainak" kudarcára.

Nem a fiatalokat vagy az AI-t támadják. Értékelik a ciklusokon átesett szemléletet: Java, Ruby, Node, blockchain, serverless. Ez nem anti-fejlődés, hanem anti-ködlovagolás.

Mit jelent ez a NameOcean-usereknek?

A NameOceannél hiszünk az AI jövőjében – épp ezért vagyunk őszinték a határairól.

Vibe Hostingunkban AI-t használunk, ahol igazán számít: infrastruktúra, deployment, skálázás. Itt mérhető nyereség van, mert jól körülhatárolt problémák.

Nem cseréljük le a fejlesztőt. Eltávolítjuk a felesleges súrlódást: infra, deployment, monitoring.

Ha szkeptikus vagy az AI-kódolókkal, az jó jel. Gondolkodsz, hol ad értéket, hol bonyolít. Használd ott, ahol rutint spórol, kerüld, ahol közel kell a problémához.

A fejlesztés jövője nem a programozók kiiktatása. Hanem a zavaró tényezők eltávolítása onnan, ahol csak ember jó.