# Building an AI-native engineering team — OpenAI business guide (2026-07-31)

> **Forrás:** OpenAI Business Guides & Resources — "Building an AI-native engineering team: How coding agents accelerate the software development lifecycle"
> **PDF URL:** https://cdn.openai.com/business-guides-and-resources/building-an-ai-native-engineering-team.pdf
> **Dátum:** 2026-07-31 (feldolgozás dátuma; a cikk 2025-ös METR-adatra hivatkozik, augusztusi cutoff)
> **Szerző:** OpenAI
> **Feldolgozás:** pdftotext -layout (7.8 MB PDF → 4044 szó, 749 sor), 1 self-write a fő agenttől (5-7K szó tartomány alatt, `rész-size-decision-table` szerint 0 subagent + 1 self-write)
> **Canonical mappa:**
> **Wiki raw:**

**A guide fő tézise:** a coding agent-ek (OpenAI Codex-szel példálózva) az SDLC minden fázisát átalakítják — a „mechanikus, többlépcsős munkát” átveszik, a mérnök a magasabb rendű döntésekre fókuszál. A képességek 2025 augusztusában (METR-mérés) elérték a 2 óra 17 perc folytonos munkát 50%-os sikerességi aránnyal; a képesség duplázódási ideje nagyjából 7 hónap. A „Delegate / Review / Own” keretrendszer fázisonként részletezi, mit kell az agent-re bízni, mit kell review-zni, és mi marad a mérnöknél.

## A kiindulópont — autocomplete-től a multi-agent felhőkig

A coding tool-ok három hulláma:

1. **Autocomplete** — következő sor, függvény-sablon kitöltése (kb. 30 másodperc reasoning, néhány éve)
2. **Chat IDE** — pair programming, kód-exploration (rövidebb, irányított)
3. **Coding agent-ek** — teljes fájlok, új projektek vázszerkezete, multi-step debug és refaktor; az execution az egyéni dev gépéről áttevődött a **cloud-based, multi-agent környezetekbe**

A képességek négy előfeltétele:

- **Unified context** — egy modell olvassa a kódot, konfigot, telemetry-t, konzisztens reasoning-gal a rétegek között (korábban külön tool-ok kellettek).
- **Structured tool execution** — a modellek compiler-eket, test runner-eket, scannereket hívnak, mérhető eredménnyel (nem statikus suggestion).
- **Persistent project memory** — hosszú context ablakok + compaction: a modellek egy feature-t proposal-től deployment-ig követnek, emlékeznek a korábbi design-döntésekre és korlátokra.
- **Evaluation loops** — unit tesztek, latency target-ek, style guide-ok automatikus tesztelése; a fejlesztés mérhető minőségre van lehorgonyozva.

Az OpenAI belső tapasztalata: hetek helyett napok, csapatok domain-ek között mozognak, gyorsabb onboarding, nagyobb agilitás. A rutin feladatok (új kód dokumentálása, releváns tesztek felszínre hozatala, dependency-k karbantartása, feature flag-ek kipucolása) teljesen a Codex-re vannak delegálva. Ami **változatlan**: a kód valódi ownership-je (különösen új vagy ambiguous problémáknál) a mérnöké marad, és vannak feladatok, amik átmennek a modellek képességén.

## Plan — Issue-tracking + kód-aware scoping

**A probléma:** a csapatok a mérnököktől függenek a feature feasibility, az időigény és az érintett rendszerek megállapításánál; a pontos terv általában mély kódbázis-ismeretet + több iterációs kört igényel.

**Hogyan segít az agent:** a coding agent-ek azonnali, code-aware betekintést adnak planning és scoping közben — workflow-k kötik össze őket az issue tracking rendszerekkel, hogy olvassanak egy feature spec-et, összevessék a kódbázissal, és jelezzék az ambiguításokat, bontsák a munkát sub-component-ekre, becsüljék a nehézséget. A code path-ak azonnal trace-elhetők — órák-napok helyett azonnali lista, hogy mely service-ek érintettek.

**Mit csinál a mérnök:** kevesebb meeting, több core feature munka, gyorsabb döntések.

