Amikor az AI kódoló segéded nem tud dönteni

Használsz mostanában AI coding assistantet? Biztos találkoztál már vele: felteszel egy egyszerű kérdést, az AI magabiztosan nekiesik a problémának, aztán hirtelen meggondolja magát. Visszavonul, újragondolja, aztán megint változtat. Ismét, meg újra.

Ez nem hiba az AI agyában (általában). Inkább olyan, mintha valaki hangosan gondolkodna szerkesztő nélkül. Szórakoztató nézni, de mutatja, merre tartanak a fejlesztői eszközök az AI-korszakban.

Az "Bizonytalan Copilot" jelenség

Fejlesztők mesélték el nemrég, mi történt Claude Opus modelljével a GitHub Copilotban. Egy GoAWK-projektben (AWK-interpreter Go-ban) trükkös hiba akadt: a program "0\n0\n"-t nyomtatott ki, pedig "x 1\n"-nek kellett lennie egy adott AWK szkriptnél.

Az AI diagnózisa villámgyors és pontos volt – pár bekezdés alatt megtalálta a gyökeret. A baj? Speciális változók, mint a NR, natív Go integerként tárolódtak, elveszítve a string formájukat.

De aztán jött a "javítás" rész. Több perc alatt hét különböző megoldást dobott fel az AI. Izgalmas rész: legalább 25-ször meggondolta magát, újraértékelve a problémát minden alkalommal.

A hét megoldás, ami huszonöt lett

Íme, min cikázott az AI:

• A opció: Tartsuk meg a string reprezentációt a speciális változókban
• B opció: Value type-ként tároljuk őket
• C opció: String felülírásokat mentsünk, ha stringet rendelünk hozzájuk
• D opció: Csak a ForIn opcode-ot javítsuk
• E opció: Eredeti értékeket mellékmezőbe tegyük
• F opció: Csak lineNum és fileLineNum legyen value type
• G opció: Külön overrides map value type-okhoz

Lenyűgöző volt a belső monológja: "Igazából a legegyszerűbb..." "Várjunk, de a lényeg..." "Nem, az első ötlet volt jó..."

Mi okozza ezt a bizonytalanságot?

Miért van ez így? Az AI modellek, mint a Claude, arra vannak trenírozva, hogy minden szögből nézzék a dolgot. Felismerik, ha több jó megoldás lehetséges – itt tényleg több működött volna.

A gond, ha nincs egyértelmű értékelési kritérium (pl. "kevés refactor", "kompatibilitás megőrzése"), akkor az AI végtelenül pörög a lehetőségeken. Nem ostoba, csak túlbuzgó – és ez kontraproduktív.

Mi lett a vége?

A tanulság: a sok cikázás ellenére az AI leggyakrabban (26-ból 11-szer) a B opciót tartotta a legjobbnak. A fejlesztő ezt valósította meg – value type-ok integer helyett –, és bevált.

Így mutatkozik meg az AI ereje a kódingban. Bizonytalan volt, de:

• Gyorsabban diagnosztizált, mint manuálisan
• Megtalálta a legjobbat (huszonöt próbálkozás után)
• Áttekintette az edge case-eket és alternatívákat
• Kódjavaslatokat adott

Mit várj az AI coding tooloktól?

Claude, ChatGPT vagy más segédnél számolj ezzel:

Kiváló a diagnózisban, de döntésben gyengébb. Ha ismételgeti a "de valójában...", akkor a design teret pásztázza – ez értékes, több nézőpontot kapsz.

Adj pontos kereteket. Ne kérdezz simán "hogy javítsam?", hanem "hogy javítsam minimális refactorral?" vagy "mi a legkisebb változtatás?" Ez irányít.

Gondolkodó partnerként használd, ne jósnak. Értékeld az érvelését, ne másold az elsőt. A bizonytalanság jele, hogy foglalkozz a javaslatokkal.

A jövő: Vibe-alapú fejlesztés

Ez az eset elgondolkodtató az AI-fejlesztés jövőjéről. A NameOcean Vibe Hosting platformján azon dolgozunk, hogyan illesszük be jobban az AI-t a workflow-ba. Nem az AI döntsön mindent – az fedezze fel a terepet, te válassz okosan.

Olyan rendszerek kellenek, amik rangsorolnak: "B opció a legjobb, mert passzol a codebase architektúrájához." Nem csak cikáznak örökké.

Összefoglalva

Az a bizonytalan AI nem romlott el. Csak hangosan gondolkodott keret nélkül. Ha visszalépsz, látod: gyors diagnózis, több jó ötlet, legjobb megoldás azonosítása. A "bizonytalanság" csak átláthatóság a problémamegoldásban.

Az AI-fejlesztés jövője nem a tökéletes döntéshozó AI. Hanem az, ami mélyen kutat, érthetően magyaráz, és rád bízza a végső szót.

Legközelebb, ha a segéded hezitál, állj meg: pont azt csinálja, amiért hívtad – minden szögből megvizsgálja a gondot.