Andrew Stellman bemutatja, hogy a szoftverfejlesztés AI-vel segített módjaira ma több, egymást részben fedő kifejezést használunk, és ez pontatlansághoz vezet. A cikk célja egy egységes, értelmezhető név — „AI-driven development” vagy röviden AIDD — mellett érvelni, amely az egész munkafolyamatot lefedi: a generálást és az azt követő ellenőrzést, illetve azt a tényt, hogy valaki felel azért, amit a rendszer szállít.
Mi a probléma a meglévő nevekkel?
A név fontos: programozásban maga a név teszi „valóssá” a fogalmat, és rosszul megválasztott elnevezés hosszú távon félrevezető lehet. Több elnevezés létezik, mindegyik a munkának külön részét ragadja meg, de egyik sem nevezi meg a teljes felelősségi és ellenőrzési folyamatot.
Vibe coding
A „vibe coding” egy felfedező, prompt-első módszer: gyors prompt, kód vissza, iteráció. Andrej Karpathy alkotta a kifejezést; Stellman szerint hasznos technika és kreatív módja sok kód gyors előállításának. Ugyanakkor önmagában nem biztosítja, hogy a leszálló kód megfelel a céloknak vagy követelményeknek: ha a fejlesztők túlságosan támaszkodnak erre, elveszhet az áttekintés a megvalósítás felett, és a végeredmény nem azt csinálja, amit elvártak. Stellman ezért fejlesztette a Sens-AI Frameworköt, amely segít felismerni, mikor kell elmozdulni a vibe codingtól és több kutatást, kritikus vizsgálatot alkalmazni.
Prompt engineering és loop engineering
A „prompt engineering” arra a készségre utal, hogy a modelleknek jól megfogalmazott, kontextusos utasításokat adunk, mert a pontatlan kérés hibás vagy nem kívánt kódot eredményezhet. Ez a név azonban sokak számára egy-egy kérés alapú munkamódot sugall, amit kezd elavultnak érezni a gyorsan terjedő agent-alapú munkafolyamatok mellett.
„Loop engineering” Addy Osmani által javasolt elnevezés: a promptolás skálázott, rendszerszintű változata, ahol egy hurkon keresztül ütemezik és újrafuttatják az agentek feladatait — a promptok megmaradnak, de nem kézzel gépelik őket minden körben. Stellman szerint a loop engineering pontosan a gépezet tervezését nevezi meg, de önmagában nem dönt arról, hogy a gépezet által előállított kód valóban megfelel-e a követelményeknek.
Agentic engineering
Az „agentic engineering” kifejezést Andrej Karpathy is használta, és azt a munkát írja le, amikor a fejlesztő nem maga írja a kódot, hanem agenteket irányít, amelyek végzik a munkát. Boris Cherny, a Claude Code vezetője, állítása szerint agentek tömegeit is dirigálja. Az agentek irányítása menedzseri feladattá változtatja a mérnöki szerepet: a felelősség a végtermékért ugyanúgy az embernél marad, mint a hagyományos csapatoknál, mert nem lehet az agentekre hárítani a felelősséget.
Spec-driven development
A „spec-driven development” a régi, bevált minták sorába illeszkedik: előre írt specifikációk, elfogadási kritériumok és tesztek határozzák meg, mit kell teljesítenie a kódnak. Mivel az AI olcsóvá tette a kódgenerálást, a költség nagy része az ellenőrzésre és a verifikációra tevődik át, ezért a spec-driven szemlélet fontos: írjuk le a követelményt a generálás előtt, így van szabvány arra, ami később ellenőrizendő.
Melyik név mire jó — és mi hiányzik belőlük?
- Vibe coding: az exploratív vég; gyors kódgenerálás, de kevés garancia a megfelelésre.
- Prompt engineering: a készség a megfelelő utasítások megfogalmazására.
- Loop engineering: a rendszerszintű hurkok és automatizált ütemezés tervezése.
- Agentic engineering: agentek és azok üzemeltetésének architektúrája; a szerep menedzseri jellege.
- Spec-driven development (és test-/behavior-driven minták): a verifikáció és a követelményekhez való igazítás.
Ezek a nevek mind valós munkadarabokat írnak le, de semelyik nem nevezi meg egyszerre a generálást, az ellenőrzést és a felelősséget. Ezt a hiányosságot pótolná az „AI-driven development”.
Mit takar az „AI-driven development”?
Az AIDD átöleli a teljes munkafolyamatot: az AI által végzett generálást, a specifikációk szerinti verifikációt, a hibafelfedezést és a végső felelősséget, amelyet ember visel. Az AIDD lényege nem a gépezet konkrét felépítése, hanem az a fegyelmezett szemlélet és a minőségi elvárás, amihez mérik a munkát — ugyanúgy, mint a test-driven vagy behavior-driven development elnevezések esetében.
Stellman gyakorlati szokásai, amelyek az AIDD részét képezik:
- A specifikáció vagy interfész megírása a generálás előtt, hogy legyen elfogadási kritérium.
- Több modell vagy több review használata, mert a modellek eltérően hibáznak.
- Hibák közös, pontos fogalmi keretbe helyezése (például: hibás a spec szerint; a kód technikailag helyes, de rossz funkciót ad; viselkedés, amit senki nem specifikált).
- Emberi döntéshozó fenntartása a végső mérésnél és felelősségnél — a mesterséges intelligencia eredményeit embernek kell helytállóvá tenni.
A figyelmeztetés világos: ha ezeket a lépéseket kihagyják, könnyen „vibe slop” keletkezik — magabiztosan kinéző, de valójában ellenőrizetlen és hibás output.
Lehet-e egy név mindenre kiterjedő?
Az AIDD mint gyűjtőnév akkor állja meg a helyét, ha egyetlen alapigazságot tud megfogalmazni: valaki vállalja a végeredményért a felelősséget. A különböző módszerek a skála különböző pontjain eltérő verifikációt igényelnek (prototípusnál kevesebb, éles terméknél teljes minőségbiztosítás), de a „ki áll a termék mögött” kérdés minden esetben jelen van. Ez az egységesítő szempont az, amit a meglévő nevek nem fednek le; az AIDD pedig erre a közös nevezőre épít.
Következtetés
Stellman végkövetkeztetése szerint minden meglévő név — vibe coding, prompt engineering, loop engineering, agentic engineering és spec-driven development — valós és hasznos. De mindegyik a munkafolyamat egy darabját ragadja meg. Az „AI-driven development” javasolt gyűjtőnév arra szolgál, hogy a generálást, a verifikációt és a felelősséget egy fegyelmezett, megnevezett diszciplínaként írja le. Az AI olcsóvá tette a kód generálását, de nem szüntette meg a felelősséget: aki irányítja az AI-t, annak továbbra is vállalnia kell, hogy a leszálló termék megfelel-e a követelményeknek.