- **Delegate:** az agent-ek első lépésben feasibility és architekturális analysis-t végeznek — spec-et olvasnak, mappolják a kódbázishoz, azonosítják a dependency-ket, felszínre hozzák az edge case-eket.
- **Review:** a team review-ja az agent megállapításait, validálja a pontosságot, ellenőrzi a completeness-t, biztosítja, hogy a becslések a valós technikai korlátokat tükrözik (story point, effort sizing, non-obvious risks — ezek még mindig emberi ítéletet igényelnek).
- **Own:** stratégiai döntések (prioritizáció, hosszú távú irány, sequencing, tradeoffs) — a végső felelősség a szervezeté.

**Getting-started checklist:** azonosítsd a feature-ek és a forráskód közötti alignment-mechanizmusokat (feature scoping, ticket creation). Kezdd alap workflow-kkal: issue-k tag-elése és deduplikálása, feature request-ek. Haladóbb: sub-task-ok hozzáadása egy ticket-hez az eredeti feature leírásból, vagy agent-run indítása, amikor a ticket egy adott stádiumba ér.

## Design — Multi-modalitás + MCP a komponenskönyvtárakhoz

**A probléma:** a design fázist a boilerplate lassítja — UI komponensek integrálása, design rendszerek finomítása; a mockup-ok és az implementáció közti eltérés gyakori rework-ot okoz, és a limiteált bandwidth késlelteti a design validációt.

**Hogyan segít az agent:** az AI coding tool-ak drámaian gyorsítják a prototípus-készítést — boilerplate kód vázszerkezete, projekt struktúra, design token-ek és style guide-ok azonnali implementációja. A mérnökök természetes nyelven írják le a kívánt feature-t vagy UI layout-ot, és prototípus-kódot / komponens-stub-okat kapnak, amelyek követik a csapat konvencióit. A mockup-ok közvetlenül kóddá alakíthatók, accessibility javaslatokkal, sőt a code-base elemzésével user flow-k és edge case-ek feltárásával.

**Mit csinál a mérnök:** core logika finomítása, skálázható architekturális minták, quality és reliability standard-ok betartása. A designer-ek a user flow-kat és alternatív koncepciókat vizsgálják. Az együttműködés áttevődik az implementációs overhead-ről a termék-élmény javítására.

- **Delegate:** agent-ek kezelik a kezdeti implementációs munkát — projektek vázszerkezete, boilerplate kód generálás, mockup-ok komponensekké alakítása, design token-ek és style guide-ok alkalmazása.
- **Review:** a csapat review-ja az agent outputját, hogy a komponensek kövessék a design konvenciókat, megfeleljenek a quality és accessibility standard-oknak, helyesen integrálódjanak a meglévő rendszerekbe.
- **Own:** a csapat birtokolja az átfogó design rendszert, UX mintákat, architekturális döntéseket és a user experience végső irányát.

**Getting-started checklist:** multi-modal coding agent, amely szöveget és képet is fogad; integráld a design tool-okat a coding agent-ekkel MCP-n keresztül; programmaticusan tedd elérhetővé a komponenskönyvtárakat MCP-n, és integráld a coding model-lel; építs workflow-kat, amelyek designs → components → implementation map-et követnek; használj típusos nyelveket (TypeScript), hogy definiáld az érvényes prop-okat és sub-component-eket az agent számára.

## Build — A legnagyobb hatású fázis

**A probléma:** a build fázis az, ahol a csapatok a legnagyobb friction-t érzik — spec-ek lefordítása kód-struktúrákká, service-ek összekötése, pattern-ek duplikálása a kódbázisban, boilerplate kitöltése. Egy kis feature is órákig tartó „busy-work”-ot jelent. Ahogy a rendszerek nőnek, a friction compound-ol — nagy monorepo-k felhalmoznak pattern-eket, konvenciókat, történeti kvirkeket, amelyek lassítják a contributor-okat.

**Hogyan segít az agent:** a coding agent-ek az IDE-ben és CLI-ben nagyobb, multi-step implementációs feladatokat kezelnek — teljes feature-ök end-to-end (data modellek, API-k, UI komponensek, tesztek, dokumentáció) egy koordinált futásban. A hosszan futó feladatoknál az agent-ek:

- Teljes feature-implementációkat draftolnak egy spec alapján
- Build hibákat javítanak menet közben, emberi beavatkozás nélkül
- Több tucat fájl között keresnek és módosítanak, miközben konzisztenciát tartanak
- Teszteket írnak az implementáció mellett, egyetlen workflow részeként
- Boilerplate-et generálnak, amely követi a konvenciókat (error handling, telemetry, security wrapper-ek, style pattern-ek)
- Diff-ready changeset-eket készítenek, amelyek követik a belső irányelveket és tartalmazzák a PR message-t

