AWS Community Day CEE: ha a kódolás felgyorsul, a szűk keresztmetszet máshová költözik. Szerintünk tudjuk, hová.

A keynote: egyenetlen hatás, és hová megy a szűk keresztmetszet

Liam Greenamyre, az AWS Principal Product Managere nyitotta a napot a The (Hype-Free) AI SDLC, as of September 2026 című előadással, és már az első dia a jó kérdést tette fel: miért érezzük ennyire egyenetlennek az AI hatását? A válasza: egy átlagos héten mindhármat átéljük egyszerre, a nagy sikert, a frusztráló kudarcot és a hétköznapi apró javulást. Az egyik dián egyszerre öt „you are here" jelölés ült a hype-görbén. Ennél őszintébb helyzetképet főszínpadról még nem hallottunk.

A nagy siker a Bun újraírása volt: nagyjából félmillió sor kód Rustban, tizenegy nap alatt, legfeljebb hatvannégy agenttel párhuzamosan, a dián pedig ott volt az ellenpélda a csapat saját szavaival: három mérnök egy évig, amit sosem csináltunk volna meg. A frusztráló kudarc ugyanannyi időt kapott: ugyanaz a kérdés háromféleképpen, öt százalék javulás, aztán semmi, aztán egy százalék, és a mondat, amelyet mindannyian begépeltünk már: „feladtam, és átmentem egy másik feladatra".

Aztán a mondat, amelyen ez az egész jegyzet függ, idézve a diáról: „When coding accelerates, the bottlenecks move elsewhere." És egy diával később: lehet, hogy feljebb, a folyamat elején.

A sebesség előtt a feltételek. Context as code: amit a fejlesztő tud, az ott legyen leírva, ahol az agent el is olvassa, mert, ahogy egy másik dia fogalmazott, a teljes kontextus nem mindig látszik neked sem. Dokumentáld a kódbázist. Írd le a tenetjeidet és a döntési pontokat, hogy a modellnek ne kelljen kitalálnia, te mit döntöttél volna. Legyen ellenőrizhető a feladat. A futásidejű hibából csinálj fordítási hibát. Rövidítsd a build időt. Írj jó kiértékelési rubrikákat. Ebből semmi nem új mérnöki tanács. Ami új, az az ára: az ilyen feltételek nélkül dolgozó agent magabiztos kódot ír rossz irányba, és ezeknek a feltételeknek a felállítása valódi munka, ahogy egy feladat jó megfogalmazása is az.

Aztán a munkastílus. A prompt-driven development alapértelmezésként hangzott el, nem újdonságként: indulj egy homályos ötletből, és hagyd, hogy a modell addig kérdezzen, amíg az ötlet tiszta nem lesz. A „grill me" ugyanolyan népszerű abban a teremben, mint nálunk. Adversarial agentek: az egyik épít, a másik támad. És egy dia, amelyet a nyerseségéért szerettünk: „Goal: let your agents bash their heads against the wall", a figyelmeztetésével együtt, hogy az agentek nagyon-nagyon be akarják fejezni a feladatot, és ehhez hajlandók rövidebb utat választani. Ez a páros az oka annak, hogy a jegyzeteim tetején az áll: limited blast radius. Hadd verjék a fejüket a falba, de legyen korlátozva, mit törhet el egy rossz válasz. És a mindezek tempóját eldöntő korlát, idézve: „Inner development loop speed is your primary constraint." Tudjuk. A saját loopunk minden DEV-re push előtt egy helyi Docker buildet futtat, és ez a leglassabb becsületes lépésünk.

A rész, amelyet a legjobban szerettünk, az egész iparág ellen ment, minket is beleértve. Mérd a hatást, ne a tevékenységet. A több kód nem több profit. A példa egy AI kódreviewer volt, a diára írt guardraillel: „human review requirements don't change", és egy felfújás nélkül kimondott nyereséggel: heti néhány óra, csapatszinten. Így néz ki egy valódi szám.

Hová költözik szerintünk a szűk keresztmetszet

