A probléma, amit nem láttunk jönni

Képzeld el: két pull request külön-külön tökéletesen működik. Tesztjei zöldek, a diff logikus, a reviewerek rábólintanak. Összemergeszed őket a main branch-re, és hirtelen az egész app összeomlik. Senki sem érti, mi a baj, mert egyik változtatás sem hibás önmagában.

Most képzeld el, hogy ez naponta megtörténik. Nem azért, mert a csapat koordinálatlan, hanem mert egy fejlesztő AI coding agentje percek alatt tucatnyi átfedő branch-t szül, miközben egy ember még egy függvényt se írt meg.

Ez a agent-assisted development új világa. Rávilágít a workflow-ink gyenge pontjaira, amik egy évtizedig jól szolgáltak minket.

Helyi tökéletesség ≠ globális harmónia

A gond lényege: egy kód lehet helyi szinten makulátlan, mégis tönkreteheti a rendszert.

Tegyük fel, az agent három branch-t készít a webes renderelődhöz:

• Branch A: Átállítja az üzenethálózatot egy gyorsabb méréssel. Tökéletes, gyorsabb, minden teszt átmegy.
• Branch B: Bővíti a markdown renderelést a régi méréssel. Izoláltan hibátlan.
• Branch C: Teljes teszteket ad a görgetéshez. Minden zöld.

Egyenként szuperül néznek ki. A code review nem jelzi a bajt, mert nincs nyilvánvaló hiba.

De ha összerakod őket? Két ellentétes mérés dolgozik párhuzamosan. A rendszer önellentmondásos. A hiba csak a kombinált replay-nél bukik ki a target branch-en.

Ez nem kódminőségi gond. Ez integrációs probléma.

A CI/CD-ed nem bírja az agent tempót

A hagyományos CI/CD – merge queue-kkal együtt – emberekre készült: több dev, közös branch-ek, központi tesztek, PR review-k, ha "elég jó" a kód.

Be van építve a lassítás: ember ír feature-t, push-ol PR-t, vár review-ra, közben mást csinál. Az integrációs nyomás a csapathatáron éri el a CI-t.

Az agentek másképp pörögnek.

Egy dev agentje egyszerre futtathat öttől húszig helyi worktree-t. Néhány stacked, mások vakvágányok, pár elavult codebase-assumpciókra épül. Olcsók, kidobhatók, és gyorsabban jönnek, mint a review.

Az integrációs nyomás helyben jelentkezik, még mielőtt remote-ra menne.

GitHub CI akkor látja, ha már órákat töltöttél review-val, rebase-szel, mentális egyeztetéssel. Merge queue már késő – a baj helyben van.

Rebase csak ragtapasz

"Az agent rebasetelje, oldja meg a konfliktusokat!" – gondolod.

Segít, de nem elég.

Rebase szöveget igazít: Git látja, hogy a 42. sor a 49-re került. De nem mondja meg, hogy az architektúra még értelmes-e.

Szándékkonfliktus nincs szövegbelvi konfliktushoz.

Egy branch OAuth2-re refaktorálja az auth-ot. Másik legacy session-t bővít egy kis feature-hez. Nincs merge konfliktus, tesztek zöldek. De együtt két auth paradigma keveredik.

Rebase sikerül, tesztek átmennek, broken kód megy live-ra.

Folyamat kell, nem csak tool

Kulcs különbség:

Rebase-elő agent = tool. Paralell agent branch-eket orchestráló workflow = folyamat.

Merge queue nem csak "várakozás PR-re". Ez:

• Sorrend: mi integrálódik először
• Replay ellenőrzés: kombinált eredményt futtat a valódi target-en
• Architektúra validáció: nem csak szöveg, hanem rendszerlogika

Agent dev-hez kell helyi integrációs queue:

1. Figyeli az összes futó agent branch-t
2. Kimutat átfedéseket, függőségeket
3. Javasol biztonságos sorrendet
4. Kombinált verifikációt futtat upstream előtt
5. Elkapja az architektúra konfliktusokat, amiket egyedi tesztek nem látnak

A gyorsaság rejtett ára

Erről senki sem beszél: a felügyelet másképp skáláz a sebességgel.

Emberi tempónál egy reviewer bírja. A review maga flow-control.

Agentek gyorsabban generálnak, mint review-olsz? A bottleneck nem lassú ember, hanem okos integráció orchestráció. El kell kapni a konfliktusokat human review előtt.

Itt lépnek be platformok, mint a NameOcean Vibe Hosting. A hosting ma már dev workflow része – a cloud környezeted értheti a deployment cadenciát, adjon early feedback-et. Képzeld: hosting layer elkapja az architektúra gondot helyi agent munkánál, GitHub push előtt. Ez a cross-stack gondolkodás, amit agent dev igényel.

Mit jelent ez a te workflow-odnak?

Ha komolyan használod az AI coding agenteket (vagy tervezed), nézd át az integrációdat:

1. Több átfedő change egy dev-től? Ha merge queue emberi, szekvenciális munkára van, sebezhető vagy.

2. Verifikáció merge után vagy előtt? Agent branch-eknek queue-ban kell, ne utána.

3. Csak szövegkonzisztencia vagy architektúra? Teszt+linter nem elég. Kell folyamat a system design ellenőrzésére.

4. Review a szűk keresztmetszet? Ha igen, nem oldottad meg az agent orchestrációt – csak torlódást okoztál.

Jó hír: megoldható. Nem kell lassítani az agenteket. Okosabbá kell tenni az integrációt.

Rosszul: a tool-od valószínűleg nem erre optimalizált. De ez izgi kihívás. Ahogy az agent-assisted dev standarddá válik, a helyi integrációt megoldó csapatok velocity-előnyben lesznek a 2010-es merge queue gondolkodókkal szemben.

A jövő nem gyorsabb dev-ekről vagy okosabb agentekről szól. Hanem workflow-król, amik orchestrálják a sebességet.