Az eredmény: a „mechanikus build-munka” a mérnökökről áttevődik az agent-ekre, a mérnökből reviewer, editor, és a „direction forrása” lesz.

**Mit csinál a mérnök:**

- Termék-viselkedés, edge case-ek és spec-ek pontosítása az implementáció előtt
- Minták, guardrails és konvenciók tervezése, amelyek az agent-generálta kódot vezetik
- AI-generálta kód architekturális implikációinak review-ja a rote wiring helyett
- PM-ekkel és design-nal való együttműködés a feature intent iterálásán, nem a boilerplate-en
- Business logika és performance-kritikus útvonalak finomítása, amelyek mély domain-reasoning-ot igényelnek

A mérnök nem a feature spec-et fordítja kódra, hanem correctness-re, coherence-re, maintainability-re és hosszú távú minőségre koncentrál.

- **Delegate:** agent-ek draftolják az első implementációs pass-t jól-specifikált feature-ökhöz — scaffolding, CRUD logika, wiring, refaktorok, tesztek. Ahogy a hosszan futó reasoning javul, egyre inkább end-to-end build-eket fednek le, nem csak izolált snippet-eket.
- **Review:** a mérnökök értékelik a design döntéseket, performance-t, security-t, migrációs kockázatot és domain alignment-et, miközben korrigálják a finom hibákat, amiket az agent kihagyhat.
- **Own:** a mérnök megtartja az ownership-t a mély rendszer-intuíciót igénylő munkánál: új absztrakciók, cross-cutting architekturális változások, ambiguous termék-követelmények, hosszú távú maintainability trade-off-ok.

**Példa — Cloudwalk:** mérnökök, PM-ek, design-erek és operátorok naponta használják a Codex-et arra, hogy a spec-eket működő kóddá alakítsák — script, új fraud rule, vagy teljes microservice, percek alatt leszállítva.

**Getting-started checklist:** kezdj jól specifikált feladatokkal; az agent használjon egy planning tool-t MCP-n keresztül, vagy írjon egy PLAN.md fájlt, amelyet commitolnak a kódbázisba; ellenőrizd, hogy az agent által futtatni kívánt command-ok sikeresek-e; iterálj egy **AGENTS.md** fájlon, amely kioldja az agentic loop-okat (tesztek, linterek futtatása visszacsatolásként).

> **Megjegyzés:** az `AGENTS.md` (agent-eknek szóló, a repo-ban tárolt rendszerüzenet) a guide egyik fő konkrét, technikai javaslata — ugyanaz a pattern, amit a Hermes Agent saját dokumentációjában (`*/SKILL.md` + `AGENTS.md`) is használ, és amit a `hermes-agent-skill-authoring` skill formalizál.

## Test — Second-opinion + mindig friss tesztek

**A probléma:** a fejlesztők nehezen biztosítanak adequate test coverage-t — a comprehensive tesztek írása és karbantartása idő, context switching és az edge case-ek mély megértése kell. A csapatok gyakran szembesülnek trade-off-fal a gyors haladás és az alapos tesztelés között — amikor a határidők szorítanak, a test coverage szenved először. Még ha a tesztek meg is vannak írva, a kóddal együtt frissen tartásuk ongoing friction-t jelent: a tesztek törékennyé válhatnak, tisztázatlan okokból fail-elhetnek, és a termék változásával együtt nagy refaktor-t igényelhetnek.

**Hogyan segít az agent:** AI coding tool-ok több erőteljes módon segítenek a jobb tesztek author-olásában. Először is, javasolhatnak teszt eseteket a requirements document és a feature kód logikájának olvasásával — a modellek meglepően jók az edge case-ek és failure mode-ok javaslatában, amelyeket a fejlesztő könnyen figyelmen kívül hagyhat, ha mélyen fókuszálva van a feature-re. Emellett a modellek segítenek a tesztek naprakészen tartásában, ahogy a kód fejlődik, csökkentve a refaktor friction-jét és elkerülve az elavult, flakessé váló teszteket.