Ez a saját gondolatunk, és annak is írjuk. Az ATAILA Codert a saját modelljeinken futtatjuk, egy harnesszel, amely az agentet a repository szabályai között tartja, és az őszinte tapasztalat az, hogy az ügyfeleink ideje már nem a kód megírására megy el. Oda megy, ahová a keynote mutatott: a productionig vezető út még mindig nagyon bonyolult. Egy laptopon működő alkalmazást valódi környezetbe vinni, a landing zone-jába, a négy környezetébe, DEV-ről UAT-ra és PROD-ra léptetni úgy, hogy nyoma legyen, ki mit hagyott jóvá: ma ez a lassú rész. Ezért létezik az ATAILA Factory és a Release Manager, és az volt a délelőtt pillanata, amikor a szűk keresztmetszetet a főszínpadról nevezte meg az a gyártó, amelynek az eszközei a másik végét gyorsítják. Ugyanez igaz a füzetem utolsó sorára: gyorsítsd a kódreview-t. Ha a kód olcsó, a review a korlát, és a review ítélőképességi probléma, nem gépelési.

A workshop: az illesztési pont a model provider

A session, amelyet egy hete bekarikáztunk, Arnaud Jean kilencvenperces, kézzel-billentyűzettel workshopja volt, a Create Your Own Role-Playing Game with Agentic AI using Strands Agents: egy game master, amely specializált agenteket vezényel, egy kockadobó szolgáltatás MCP-n keresztül toolként, két agent, amely A2A-n beszél egymással, egy retrieval lépés a szabálykönyv fölött, és egy tipizált JSON contract, hogy egy böngészős UI meg tudja jeleníteni az eredményt. Elég kicsi, hogy egy délután alatt átolvasd, elég teljes, hogy őszinte legyen.

Mi a model provider absztrakcióért mentünk, nem a játékért, és az absztrakció szállított. A Strands Agents nyílt forráskódú SDK, Apache-2.0 licenccel, és a provider rétege egyetlen objektum: az dönti el, hogy az inferencia egy felhőrégióban vagy a saját GPU-inkon történik, és minden, ami fölötte van, a toolok, a memória, a két protokoll, a UI, ott marad, ahol volt. Kora délutánra a kész játék a saját adatközpontunkban futott, a saját vasunkon, egy elszigetelt hálózaton, amelyről egyáltalán nincs út az internetre. Az inferencia átköltöztetése konfigurációs változtatás volt, nem portolás. A teljes beszámoló, azzal együtt, mi tört el és hogyan, a privateai.blogon olvasható.

Három tanulság, amelyre nem számítottunk:

• Először nem a modell tört el. Hanem a kérés alakja: az SDK üres tools tömböt küld egy tool nélküli agentnél, és az egyik serving verziónk ezt kapásból elutasítja. Tíz sor javította. Ez egy hibrid csere valódi tanulsága: a meglepetések a plumbingban ülnek, nem az intelligenciában.
• A tool call fidelity a szám, amely számít, és szinte senki nem méri. A kis helyi modellünk vidáman mesélt kockadobásokról, amelyeket sosem dobott, és egyszer bejelentett egy karaktert, amely sosem került az adatbázisba. A nagy modell a klaszterünkön pontosan ugyanazt a feladatot hibátlanul végezte el. Ugyanaz a kód, ugyanazok a promptok, más igazmondás. Van már egy kis harnessünk, amely számolja a tool callokat, és összeveti, mit mond a modell azzal, amit a toolok visszaadtak; ez a harness fut a következő agent workloadon, nem egy benchmark pontszám.
• Rögzítsd a verziókat. A workshop saját lépései a hét közepén álltak le, mert egy upstream függőség főverziót váltott. Két import sor, egy törés, kilencven perc közös zavar egy teremben, ahol mindenki tudta, hogy ezt nem így kellene.

És a rész, amely nekünk mond ellent, ahogy megígértük, hogy megírjuk: a helyi nem automatikusan elég jó. A saját pitchünk könnyű változatát, tedd a modellt a saját vasadra és kész, egy kockadobás cáfolta meg. Egy kis on-prem modell olyan eredményeket talált ki, amilyeneket egy nagyobb nem. Az illesztési pont működik; azt, ami a két oldalán ül, use case-enként meg kell mérni, mielőtt bárki megbízik benne. Ez keményebb mondat, mint ami a főoldalunkon áll, és igazabb.

