AI Agentek mikromenedzselése helyett: OpenAI Symphony
Az OpenAI Symphony megmutatja, hogyan lehet a Linear és a ticketalapú munka az AI Agentek vezérlőpultja.
A marketing kicsit elrontotta az "AI Agent" kifejezést. Ma már majdnem mindenre ráhúzzák, ami válaszol egy promptban, pedig a valódi AI Agent ott kezdődik, hogy munkát kap, eszközöket használ, és valamilyen ellenőrizhető eredményt ad vissza.
És itt jön a kellemetlen rész: minél több AI Agentet indítasz el, annál több koordinációs munka keletkezik.
Az OpenAI mérnökei is ebbe futottak bele. A Codex gyors volt, a fejlesztők viszont egy idő után már nem kódoltak, hanem sessionöket figyeltek, nudgoltak, javítgattak, újraindítottak. Erre építették meg a Symphony mintát.
A szűk keresztmetszet az emberi figyelem
Interaktív AI coding eszközzel dolgozni eleinte nagyon látványos. Elindítasz egy sessiont, adsz neki egy feladatot, nézed, ahogy dolgozik. Aztán elindítasz még kettőt. Aztán még hármat.
Egy pont után már nem a munka gyorsul, hanem a fejed telik meg zajjal.
Az OpenAI-nál azt látták, hogy egy fejlesztő kényelmesen nagyjából 3-5 AI Agent sessiont tud párhuzamosan kezelni. Ennél többnél a context switching elkezdi megenni a nyereséget. Melyik ablakban mi fut? Hol állt meg a teszt? Melyik AI Agent ment rossz irányba? Melyik PR vár review-ra?
Ez ismerős mintázat. Nem az eszköz lassú. A rendszer rosszul osztja el a figyelmet.
Ha minden AI Agenthez emberi felügyelet kell, akkor az ember lesz a bottleneck. Nem azért, mert lassú vagy ügyetlen, hanem mert egyszerűen nem erre való az idegrendszerünk.
Ne az Agentet kezeld, hanem a munkát
A Symphony mögötti felismerés józan és nagyon praktikus: a csapatok eleve ticketekben gondolkodnak.
Nem sessionöket kell menedzselni. Nem terminálablakokat. Nem félkész PR-okat. Hanem feladatokat.
A Symphony ezért a projektmenedzsment rendszert, például a Lineart, használja vezérlőpultként. Nyitsz egy ticketet, a rendszer észreveszi, létrehoz hozzá egy izolált munkakörnyezetet, majd elindít rá egy AI Agentet.
A gyakorlatban ez így néz ki:
- Felveszel egy feladatot Linearban.
- A Symphony látja, hogy a ticket dolgozható.
- Egy AI Agent saját workspace-ben elkezdi a munkát.
- Ha végez, visszaadja a kódot, a megjegyzéseket, és ideális esetben egy review-csomagot is.
Ha a ticket blokkolva van, az Agent nem kezd hozzá. Ha munka közben talál egy külön kezelendő hibát vagy refaktorötletet, nyithat rá új ticketet. Ez sokkal közelebb áll ahhoz, ahogy egy rendes termékcsapat működik, mint ahhoz, hogy valaki öt terminál között ugrálva próbálja észben tartani, melyik AI éppen mit csinál.
A váltás lényege egyszerű: az AI Agent nem egy chatablak, amit figyelni kell. Inkább végrehajtó kapacitás, amit jól megírt ticketeken keresztül lehet irányítani.
Ez nem csak fejlesztői kényelmi kérdés
A legérdekesebb szám az OpenAI posztjában az, hogy egyes csapatok három hét után ötször annyi PR-t tudtak beolvasztani, mint korábban.
Ezt nem érdemes úgy olvasni, hogy "akkor most minden ötször gyorsabb lett". A valóság ennél kevésbé tiszta, de pont ezért érdekesebb.
A Symphony ott változtatja meg a gazdaságtant, hogy leviszi a kísérletezés érzékelt költségét. Egy refaktorötlet, egy apró termékhipotézis vagy egy technikai vizsgálat már nem feltétlenül igényel fél nap emberi fókuszt. Ticket lesz belőle. Az AI Agent megpróbálja. Ha használható, review-zod. Ha nem, tanultál belőle, és általában az is kiderül, hol hiányzik teszt, dokumentáció vagy pontosabb instrukció.
Ez a PM-eknek és designereknek is fontos. Nem kell repót klónozniuk, Codex sessiont indítaniuk vagy terminált kezelniük ahhoz, hogy kipróbáltassanak egy ötletet. Leírják a kérést a ticketben, majd kapnak egy működő változatot vagy egy review-csomagot.
Persze ettől még nem tűnik el a mérnöki ítélőképesség. Sőt. Csak máshová kerül. Kevesebb idő megy el az AI Agentek terelgetésére, és több marad scope-ra, architektúrára, minőségre, review-ra.
A Symphony inkább munkaszervezési minta, mint termék
A Symphony GitHub repó legfurcsább része elsőre az, hogy nincs benne egy klasszikus "itt a kész SaaS, telepítsd" élmény. A központi elem egy SPEC.md: egy leírás arról, hogyan működjön egy olyan service, amely ticketekből indít AI coding munkákat.
Szerintem ez a jó része.
Az OpenAI nem azt mondja, hogy minden csapat ugyanazt a rendszert használja. Azt mutatja meg, milyen operációs logikára van szükség, ha az AI Agentek már nem egyszeri promptokra válaszolnak, hanem párhuzamosan dolgoznak egy valódi backlogon.
Itt kezdődik az AI transzformáció kevésbé látványos, de sokkal fontosabb része. Nem az a kérdés, hogy "melyik modell tud kódot írni?". Hanem ezek:
- Hol él a feladat kontextusa?
- Mikor dolgozhat önállóan egy AI Agent?
- Mi számít kész eredménynek?
- Ki review-zza?
- Mit csinálunk, ha rossz irányba ment?
- Hogyan kerül vissza a tanulság a workflow-ba?
A csapat, amelyik ezekre jól válaszol, tényleg gyorsulni fog. Aki csak több AI Agentet indít ugyanabba a régi munkamódszerbe, az valószínűleg csak több figyelmet fog elégetni.
Hasznos linkek
Ha a te csapatod is tisztább irányvonalat, erősebb UX-et vagy senior szintű támogatást keres egy komplex digitális és AI-integrációs projekthez, foglalj egy 30 perces konzultációt a Studio Kutival. Ennyi idő általában elég ahhoz, hogy lássuk, hol szivárog el a legtöbb figyelem a workflow-ban.
További írások az archívumból
Hogyan készítsd el az első AI Agentedet 30 perc alatt, kódolás nélkül
Gyakorlati útmutató az első valódi AI ügynököd felépítéséhez projekttel, utasításokkal és eszközökkel, kódolás nélkül.
9 Months of Customizing Claude Code: What I Built and Why
How I turned Claude Code from a default AI assistant into a personalized workflow — 9 skills, 55 plugins, daily routines, and the philosophy behind it all.
Ehhez a gondolathoz kapcsolódó projektek
Open Brain: Building a Personal Knowledge Backend with AI
Open Brain: Building a Personal Knowledge Backend with AI What if your notes could think? Not in a sci fi way — but in a practical, "I wrote something three months ago th…
Raiffeisen Bank: End-to-End Online Account Opening
Raiffeisen Bank: End to End Online Account Opening When Raiffeisen Bank decided to let customers open a bank account entirely online — no branch visit required — they kne…