**Mit csinál a mérnök:** az AI tool-okkal való tesztírás nem szünteti meg a fejlesztők gondolkodásának szükségességét. Ahogy az agent-ek eltávolítják a kódgenerálás korlátait, a tesztek egyre fontosabb forrásként szolgálnak az alkalmazás funkcionalitásáról. Mivel az agent-ek futtathatják a test suite-t és iterálhatnak az output alapján, a magas minőségű tesztek definiálása gyakran az első lépés egy agent számára, hogy build-eljen egy feature-t. A fejlesztők a magas szintű pattern-ekre fókuszálnak a test coverage-ben, kihívások elé állítva és építkezve a modell által azonosított tesztesetekre.

- **Delegate:** a mérnökök delegálják a tesztesetek generálásának első lépését feature spec-ek alapján — hasznos, ha a modell **külön session-ben** generálja a teszteket, mint a feature implementáció.
- **Review:** a mérnök alaposan review-ja a modell-generálta teszteket, hogy ne legyenek shortcut-ok vagy stub-ok; biztosítja, hogy a tesztek futtathatók legyenek az agent-ek számára (a megfelelő permission-ök és a teszt-suite-k context-tudatossága mellett).
- **Own:** a mérnök birtokolja a teszt-coverage igazítását a feature spec-ekhez és a user experience elvárásokhoz. Adversarial gondolkodás, kreativitás az edge case-ek mappelésében és a tesztek intent-jére való fókusz maradnak kritikus skill-ek.

**Getting-started checklist:** a modell a teszteket **külön lépésben** implementálja, és a validálás, hogy az új tesztek fail-eljenek a feature implementáció előtt; guideline-ok a test coverage-hez az `AGENTS.md` fájlban; konkrét példák a code coverage tool-okról, amelyeket az agent hívhat a test coverage megértéséhez.

> **Megjegyzés:** a „külön session a teszthez” elv megegyezik a podcast-processing pipeline „kis utolsó rész self-write” és a subagent-kiosztás split-jével — a független context-ablak megakadályozza, hogy a feature-implementáció ASR-hibái vagy hallucinációi átterjedjenek a tesztekre.

## Review — AI code review a P0/P1 bug-okra hangolva

**A Probléma:** átlagosan a fejlesztők heti 2-5 órát töltenek code review-val. A csapatok gyakran szembesülnek a választással: invesztálnak-e jelentős időt egy mély review-ba, vagy egy gyors „good enough” pass-t adnak kis változtatásokra. Amikor ez a priorizáció elcsúszik, bug-ok jutnak a produkcióba, user-eknek okoznak problémát és jelentős rework-ot generálnak.

**Hogyan segít az agent:** a coding agent-ek lehetővé teszik a code review folyamat skálázását, hogy minden PR konzisztens baseline figyelmet kapjon. A tradicionális statikus analízis tool-okkal ellentétben (amelyek pattern matching-re és rule-based ellenőrzésre épülnek) az AI review-erek valóban végrehajthatnak kódrészleteket, értelmezhetik a runtime viselkedést és logikát trace-elhetnek fájlok és service-ek között. **A hatékony működéshez a modelleket kifejezetten a P0 és P1 szintű bug-ok azonosítására kell tanítani, és úgy hangolni, hogy concise, high-signal feedback-et adjanak**; a túl bőbeszédű válaszokat ugyanúgy ignorálják, mint a zajos lint warning-okat.

**Mit csinál a mérnök:** az OpenAI-nál az AI code review nagyobb magabiztosságot ad a mérnököknek, hogy nem szállítanak major bug-okat a produkcióba. Gyakran a code review olyan problémákat fog el, amelyeket a contributor korrigálhat, mielőtt egy másik mérnököt bevonna. A code review nem feltétlenül gyorsítja a PR folyamatot (különösen, ha értelmes bug-okat talál) — de megelőzi a defektusokat és az out-age-eket.

- **Delegate vs. Review vs. Own:** az AI code review ellenére a mérnökök továbbra is felelősek azért, hogy a kód kész legyen a szállításra. A gyakorlatban ez a változás implikációinak olvasását és megértését jelenti. A mérnökök delegálják a kezdeti code review-t az agent-nek, de birtokolják a végső review-t és a merge folyamatot.
- **Delegate:** a mérnökök a kezdeti code review-t agent-ekre delegálják — ez többször is megtörténhet, mielőtt a PR-t „ready for review”-nak jelölik.
- **Review:** a mérnökök továbbra is review-ják a PR-eket, de nagyobb hangsúlyt fektetnek az architekturális alignment-re: composable pattern-ek implementálva vannak-e, a helyes konvenciókat használják-e, a funkcionalitás megfelel-e a követelményeknek.
- **Own:** a mérnökök végső soron birtokolják a produkcióba kerülő kódot — biztosítják, hogy megbízhatóan működik és teljesíti a szándékolt követelményeket.