A délután: a routing kérdése nem csak a miénk

14:00-kor az Akváriumban Varga György Márk (Shiwaforce) tartotta a One Endpoint, Every Model: Building an Adaptive LLM Gateway on AWS előadást, és ez volt az a session, amely az első kérdésünkre választ adott. Épített egy gatewayt, amely sok modellt tesz egyetlen endpoint mögé, és egy kis, tanuló router választ közülük, a kód pedig nyilvános. A routing szabálya a diája szavaival: minden kérésnél minden modell a saját tartományán belül dob egy számot, ezt elosztjuk azzal, amibe a modell kerül; a legmagasabb nyer, tehát egy majdnem ugyanolyan jó, de sokkal olcsóbb modell legyőzi a drágát. Semmi nincs bedrótozva, és minden döntés indokkal kerül a logba: greedy, exploring vagy sampled. Az élő konzolja 532 kérdés után 1,31 dollár megtakarítást, nulla elhibázott választ és „80% cheaper than always-biggest" feliratot mutatott.

A diáiról két tervezési szabály egyenesen a saját gateway munkánkba megy. Az első: „route between conversations, never inside one." A prompt cache azt akarja, hogy maradj, a router azt, hogy mozogj; ha egy beszélgetés közepén váltasz, a felmelegített prefix elveszett, és az új modellen újra fizetsz érte. Kimondva nyilvánvaló, és mi nem mondtuk ki. A második egy elszámolási csapda, amelyet élőben mutatott: egy cache-elt válasz 4087 helyett 124 milliszekundum alatt jött vissza, és semmibe nem került, miközben a válasz fejléce továbbra is az eredeti töredékcentet állította, mert a proxy a cache-elt választ az eredeti usage adatokkal együtt játssza vissza. Ha a költség dashboardod fejlécekből olvas, a legolcsóbb kéréseidről hazudik neked.

Egy mondata áll hozzánk a legközelebb, és olvasható ellenünk is: „Is routing what you sell? For almost everyone it is plumbing. Nobody buys your product because of how you pick a model." Igaza van, egy termékcég esetében. És pontosan ezért tartozik a routing a termék alatti platformba, nem minden egyes termékbe; nálunk pedig a platform maga a termék. A záró szabályát úgy vesszük át, ahogy mondta: csak a valódi rést építsd meg, egyetlen komponenst ott, ahol semmilyen beállítás nem fejezi ki, amire szükséged van, és tartsd ugyanahhoz a production mércéhez, mint a többit.

A repositoryját betükröztük a saját GitLabunkba, hogy rendesen el tudjuk olvasni. Amit a kód megerősít, azért jöttünk: egy jelölt modell egyszerűen egy deployment, tokenenkénti költséggel, tehát egy endpoint a saját GPU-inkon ugyanabba a választási halmazba kerül, mint bármelyik felhőmodell. A routing kérdését mások is felteszik és megválaszolják, ugyanazon a napon, ugyanabban a városban, és ugyanoda jutnak: válassz beszélgetésenként, minőség és költség alapján, és őrizd meg, miért.

Amit hazaviszünk

• A szűk keresztmetszet a productionig vezető útra költözött. Olcsó kód, drága szállítás. A Release Managert eddig is így kellett volna leírnunk.
• Mérd a tool call fidelityt, ne a benchmark pontszámot. Egy modell, amely arról mesél, amit nem csinált meg, rosszabb egy lassabbnál, amely megcsinálja.
• Beszélgetések között routolj, sosem egy beszélgetésen belül. És ne bízz a költség fejlécben egy cache-elt válasznál.
• A use case-enkénti routing ma piaci elvárás. Mások is építik, döntésenként naplózott indokkal; a kérdés már nem az, hogy kell-e, hanem hogy mennyire jól és mennyire auditálhatóan.
• Először a plumbing törik el. Kérésalakok, függőségverziók, üres tömbök. Tervezz vele.
• Mérd a hatást, ne a tevékenységet, korlátozott blast radiusszal mindenre, amit egy agent megtehet.

Egy nap alatt három teremben ültünk, és kétszeresen megérte a jegyet.