Az AI Engineer YouTube‑csatorna elérte az egymillió feliratkozót; ebből az alkalomból a csatorna házigazdája, swyx, Mihail Eric‑et (Stanford adjunktus, aki a The Modern Software Developer, CS146S kurzust tanítja, és ugyanakkor a Monaco mesterséges intelligencia részlegét vezeti) kérdezte arról, mit kell ma megtanulnia egy szoftvermérnöknek.
A kurzus háttere és célja
Mihail elmondása szerint a kurzus a 2024 novemberében felmerült ötlet után alakult meg, és az első félévnyi oktatás a 2025‑ös őszi félévben indult. A 146S, The Modern Software Developer tízhetes programként épül fel: célja nem az alap algoritmusok megtanítása, hanem azoknak a gyakorlati, termelési környezetben használt módszereknek a bemutatása, amelyek az AI‑native fejlesztésben ma döntőek.
A kurzus kifejezetten arra számít, hogy a résztvevők már rendelkeznek egy alap CS‑készlettel (algoritmusok, adatszerkezetek), és a fókusz a nagy kódalapok, kontextuskezelés és az ügynök‑hajtású munkafolyamatok megtanítása.
Házifeladat: nyílt forráskódú hozzájárulások és valós feladatok
A kurzus egyik fontos újítása, hogy a hallgatók feladatai közé bekerült nyílt forráskódú projektekhez való hozzájárulás. A diákok által készített patch‑eket a projekt fenntartói vizsgálják át: ez a gyakorlat rákényszeríti a hallgatókat arra, hogy ne csak automatizált eszközöket futtassanak, hanem megtanuljanak kommunikálni egy maintainerrel, megértsék a projekt szándékát és a lehetséges regressziókat. Mihail szerint ez a mentori tanulás fontos része annak, hogy junior mérnökök „senior szintű” gondolkodásmódot sajátítsanak el gyorsabban.
A kurzus gyakorlataiból említésre került Geoffrey Litt explain‑diff készsége is, amely egy diff‑változást vizuálisan jár be, majd kvízszerűen ellenőrzi a megértést — jó gyakorlat a mesterségesen előállított módosítások megértésére.
A kurzus tíz heti tematikája (összefoglalva)
- Week 1: Az ügynökök belső működése, egyszerű „harness” felépítése (például Claude Code‑szerű loop bemutatása, 200 sor körüli példakód).
- Week 2: Context engineering skálázhatóan; eszköztervezés és MCP‑szerű szabványok.
- Week 3: Skills (eljárások/szkriptek) és azok automatizálása.
- Week 4: Testreszabás (configok, hooks, alügynökök).
- Week 5: Agent‑ready kódbázisok — hogyan tegyük a repót fogyaszthatóvá ügynökök számára (dokumentáció, verifikálhatóság, szolgáltatási határok).
- Week 6: Ügynök‑vezérelt kódellenőrzés; a kódreview mint szűk keresztmetszet és verifikálási stratégiák.
- Week 7: Biztonság — új támadási felületek és függőségek kezelése.
- Week 8: Background agents — ügynökök, amelyek eseményekre vagy CI/CD‑re reagálnak, hosszabb futású folyamatok.
- Week 9: Csapat‑szintű infrastruktúra (LM Gateway‑ek, MCP Portálok, platform‑szerepek).
- Week 10: A szoftver‑gyár (software factory) koncepciója, ember‑ügynök határok, mit hagyunk humánnak.
Mihail hangsúlyozza, hogy egyes témák még nem konszolidáltak, de a «context engineering», a verifikálhatóság és az agent‑ready tervezés már tartós elveknek tűnnek.
Mit csinál Monaco — vásárlás kontra házon belüli fejlesztés
Monaco csapata több kódellenőrző terméket tesztelt és végül Devin (Cognition) mellett döntött több használati esetnél. Ugyanakkor háttér‑ügynökök futtatására és a helyi felhőstruktúrához igazodó munkakörnyezetekre szükségük volt, ezért saját workspacokat építettek. Mihail képlete: „you buy to learn, and you build to keep” — azaz vásárolnak eszközöket a tanulási fázisban, de akkor építenek saját megoldást, ha hosszú távon kell integrálni és fenntartani.
Monaco belső fejlesztései közül említették Hal nevű rendszert: ez egyszerre használható hibakeresésre (ingeniőr kérdezi meg, mi tört el, és PR‑t nyit), illetve értelmezésre (értékesítő megtudja, hogyan működik egy funkció). Mihail kiemelte, hogy ugyanaz a nyers hibakeresési kimenet nem szolgálja jól mindkét célcsoportot — másfajta összefoglalás/levonás kell a vevőszolgálati/értékesítési célokra.
Monaco továbbá belső background agent platformot (Monocoder, Coder alapokon) és speciális harness‑okat használ a hosszú és rövid horizontú GTM (go‑to‑market) ügynökökhöz.
Kódellenőrzés, sebesség és a review mint szűk keresztmetszet
Több beszélgetés és mérés is azt jelzi, hogy ahol az AI nagyon megnöveli a kódgenerálás sebességét, ott a hagyományos kódreview válik bottlenecké. Mihail és a vendégszerzők is a «mi engedhető automatikus jóváhagyásra és mi nem» kérdésre fókuszálnak: mit lehet automatikusan elfogadtatni, milyen verifikációk és tesztek szükségesek, és milyen módon változik a review szerepe (line‑by‑line helyett specifikáció‑ és verifikáció‑központú ellenőrzés).
A kurzusban statisztikákra is hivatkoznak: a magas AI‑felhasználású csapatok több PR‑t merge‑elnek, de a review‑idő növekedhet; emiatt új megoldásokra, verifikálási technikákra és eszközökre van szükség.
Biztonság és függőségek
A hét a biztonságról a használati esetek és az új támadási felületek miatt fontos: a hallgatók kapnak áttekintést a supply‑chain és dependency‑kockázatokról, függőség‑pinelésről és arról, miért lehet bizonyos helyzetekben biztonságosabb (de nem feltétlenül jobb) önálló, házon belüli megoldásokat írni. Mihail felhívta a figyelmet, hogy a sebezhetőségek természetükben változhatnak, és az AI‑szintű fejlesztés más típusú hibákat hozhat a felszínre.
Többügynökös rendszerek, alügynökök és kontextuskezelés
A több alügynököt alkalmazó megközelítésekben a kontextus menedzsment összetett problémává válik: milyen információ öröklődjön az alügynökbe, mikor kell «kompaktálni» a kontextust, hogyan kezeljük a felnagyuló prompt‑méreteket. Az elosztott munkavégzésnél a mérnököknek stratégiákat kell kialakítaniuk a kontextus felfuttatása és karbantartása körül, különösen, ha review‑ügynök felügyel több munkafolyamatot.
A szoftver‑gyár (software factory) gondolata
Mihail és a beszélgetés résztvevői szerint az ügynök‑vezérelt fejlesztés egyik logikus iránya a „szoftver‑gyár”: agentek által nagy arányban generált és karbantartott kód, ahol az emberi szerep inkább intent‑meghatározásra, verifikációra és felügyeletre szorítkozik. Ugyanakkor a jelenlegi példák alapján még messze vagyunk a teljesen „sötét” (embertől mentes) gyáraktól; sok csapat 20–30%‑os autonómiáról vagy folyamatokra épülő hibrid megoldásokról beszél.
Tanácsok diákoknak és tanároknak
Mihail hangsúlyozta a kísérletezés fontosságát (napi 10 perc új eszközök kipróbálására), a nyílt forráskódú hozzájárulások hasznát mentorálással együtt, valamint a mérési, benchmark‑ és eval‑munka értékét — ezek jól látható eredményt és esetleges karrierlehetőséget hoznak.
Következtetés
A beszélgetésben Mihail Eric összekapcsolta az egyetemi oktatást és a termelési tapasztalatot: a CS146S kurzus célja, hogy a diákok gyakorlati, AI‑native készségeket szerezzenek — különösen a kontextuskezelés, agent‑readiness és verifikálható kódalkotás területén — míg Monaco példája megmutatja, hogyan lehet a „vásárlás a tanulásért, építés a megtartásért” logikát alkalmazni egy AI‑hajtású termékfejlesztésben.
A témák — a kódreview mint szűk keresztmetszet, a háttérügynökök infrastruktúrája, a biztonság és a szoftver‑gyár koncepciója — mind azt jelzik, hogy az ipar átállása nemcsak eszközök (modellek) kérdése, hanem architektúrák, munkafolyamatok és szervezeti szerepek újragondolása is.
(Összefoglaló a Mihail Eric‑szal készült YouTube‑interjú alapján; a beszélgetés részletes időbélyegzőivel és forrásanyagokkal a webes kiadásban találhatók.)