**Példa — Sansan:** a Codex review-t race condition-ökre és adatbázis-relációkra használja, amelyeket emberek gyakran figyelmen kívül hagynak. A Codex improper hard-coding-ot is elkap, és jövőbeli skálázhatósági aggályokat is előre jelez.

**Getting-started checklist:** kurátorolj példákat gold-standard PR-ekről, amelyeket mérnökök végeztek (beleértve a kódváltozásokat és a comment-eket); mentsd el evaluation set-ként a különböző tool-ok méréséhez; válassz egy terméket, amelynek kifejezetten code review-ra tanított modellje van (az OpenAI azt találta, hogy az általánosított modellek gyakran nitpick-elnek és alacsony signal-to-noise ratio-t adnak); definiáld, hogyan méri a csapat a review-k minőségét (ajánlott: PR comment reaction-ök követése alacsony friction-ös good/bad marker-ként); kezdj kicsiben, de rollout gyorsan, amint bizalmat szerzel az eredményekben.

> **Megjegyzés:** a „gold-standard PR-ek mint evaluation set” elv ugyanaz, mint a podcast-processing `eval-golden-dataset.json` (8 → 50 auto-promote-tal bővített synthetic + curated critique példa). A critique agent tanításához a `critique_runner.py` + `data_viewer.py` minta transzferálható.

## Document — Auto-generált doc + AGENTS.md-vel ösztönzött következetesség

**A Probléma:** a legtöbb mérnök-csapat tudja, hogy a dokumentáció le van maradva, de a felzárkózás költséges. A kritikus tudás gyakran egyéneknél van, nem kereshető tudásbázisokban, és a meglévő doc-k gyorsan elavulnak, mert a frissítésük elszakítja a mérnököket a termékmunkától. Még ha a csapatok doc sprint-eket is futtatnak, az eredmény általában egyszeri erőfeszítés, amely a rendszer fejlődésével egyből decay-el.

**Hogyan segít az agent:** a coding agent-ek magasan képesek a kódbázis olvasásán alapuló funkcionalitás-összefoglalásra. Nem csak arról írhatnak, hogy a kódbázis egyes részei hogyan működnek, hanem rendszer-diagramokat generálhatnak (pl. mermaid szintaxissal). Ahogy a fejlesztők feature-öket építenek az agent-ekkel, a dokumentációt is frissíthetik egyszerű promptinggal. Az `AGENTS.md`-vel a dokumentáció-frissítésre vonatkozó utasítások automatikusan beépíthetők minden promptba a konzisztencia érdekében. Mivel a coding agent-ek programozottan futtathatók SDK-n keresztül, release workflow-kba is beépíthetők — pl. az agent review-ja a release-be kerülő commit-okat és összefoglalja a kulcsváltozásokat.

**Mit csinál a mérnök:** a mérnökök a kézzel írt doc-ról átállnak a rendszer formálására és felügyeletére. Eldöntik, hogyan szervezik a doc-okat, hozzáadják a fontos „miért”-et a döntések mögött, világos standard-okat és template-eket állítanak fel az agent számára, és review-ják a kritikus vagy customer-facing darabokat. A munkájuk az lesz, hogy biztosítsák a dokumentáció struktúráját, pontosságát és a delivery folyamatba való integrálását, nem az, hogy maguk gépeljenek mindent.

- **Delegate:** alacsony kockázatú, repetitív munkát teljesen átadunk a Codex-nek: első körös összefoglalók fájlokról és module-okról, alap input/output leírások, dependency list-ek, rövid PR change összefoglalók.
- **Review:** a mérnökök review-ják és szerkesztik a Codex által draftolt fontos doc-okat: core service-ek áttekintése, publikus API és SDK dokumentáció, runbook-ok, architektúra oldalak — mielőtt bármit publikálnak.
- **Own:** a mérnökök maradnak felelősek az átfogó dokumentációs stratégiáért és struktúráért, a standard-okért és template-ekért, amelyeket az agent követ, és minden külső vagy safety-critical dokumentációért (jogi, szabályozási vagy brand kockázat).

