Paul Iusztin szoftvermérnök három hónappal ezelőtt saját „software factory”-jét, a Squidet építette meg, hogy Decoding AI kis- és közepes méretű projektjeit minimális emberi beavatkozással tudja kiadni. A szerző július 2026-ban annak a tapasztalatnak az alapján ír, hogy a gyakorlatban a „vibe coding” és a kódoló ügynökökkel előállított tiszta, karbantartható kód között éles különbség van — ezt a határt a szoftvergyárak jelölik ki.
Mi az a szoftvergyár?
A szoftvergyár a fizikai gyár analógiájára automatizálja a szoftverfejlesztés teljes életciklusát (SDLC) úgy, hogy a bemenetek — hibajegyek, feature-ötletek, incidentek — feldolgozódnak, és kimenetként működő, kiadott szoftver jön létre. A gyárhoz néhány magas képzettségű emberre van szükség, akik magas hozamú döntéseket hoznak, és olyan átjárókra (gates), amelyeken munka nem haladhat át emberi jóváhagyás nélkül.
Factory.ai definíciója szerint ez egy "self-improving system for your Software Development Life Cycle (SDLC)"; Addy Osmani pedig úgy írja le a rétegezést, hogy a loop az atom, a factory pedig egy "org chart made of loops". Warp vezérigazgatója, Zach Lloyd szerint pedig „software engineering will become factory engineering.”
Iusztin nyolc, egymással összefüggő szakaszra bontja a szoftvergyárat, amelyek három nagyobb csoportba sorolhatók:
-
Mit építsünk
- Triage/intake: az érkező munkák osztályozása, duplikációk kiszűrése és útválasztás
- Brainstorming: piaci elemzés, felhasználói adatok és technikai kutatás révén magas hatású ötletek megtalálása
- Planning: a legfontosabb szakasz, ahol a kutatásból kiválik egy kiforrott terv; az ügynök „grilleli” a tervet, döntéseket ADR-be (Architecture Decision Record) és glosszáriumba rögzítenek; a kimenet ticketek és dokumentáció
-
Terv megvalósítása és ellenőrzése
- Implementing: egy szoftvermérnök- és QA-ügynök loop, amely a ticketeket végrehajtja és teszteli
- Review: PR-diff ellenőrzése termék-, architektúra- és kód szabványok szerint
- Review-CI: a tesztcsomag lefuttatása; hibák esetén egy javító ügynök lép fel
- Release: folyamatos kiadás staging/productionba emberi deployment-checkpontokkal
-
Önálló fejlődés
- Monitor/incident response: a produkcióból érkező jelek (riasztások, hibák, incidentek) visszacsatolódnak a triage-ba, új munkaként bezárva a kört
Ezek fölött egy közös „context layer” áll, amely dokumentációt, felhasználói analitikát, versenyelemzést, átírásokat és egyéb forrásokat tartalmaz. A brainstorming és a planning különösen érzékeny erre a rétegre: ha a kontextus rossz vagy hiányos, az ügynökök csak a legvalószínűbb, de nem feltétlenül a legjobb megoldást fogják előállítani. Egyre népszerűbb megoldás az LLM Wiki (Andrej Karpathy által elnevezett stratégia), amely sima fájlokból strukturált tudásbázist hoz létre — például Factory AutoWiki vagy LangChain OpenWiki eszközei.
Hol van szükség emberre?
Iusztin egy ecommerce-szerű példa mentén mutatja be a helyet: ha egy shopping-assistant ajánlórendszere alacsony felhasználói elköteleződést produkál, a brainstorming és planning fázisokban van szükség emberi ízlésre és stratégiai döntésekre. Az ügynökök képesek nagy mennyiségű adatot feldolgozni és javaslatokat hozni, de az embernek kell a végső üzleti problémát megfogalmaznia, majd a megvalósíthatóság, költség, latencia és architektúra szempontjából pontos tervet kialakítania. A terv kifinomultsága meghatározza, hogy később olcsóbb modellek (Opus, Sonnet) képesek-e sikeresen végrehajtani a feladatot; gyenge terv esetén a kisebb modell több kísérletet igényel, ami összességében drágább lesz (token × ár számít).
A valós kivitelezésnél a loop úgy működik, hogy az implementáló ügynök felveszi a kész ticketeket, végrehajtja, majd egy QA-ügynök megpróbálja megtalálni a hibákat. Fontos, hogy az ügynökök hozzáférjenek az alkalmazáshoz ugyanúgy, mint egy emberi felhasználó: le kell tudni indítani a stack-et, vezérelni a böngészőt, hívni API-kat vagy adattápláló csöveket. A feedback loopok (lint, unit, integrációs és e2e tesztek) beágyazása kritikus; ha a loop folyamatosan bukik, a probléma jellemzően hiányzó infrastruktúra.
A review három lépésből áll: termék/architektúra ellenőrzés (eltérések új ticketet generálnak), kódminőség vizsgálata (modularitás, névadás, AI-specifikus hibák kiszűrése), és CI/CD csővezeték átnézése. A gyár "végén" marad egy PR, amelyet embernek kell felülvizsgálnia és merge-elnie. Ha a planning jól sikerült, a PR általában deploy-hoz készen érkezik.
Ne építs túl nagyot
Iusztin saját Squid-prototípusánál elkövette a túlzás hibáját: mindent automatizálni akart, teljesen autonóm, párhuzamos ügynökhálózatot indított. Amikor valami „off-script” történt, nem tudta egyszerűen megállítani vagy módosítani a folyamatot. Tanulsága: szükség van finomgranuláris parancsokra (egy terv „grillelése”, egy konkrét feladat implementálása, egy adott lépés ellenőrzése), és egy end-to-end parancsra, amikor valóban teljes autonómiát adunk. A terv és a végrehajtás külön parancsként maradjon — a tervezés továbbra is emberi feladat.
Néhány további megfigyelés:
- A szűk keresztmetszet gyakran a tervezés: Iusztin szerint nála ez maradt a legfontosabb bottleneck a folyamatos automatizálás ellenére.
- Kis csapatoknál helyben futó, izolált ügynökök (worktree-k) gyakran elegendők; 24/7 távoli ügynökök menedzselése nagy logisztikai terhet jelent.
- Nagy csapatok indokolhatják a több automatizálást, de annak értelmet kell adni: először a legidőigényesebb akadályokat automatizáljuk.
Építsünk vagy vegyünk kész megoldást?
A legtöbb projekt előre elkészített coding harness-szel indul: zárt rendszerek például Claude Code vagy Codex; nyílt forrású lehetőségek az OpenCode vagy Pi. Azonban a harness kiválasztása csak az első lépés: tudni kell, hogyan konfiguráljuk és illesztjük be a saját szoftvergyár folyamatába. Emiatt fontos, hogy a mérnökök értsék az ügynökloop belső működését, a távoli futtatás következményeit, és a kontextus‑kezelési stratégiákat.
Kis csapatoknak gyakran elegendő egy kész készlet skill és agent definiálása .md fájlokban, ahogy Iusztin is tette Squiddel. Vannak off-the-shelf megoldások is (például Matt Pocock skills-repozitóriuma vagy a BMad módszer), illetve platformok mint Factory.ai (droid agenttel) vagy Warp Oz, amelyek integrálódnak meglévő munkafolyamatokba. A vásárlás akkor éri meg, amikor a felügyelet nélküli ügynökök futtatása, megfigyelhetősége, költségkövetése és token-számlázása olyan szerepeket igényel, amelyek nem a termék fejlesztéséhez kapcsolódnak.
Az ellenkező irányban akkor érdemes saját megoldást építeni, ha a platform korlátai többe kerülnek, mint a saját csapat kialakítása — ahogy az OpenAI Codex-kísérlete is jelezte.
Mire számítsunk tovább?
Újabb „_____ engineering” címkék jelennek meg folyamatosan, de a valódi változást az jelenti, ha a folyamatok kézzelfogható termékekhez vezetnek. Zach Lloyd ajánlása szerint érdemes egy „idegesítő” munkarészt kiválasztani, és megépíteni a legkisebb loopot, ami azt megoldja.
A szoftvergyárak még kezdeti állapotban vannak: távol állnak a tökéletestől és a teljes autonómiától. Iusztin szerint reális cél, hogy a teljes SDLC automatizálhatóvá váljon, kivéve a brainstormingot és a tervezést, de jelenleg még tapasztalatokat gyűjtünk. Nála a tervezés maradt az állandó emberi szűk keresztmetszet.
Kérdések a gyakorlatból
Melyik gyárfázis igényli nálad a legtöbb emberi beavatkozást? Iusztin azt javasolja, hogy folyamatosan automatizáljunk, de tartsuk észben: legyen lehetőség belépni, megállítani és átirányítani a folyamatot, miközben fennmarad a teljes autonómia opciója.
