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:

Autocomplete — következő sor, függvény-sablon kitöltése (kb. 30 másodperc reasoning, néhány éve)
Chat IDE — pair programming, kód-exploration (rövidebb, irányított)
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.

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).