**Getting-started checklist:** kísérletezés a dokumentáció-generálással az agent promptolásával; dokumentációs guideline-ok beépítése az `AGENTS.md`-be; workflow-k azonosítása (pl. release cycle-ok), ahol a dokumentáció automatikusan generálható; review a generált tartalom minőségéről, pontosságáról és fókuszáról.

## Deploy & maintain — Logs + commit history a unified context-ben

**A Probléma:** az alkalmazás log-olásának megértése kritikus a software reliability-hez. Incident alatt a software mérnökök log tool-okra, kód-deploy-okra és infra változásokra hivatkoznak a root cause azonosításához. Ez a folyamat gyakran meglepően manuális, és megköveteli a fejlesztőktől, hogy tab-okat váltogassanak a különböző rendszerek között — kritikus percekbe kerül a magas nyomású helyzetekben.

**Hogyan segít az agent:** az AI coding tool-okkal MCP server-eken keresztül hozzáférést adhatsz a logging tool-okhoz a kódbázis kontextusán kívül. Ez lehetővé teszi a fejlesztőknek, hogy egyetlen workflow-ban promptolják a modellt: „nézd meg a hibákat egy adott endpoint-ra” — a modell ezt a kontextust használva bejárja a kódbázist és megtalálja a releváns bug-okat vagy performance issue-kat. Mivel a coding agent-ek CLI tool-okat is használhatnak, a git history-t is megnézhetik, hogy azonosítsák azokat a konkrét változásokat, amelyek a log trace-ekben megjelenő problémákhoz vezethettek.

**Mit csinál a mérnök:** a log-analízis és incident triage fárasztó aspektusainak automatizálásával az AI lehetővé teszi, hogy a mérnökök a magasabb szintű troubleshooting-ra és rendszer-javításra koncentráljanak. Ahelyett, hogy manuálisan korrelálnák a log-okat, commit-okat és infra változásokat, a mérnökök az AI-generálta root cause-ok validálására, reziliens fix-ek tervezésére és preventatív intézkedések fejlesztésére fókuszálnak.

- **Delegate:** sok operatív feladat delegálható agent-ekre — log-ok parse-olása, anomális metrikák felszínre hozatala, gyanús kódváltozások azonosítása, sőt hotfix-ek javaslása.
- **Review:** a mérnökök vetted és finomítják az AI-generálta diagnosztikát, megerősítik a pontosságot, jóváhagyják a remediation lépéseket; biztosítják, hogy a fix-ek megfeleljenek a reliability, security és compliance standard-oknak.
- **Own:** kritikus döntések a mérnököknél maradnak, különösen új incident-eknél, érzékeny produkciós változásoknál, vagy olyan helyzeteknél, ahol a modell magabiztossága alacsony. Az ember marad felelős az ítéletért és a végső sign-off-ért.

**Példa — Virgin Atlantic:** a Codex-et a rendszerek deploy-olásának és karbantartásának erősítésére használja. A Codex VS Code Extension egyetlen helyet ad a mérnököknek a log-ok vizsgálatára, az issue-k kód és adat közötti trace-ére, és a változások review-jára az Azure DevOps MCP és Databricks Managed MCP-n keresztül. Ezt az operatív kontextust az IDE-n belül egységesítve a Codex felgyorsítja a root cause felfedezést, csökkenti a manuális triage-t, és segíti a csapatokat abban, hogy a fix-ek validálására és a rendszer-megbízhatóság javítására fókuszáljanak.

**Getting-started checklist:**

- AI tool-ok csatlakoztatása a logging és deployment rendszerekhez: integráld a Codex CLI-t vagy hasonlót a MCP szervereiddel és log aggregátorokkal.
- Access scope-ok és permission-ök definiálása: biztosítsd, hogy az agent-ek hozzáférjenek a releváns log-okhoz, kód repo-khoz és deployment history-khoz, miközben a security best practice-eket fenntartják.
- Prompt template-ek konfigurálása: hozz létre újrahasználható prompt-okat a gyakori operatív query-khez, pl. „Investigate errors for endpoint X” vagy „Analyze log spikes post-deploy”.
- A workflow tesztelése: futtass szimulált incident scenario-kat, hogy az AI a helyes kontextust hozza felszínre, pontosan trace-elhessen kódot, és actionable diagnosztikát javasoljon.
- Iterálj és javíts: gyűjts visszajelzést valós incident-ekből, hangold a prompt stratégiákat, és bővítsd az agent képességeit, ahogy a rendszereid és folyamataid fejlődnek.

