Két történet ugyanazon a héten látott napvilágot, és a legtöbben külön fogják olvasni őket. Az egyik az elbocsátásokról szól. A másik egy biztonsági kutatóról, aki szerveralaplapokat vizsgál. Együtt olvasva egy olyan karrierváltásra mutatnak rá, amely a jelenlegi, MI-készségekről szóló párbeszédben szinte egyáltalán nem kap figyelmet: lefelé haladni a stackben, nem felfelé.

Az alkalmazási réteg szándékosan egyre zsúfoltabb

A Meta belépése az ügynökalapú kódolásba, a Muse Code, kevésbé az mögötte álló modell, mint inkább az automatizált munkafolyamat miatt figyelemre méltó. Zuckerberg úgy írta le, hogy „különálló, párhuzamosan dolgozó alügynökökre osztja szét a feladatot elszigetelt worktree-kben”, és azt állította, hogy egy tesztfuttatás során hat funkciót épített meg egyszerre egy játékhoz, ütközések nélkül. Ez mára alapkövetelmény: az Anthropic, az OpenAI és startupok egész sora már ugyanezt különböző változatokban kínálja. Az alkalmazási réteg kódjának megtervezése, megírása és validálása nagy kódtárakban árucikké váló képesség, amelyet több szolgáltató is igyekszik ingyenesen vagy olcsón, csomagban elérhetővé tenni.

Eközben a Monday.com nagyjából 20%-kal, mintegy 600 fővel csökkentette a munkaerő-állományát, a termékhez és a piacra lépéshez kapcsolódó „átalakuláshoz” kötött átszervezésre hivatkozva. Ezzel csatlakozott ahhoz a több mint 20 vállalatot számláló listához, amelyek idén az MI-t is a leépítések egyik tényezőjeként említették. Senki sem tudja pontosan megmondani, ebből mekkora rész az MI általi kiváltás, és mekkora rész az MI mint kényelmes indok egy SEC-beadványban. A haladás iránya azonban mindkét történetben ugyanaz: pontosan azt a kódot építik az ügynökalapú eszközök teljes körű kezelésére, amely git-repóban él, PR-ben vizsgálják felül, és normál CI-folyamatban fut.

Amihez az ügynökök nem nyúlnak hozzá

És most a másik történet. A kutatók ezen a héten olyan eredményeket mutattak be, amelyek szerint jelentős gyártók több ezer internethez kapcsolódó szerverét lehet távolról hátsó ajtóval ellátni a baseboard management controllerekben (BMC-kben) található hibákon keresztül — ezek azok az apró, beágyazott számítógépek, amelyek gyakorlatilag minden vállalati alaplapon megtalálhatók, és lehetővé teszik a rendszergazdák számára egy gép újraindítását, javítását vagy újraimage-elését akkor is, amikor az ki van kapcsolva. Az e vezérlők által használt IPMI-protokoll mögöttes hibái közül néhány legalább 2013 óta ismert. A kutatók a BMC-infrastruktúrát „mindenütt jelen lévő, alulmonitorozott, aluljavított párhuzamos támadási felületnek” nevezték — nem azért, mert senki sem tudott a kockázat létezéséről, hanem mert szinte senki sem kapott erőforrást a kijavítására.

Ez árulkodó. Ez nem alkalmazáskód. Firmware-ről van szó, amely saját operációs rendszert és hálózati stacket futtat, és nagyrészt láthatatlan az ügynökalapú kódolási asszisztensekre szabott eszközök és munkafolyamatok számára. Egy nagy repóra PR-t tervező ügynöknek itt nincs mit megterveznie — nincs repó, nincs tesztkészlet, gyakran nincs gyártói ösztönző a gyors javítás kiadására, és a javítási folyamat a hardvergyártókon keresztül zajlik, nem egy `git push` révén. A fontos készségek — a beágyazott C, a protokollszintű hibakeresés, a firmware visszafejtése, a hardverközeli biztonsági kutatás — a stack olyan részén helyezkednek el, amelyet a jelenlegi generációs kódoló ügynökök nem tudnak elérni, és amelybe a legtöbb mérnöki szervezet krónikusan alul fektetett be; ezt bizonyítják az évtizedes, ismert hibák.

A kikötés, világosan megfogalmazva

Ez nem felszólítás arra, hogy minden fejlesztő képezze át magát firmware-mérnökké — ez egy szűk piac, és a kereslet nem fogja felvenni a versenyt a mainstream szoftveres szerepkörökkel. Az állítás szűkebb: ha a jelenlegi szereped egyértelműen a stack azon részén található, amely felé az ügynökalapú eszközök a leggyorsabban közelednek — rutinszerű alkalmazáskód, egyetlen repón belül, jól lefedve tesztekkel —, akkor érdemes tudnod, hogy léteznek szomszédos, alacsonyabb szintű rétegek, ahová az automatizálás határvidéke még nem érkezett meg, ahol a készségek megtanulhatók CS-doktori fokozat nélkül, és ahol a kereslet jele (egy évtizedes, javítatlan támadási felület, amelyet most nyilvánosan, nagy léptékben demonstráltak) szokatlanul kézzelfogható.

Hol kezdj hozzá ténylegesen ebben a hónapban

  • Olvasd el az elsődleges kutatást, ne csak az összefoglalót. Az Ars Technica beszámolója megnevezi a protokollt (IPMI) és a hardver kategóriáját (a nagy szervergyártók BMC-i) — ez legyen a kiindulópontod a gyártói biztonsági közleményekhez és a CVE-előzményekhez használható keresőkifejezésekhez.
  • Szerezz gyakorlati tapasztalatot egy nyílt BMC-stackkel. Az OpenBMC és a hasonló nyílt forráskódú firmware-projektek lehetővé teszik, hogy valódi BMC-kódot olvass és módosíts adatközpont nélkül is — egy hétvége elegendő annak megtapasztalásához, mennyire más ez a web- vagy alkalmazásfejlesztéshez képest.
  • Fogalmazd át most az önéletrajzod nyelvezetét, még az átképzés előtt. Az „out-of-band menedzsment”, a „lights-out adminisztráció” és az „operációs rendszer alatti támadási felület” azok a kifejezések, amelyek révén megtalálnak majd az erre a területre munkatársakat kereső csapatok, és semmibe sem kerül hozzáadni őket, ha a tapasztalat valóban kapcsolódik ahhoz, amit eddig csináltál.
  • Kezeld diverzifikációként, ne pályamódosításként. Továbbra is szállíts alkalmazáskódot — ez még mindig a munkaerőpiac nagy része —, de a tanulási kereted egy tudatosan meghatározott részét fordítsd olyan területre, ahová egy ügynök még nem tud worktree-kbe szétoszlani, hogy aztán helyetted kijavítsa.