Amikor a kód本身 rossz irányba ment

Történt egyszer, hogy három órán keresztül debugoltam egy "egyszerű" funkciót, amit az egyik AI ügynököm írt. Az ügynök magabiztosan commitolt, pusholt productionbe, sőt, még egy vidám üzenetet is hagyott a task teljesítéséről. Egy aprócska probléma volt csupán: a kód teljesen hibás volt. Nem bugos—fogalmi szinten nem értette, mit akartunk építeni.

Az a pillanat átírta a mentális modellemet.

Eddig úgy gondoltam ezekre az ügynökökre, mint segítőkész junior fejlesztőkre, akiknek csak iránymutatás kell. De junior fejlesztők nem deployolnak teszteletlen kódot productionbe, miközben alszol.

Szóval teljesen új metaforát választottam.

Az Alvállalkozói Keretrendszer

Ahelyett, hogy alkalmazottként vagy asszisztensként kezeltem volna az AI ügynököket, mostantól alvállalkozókként kezelem őket. Mit jelent ez a gyakorlatban?

Egy alvállalkozónak nincs kulcsa az irodádhoz. Nem jelenik meg meghívás nélkül. Elvégzi a ráosztott munkát, majd benyújtja a számlát—amelyet átnézel, mielőtt kifizetnéd. Ha a munka nem megfelelő, visszaküldöd.

Ez nem bizalmatlanságról szól. A motivációk és az elszámoltathatóság összehangolásáról van szó. Amikor egy alvállalkozó pontosan érti, hogy a szerepe egy kész artifact leszállítása a te áttekintésedre—nem pedig egyoldalú döntések meghozatala—akkor jobban teljesít. Fókuszált. Produktív a határain belül.

A Technikai Réteg

Ehhez a mentális modellhez technikai fogak kellenek. A projektjeimnél ez így néz ki:

Token határok—ez minden

Az ügynökeim scoped credentialökkel dolgoznak, amelyek fizikailag képtelenek megérinteni a productiont. Olvasási hozzáférésük van a fő codebasehez, de írási joguk csak egy külön staging repóhoz. Ez nem házirend—kriptográfiai kényszer. Még ha az ügynök rogue módba kapcsolna, vagy hallucinált git parancsokat generálna, nem tudja módosítani a production kódot. A tokenek ezt egyszerűen nem engedik.

A staging repó egy postaláda

Semmi sem merge-el automatikusan a stagingből. A staging repó default branchje szó szerint egy sírkő—egy "no-main" nevű branch, ami csak egy README-t tartalmaz, azt üzenve: "használd az eredeti repo main branchét."

Az ügynökök ide pusholják a kész munkát. Üzennek, amikor a branch kész. Aztán én átnézem, cherry-pickelek, ami működik, és kézzel integrálom. Fárasztónak tűnik mindaddig, amíg rájössz: a Linux kernel pontosan így működik húsz éve. Contributors submitolják a patcheiket. Maintainerek alkalmazzák őket.

A review nem opcionális

Egyetlen ügynök sem mergeelheti a saját kódját. Pont. A branch nem törlődik, amíg programozottan, függetlenül nem ellenőrzöm, hogy a commitjai biztonságban vannak-e a productionben. A "trust but verify" nem elég, amikor a verifikáció ingyenes.

Miért működik ez egyedül dolgozó fejlesztőknek?

Itt van a lényeg: amikor egyedül vagy kis csapatban dolgozol, nem csak szoftvert építesz. Kontextust tartasz fenn, ami sehol sem létezik a kódbázisban. Aincidenseid története. Az edge case-eid. A vásárló, akinek furcsa konfigurációja van. A három dolog, amit kipróbáltál, és nem működött.

Az ügynököknek nulla hozzáférésük van ehhez a kontextushoz. Olvasnak fájlokat, de nem értik a világodat. Szóval a cél nem az, hogy nagyobb autonómiát adj nekik—hanem az, hogy maximalizáld, mennyi munkát tudnak biztonságosan elvégezni a te review sávszélességed keretein belül.

Itt kapja a rossz nevet a "vibe coding." Rosszul csinálva a vibe coding azt jelenti, hogy hagyod az ügynököket bármit csinálni, és reméled, hogy működik. Jól csinálva azt jelenti, hogy AI-t használsz az ítélőképességed felszorzására—nem az ítélőképességed helyettesítésére.

A Gyakorlati Előny

Amikor elfogadod az alvállalkozói kapcsolatot, valami váratlan történik: több kockázatot vállalsz. Szívesen nekiveselkedsz annak az experimentális funkciónak, mert a hátrány korlátozott. Az ügynök nem tudja tönkretenni a productiont. Lehetséges, hogy meglepően rosszat vagy meglepően jót szállít—de bármelyik esetben elkapsz mindent, mielőtt számítana.

Az elmúlt hat hónapban több side projectet indítottam, mint az előző két évben összesen. Nem azért, mert keményebben dolgozom—azért, mert agresszívan delegálok biztonságos határokon belül.

Építsd be a munkafolyamatodba

Ha AI ügynököket használsz fejlesztésre, tedd fel magadnak:

1. Mit érhet el az ügynököd most? Ha a válasz "production," az probléma.
2. Van technikai korlát, ami megakadályozza a rossz lépéseket, vagy csak házirend?
3. Ki merge-el kódot? Ha nem egy ember, miért nem?

A eszközök léteznek. Token scoping, külön staging repó, branch védelem—ezek nem egzotikus Git workflowk. Ezek jelentik a különbséget AI-asszisztált fejlesztés és AI-balesetek között.

A NameOceannél sokat gondolkodunk ezen, miközben vibe coding támogatást építünk a hosting környezetünkbe. A cél nem minden automatizálása—hanem olyan terek létrehozása, ahol az AI tényleg hasznos lehet, anélkül, hogy új kockázati kategóriákat teremtene.

Az ítélőképességed továbbra is a szűk keresztmetszet. Ez nem korlát—ez a lényege. Az ügynökök azért léteznek, hogy felszorozzák, amit te el tudsz végezni—nem pedig hogy helyettesítsék azt az ítélőképességet, ami a szoftvert tényleg működőképessé teszi a valós felhasználók számára.

Építsd ennek megfelelően.