## Következtetés — Small, targeted workflow-k compound-olnak

A coding agent-ek átalakítják az SDLC-t azáltal, hogy átveszik a mechanikus, többlépcsős munkát, amely hagyományosan lassította a mérnökcsapatokat. Sustained reasoning-gal, egységes kódbázis-kontextussal és valódi tool-ok végrehajtásának képességével ezek az agent-ek mostantól a scoping-tól és prototípus-készítéstől az implementáción, tesztelésen, review-n és operatív triage-n át terjedő feladatokat kezelnek. A mérnökök szilárdan az architektúra, termék-intent és minőség kontrolljában maradnak — de a coding agent-ek egyre inkább az első-pass implementerként és folyamatos munkatársként szolgálnak az SDLC minden fázisában.

Ez az eltolódás nem igényel radikális overhault; a kicsi, célzott workflow-k gyorsan compound-olnak, ahogy a coding agent-ek képesebbé és megbízhatóbbá válnak. Azok a csapatok, amelyek jól-scoped feladatokkal kezdenek, invesztálnak a guardrails-be, és iteratívan bővítik az agent felelősségét, értelmes nyereséget látnak a sebességben, konzisztenciában és a fejlesztői fókuszban.

## Saját rendszerünkre alkalmazható tudás (MAGAS alkalmazhatóság)

Az OpenAI guide technikailag konzervatív és azonnal alkalmazható mintákat ad a Hermes / Tollaskígyó + Henky + agent-harness fejlesztésre:

### 1. **AGENTS.md mint first-class CI-kellék**

A guide ötször említi az `AGENTS.md` fájlt (Plan + Build + Test + Review + Document szekciókban), és a „getting started” checklist-ek központi eleme. A `*/SKILL.md` + `AGENTS.md` rendszerünk pontosan ez a minta — a `hermes-agent-skill-authoring` skill formalizálja. Konkrét javaslat: minden skill `SKILL.md` frontmatter-ében tüntesd fel a „trigger feltételek” + numbered steps + pitfalls + verification blokkokat, ahogy a guide ajánlja az agentikus loop-ok (tesztek, linterek) feedback-ciklusához.

### 2. **PLAN.md / PR message-ek agent-generálásra**

A Build szekció checklist-je: „Have the agent use a planning tool via MCP, or by writing a **PLAN.md** file that is committed to the codebase.” A podcast-processing pipeline-ban a `recite-before-answer` lépés (Step 4) ugyanez a minta — a kulcsmondatok kigyűjtése a pipeline előtt. Kiterjesztés: a `concatenate_chunk_summaries.py` mellé egy `plan_chunk_summaries.py` script, amely a chunk-summary-k előtt a transcript-ből PLAN.md-t ír.

### 3. **Tesztek külön session-ben**

A Test szekció explicit guideline-ja: „It can be helpful to have the model generate tests in a separate session from the feature implementation.” A `delegate_task` izolált terminál-session-je pont ezt a mintát valósítja meg — a subagent-ek saját context-ablakkal dolgoznak, és a `failure_modes` nem szennyezi a feature-implementáció session-jét. A `test-driven-development` skill a TDD-t RED-GREEN-REFACTOR mintával formalizálja; az OpenAI guide egy magasabb szintű alkalmazása: a subagent SUMMARY és a subagent TESTS két külön dispatch.

### 4. **Gold-standard PR-ek mint evaluation set**

A Review szekció checklist-je: „Curate examples of gold-standard PRs that have been conducted by engineers including both the code changes and comments left. **Save this as an evaluation set** to measure different tools.” A podcast-processing `eval-golden-dataset.json` (8 → 50 auto-promote-tal bővített synthetic + curated critique példa) pontosan ez a minta. A `critique_runner.py` + `data_viewer.py` + `auto_review.py` hármas ugyanazt a funkciót tölti be a summary-k review-jánál, mint amit az OpenAI a PR review-knál javasol.

### 5. **MCP a unified context-hez**

A Design + Deploy & maintain szekciók hangsúlyozzák az MCP-t a design tool-ok és a logging / deployment rendszerek egységesítésére. A Hermes-ben az **Nostr DM + `tollaskígyó` skill** hasonló szerepet tölt be (a NIP-42 auth + NIP-65 read+write kontextust ad); a **Természetesen a `hermes-agent` skill** a saját CLI-ját + `hermes config set` + `hermes tools` parancsokat adja, mint platform-MCP-t.

### 6. **Generalized model vs. specializált model code review-ra**

A Review szekció explicit figyelmeztetése: „We've found that generalized models often nitpick and provide a low signal to noise ratio.” A podcast-processing `auto_review.py` pont ezt a felismerést tükrözi: a `mock LLM` `estimate_critique_score` heurisztikája explicit `couvre_topics`, `cites_specific_numbers`, `well_structured` checklist-kritériumokra van hangolva, és a `failure_modes` listával jelzi, hogy mely formátum-kritériumok hiányoznak — nem egy általánosított „jó/rossz” címkét ad.

### 7. **Multi-modal coding agent (szöveg + kép)**

A Design szekció checklist-je: „Use a multi-modal coding agent that accepts both text and image input.” A Hermes `vision_analyze` tool pontosan ez — képeket tölt be a kontextusba, és a modell natív képességekkel kezeli. Az X.com hosszú cikkek cover image-éről a `references/article-fallback-vision.md` workflow-ja transzferálható.

### 8. **Specific code coverage tool-ok listája az AGENTS.md-ben**

A Test szekció checklist-je: „Give the agent specific examples of code coverage tools it can call to understand test coverage.” A Hermes skill-ek pontosan ezt a mintát követik — a SKILL.md body-jában a „References” / „linked_files” szekció felsorolja a konkrét script-eket és referenciákat, amelyeket a subagent-ek hívhatnak.

### 9. **„Start small but rollout quickly” + bizalmi küszöb**

A Review + Deploy & maintain szekciók hangsúlyozzák: „Start small but rollout quickly once you gain confidence in the results of reviews” + „Iterate and improve: Collect feedback from real incidents, tune prompt strategies, and expand agent capabilities as your systems and processes evolve.” A `pitfalls-master.md` „broken windows” elve (SOUL.md, Day 40) és a `self-improvement-discipline` (Ren et al. 2026) háromszintű gating-je (parse / scope / robustness) pontosan ugyanez a minta a saját rendszerünkre.

### 10. **PR comment reaction-ök mint low-friction marker**

A Review szekció javaslata: „We recommend tracking **PR comment reactions** as a low-friction way to mark good and bad reviews.” A podcast-processing `human_review_selected=True` + path-hash flag a `data_viewer.py`-ban ugyanez a minta — az emberi review egy explicit boolean flag, nem egy külön dashboard.

## Forrás

- **Cím:** Building an AI-native engineering team — How coding agents accelerate the software development lifecycle
- **Szerző:** OpenAI
- **Kiadás:** 2026 (a METR-adat 2025 augusztusi cutoff-hoz kötött)
- **PDF URL:** https://cdn.openai.com/business-guides-and-resources/building-an-ai-native-engineering-team.pdf
- **Transcript forrás:** pdftotext -layout (poppler 26.07.0), 4044 szó, 749 sor, 19 oldal
- **Feldolgozás módja:** 1 self-write (fő agent) a transcriptből — 4044 szó az 5–7K tartomány alatt van, a `rész-size-decision-table` szerint **0 subagent + 1 self-write** a helyes kiosztás
- **Magyar terminus poszt-processzálás:** alkalmazva (multi-word + single-word + AkH számnév-skála + ASR-hibás nevek)

**Fő szekciók a guide-ban:**
- Introduction (autocomplete → agent evolution, METR-mérés, 4 előfeltétel)
- Plan (issue-tracking + kód-aware scoping)
- Design (multi-modal + MCP a komponenskönyvtárakhoz)
- Build (legnagyobb hatású fázis, multi-step implementáció)
- Test (second-opinion + mindig friss tesztek)
- Review (AI code review a P0/P1 bug-okra hangolva)
- Document (auto-generált doc + AGENTS.md)
- Deploy & maintain (logs + commit history unified context-ben)
- Conclusion (small, targeted workflows compound-olnak)

**Példák a guide-ból:** Cloudwalk (PM/design/operator + Codex mindennapi használat), Sansan (Codex review race condition-ökre és skálázhatósági aggályokra), Virgin Atlantic (Codex VS Code Extension + Azure DevOps MCP + Databricks Managed MCP az IDE-egységes operatív kontextushoz).