Uusi 10x-insinööri ei kirjoita 10-kertaista koodia, vaan rakentaa järjestelmän, joka kirjoittaa sen.

10x-insinööri on ollut Silicon Valley -myytti vuosikymmenien ajan. Yksinäinen neropatti, kuulokkeet päässä, massatuottaa eleganttia koodia yliluonnollisella nopeudella. Olemme kiistäneet siitä, onko heitä olemassa, väitelty siitä, miten heidät voi palkata, ja hiljaisesti vihannet niitä, jotka väittävät olevansa yksi.

Mutta jotain mielenkiintoista tapahtui matkalla kohti AI-ensin-tulevaisuutta: 10x-insinööri tuli tosi. He vain näyttävät aivan erilaisilta kuin mitä olemme kuvitelleet.

OpenAI jakoi äskettäin, miten kolmen hengen tiimi käytti Codexia toimittamaan 1 500 pull-pyyntöä ja noin miljoona riviä koodia ilman, että heidän tarvitsi kirjoittaa yhtään riviä käsin. Kolme insinööriä ja nolla käsin kirjoitettua koodia. Tuotanto, jota käytti satoja sisäisiä käyttäjiä.

Se ei ole 10x, vaan lähemmäs 100x. Ja se taito, joka mahdollisti sen, ei ollut kirjoittaa nopeammin tai tietää enemmän algoritmeja. Se oli rakentaa järjestelmä, joka tekee AI-agenteista tuottavia: työvirrat, varmistuslenkit, verkkorakenteet, joihin agentit liittyvät ja ihmiset tarkastelevat.

Uskon, että tämä on uuden avainfunktion nousu insinööriorganisaatioissa. Kutsuisin sitä AI-ohjausinsinööriksi.

Kolme kurssia menee standupiin

Jos tuijotat, mitä AI-ohjausinsinööri tekee, tunnistat kolme tuttua kurssia yhdistyneenä.

Ilmeisin ainesosa on DevOps. DevOps keskitti julkaisuputken. Yksi tiimi konfiguroi CI/CD-työvirrat, joita jokainen insinööri käytti koodin toimittamiseen. AI-ohjausinsinööri tekee saman asian, mutta agenttityövirroille. Se määrittää, miten tehtävät määrätään agenteille, miten tulokset validoidaan, miten uudelleenkäynnistykset ja varmistuslenkit toimivat. Se on jaettu infrastruktuuri, jolla agentit toimivat.

Sitten on arkkitehtuuri, joka limittyy DevOpsiin enemmän kuin odotat. Arkkitehdit päättävät, mitkä rajapinnat ovat lukittuja, mitkä mallit ovat pakollisia, mitkä rajat eivät voi ylittää. Agenttimaailmassa tämä on vielä tärkeämpää. Agentit tarvitsevat puhdasta, hyvin dokumentoituja koodikokoelmia selkeillä sopimuksilla. AI-ohjausinsinööri määrittää nämä rajoitukset, ei vain ihmisten lukemiseksi, vaan myös agenttien ymmärtämiseksi. Sotkuinen varasto ei ole enää vain tekninen velka, vaan myös agenttien tuottavuuden katto.

Vähiten ymmärretty osa on AI-erityinen kerros. Ohjelmistosuunnittelu, kontekstin hallinta, mallin valinta, agentin konfiguraatio. Tänään useimmat insinöörit tekevät tämän hajanaisesti, tehtävästä toiseen. Jokainen keksii oman ohjelmointityylinsä, oman agenttiasetuksensa, oman kiertotiensä. AI-ohjausinsinööri keskittää tämän. He rakentavat jaettuja pelikirjoja, uudelleenkäytettäviä konfiguraatioita, organisaation tietämyksen siitä, mitä toimii ja mitä ei toimi eri malleissa ja käyttötarkoituksissa.

Erillään nämä kolme toimintoa ovat olemassa useimmissa insinööriorganisaatioissa tänään. Argumentti on, että yhdistämällä ne yhteen, keskitettyyn rooliin, luodaan jotain laadullisesti erilaista.

Ohjaajan metafora

Elokuvaohjaaja ei käytä kameraa, näyttele elokuvassa tai leikkaa kuvamateriaalia. Mutta jokainen kuva heijastaa heidän päätöksiään.

He valitsevat kohtauksen sommitelman, tahdin, tunnelman. He päättävät, milloin lähennellä ja milloin vetäytyä kauemmaksi. He järjestävät ympäristön (valaistus, lavastus, blokkaus) siten, että jokainen henkilö kuvauksissa voi tehdä parhaan työnsä yhtenäisen visioin. Ryhmä on yksilöllisesti lahjakkaita, mutta ilman koordinointia saadaan sotku, joka ei koskaan valmistu.

AI-ohjausinsinööri toimii samalla tavalla. Agentit ovat kykeneviä. Mallit ovat voimakkaita. Mutta ilman ketään, joka suunnittelee järjestelmän, joka koordinoi niitä, määrittää rajoitukset, rakentaa palautuslenkit, rakentaa työvirrat, saadaan se, minkä me kaikki olemme kokeneet: epäjohdonmukaiset tulokset, haaskattu laskenta, agentit toimivat ristiriitaisesti, ja insinöörit käyttävät enemmän aikaa korjaamaan AI-luotujen koodin kuin he olisivat kirjoittaneet sen itse.

Ohjaaja tekee elokuvan, joka on suurempi kuin sen osien summa. AI-ohjausinsinööri tekee saman agenttien laivastolle.

Miksi useimmat organisaatiot investoivat liian vähän

Tässä on, mitä näen teollisuudessa: yritykset investoivat voimakkaasti AI-työkaluihin eivätkä tarpeeksi järjestelmiin, jotka ympäröivät niitä.

Insinöörit saavat pääsyn Copilottiin, Claudeen, Codexiin. He kokeilevat yksin. Jotkut tulevat voimakkaiksi käyttäjiksi. Useimmat jäävät “hienon autocomplete”-vaiheeseen. 20 %:n tuottavuusparannukset, joita tutkimukset jatkuvasti raportoivat? Se on oire työkalutasolla tapahtuvasta omaksumisesta ilman järjestelmätasolla tapahtuvaa ajattelua.

Organisaatiot, jotka murtavat läpi, ne, jotka raportoivat 2-kertaista tai suurempaa tuottavuutta, ovat yhtä. He ovat keskittäneet ohjaustyön. Joku (tai joku tiimi) omistaa agenttityövirrat, varastojen valmistelun, verifioimisinfrastruktuurin, jaetun kontekstin, johon jokainen agentti pääsee käsiksi.

Millainen rooli todella on

AI-ohjausinsinöörin päivittäinen työ saattaa sisältää:

• Agenttityövirtojen suunnittelua: määrittelyä siitä, miten toimintopyyntö muuttuu määritykseksi, muuttuu suunnitelmaksi, muuttuu rinnakkaisiksi agenttitehtäviksi, muuttuu tarkastettavaksi ja yhdistettäväksi koodiksi.
• Varmistusinfrastruktuurin rakentamista: automaattisia testejä, linttausohjeita, tietoturvatarkastuksia ja arviointikehyksiä, jotka agenteille on läpäistävä ennen kuin heidän työnsä voidaan yhdistää.
• Varastojen terveyden ylläpitämistä agenttien kulutukseen: dokumentaatiota, selkeitä rajapintoja, riippuvuuksien hallintaa ja koodin yksinkertaistamista, kaikkea optimoitu agenttien ymmärtämiseksi, ei vain ihmisten lukemiseksi.
• Ohjelmistojen ja kontekstien keskittämistä: jaettuja järjestelmäohjelmia, hakuputkia, mallin reitityspäätöksiä ja konfiguraatiomalleja, joita koko tiimi käyttää.
• Agenttien suorituskyvyn seuraamista ja parantamista: seuraamista siitä, miten paljon tehtäviä agenteille on, miten paljon epäonnistumisia on, kustannuksia tehtävittäin, ja aikaa yhdistämiseen, ja sitten säätämistä järjestelmää perustuen tietoihin.

Tämä henkilö istuu platform-tekniikan, ohjelmistosuunnittelun ja AI-asiantuntemuksen risteyksessä. He eivät kirjoita ominaisuuksia. He rakentavat järjestelmän, joka tekee ominaisuuksien toimittamisen nopeaksi, luotettavaksi ja skaalautuvaksi.

Historiallinen malli

Pilvilaskennan alkuaikoina jokainen insinööri teki oman sivutehtävänsä. Jokainen tiimi oli omassa maailmassaan. DevOps kehittyi keskittämään tämän työn, ja platform-tekniikka kehittyi rakentamaan siitä jaettua, itsepalvelupohjaista infrastruktuuria.

AI seuraa samaa kaarta. Tällä hetkellä agenttien käyttö on jokaisen insinöörin sivutehtävä. Jokainen henkilö on omassa maailmassaan. Joku on keksinyt oman ohjelmointityylinsä, oman agenttiasetuksensa, oman kiertotiensä. Organisaatiot, jotka keskittävät tämän, jotka käsittelevät sitä infrastruktuurina eivätkä yksilöllisenä kokeiluna, vetävät eteenpäin samalla tavalla kuin organisaatiot, joilla on kypsät DevOps-käytännöt, ohittavat ne, joilla ei ole.

Ero on nopeus. DevOps-siirtymä kesti vuosikymmenen. Tämä saattaa kestää vain neljännesvuosia. Vaikka myönnän, että tämä ennuste olettaa, että organisaatiot tunnistavat mallin nopeammin kuin he yleensä tekevät.

Eteenpäin

Jos olet insinöörijohtaja, tässä on, mitä ehdottaisin, vaikka matka voi vaihdella riippuen siitä, kuinka pitkällä tiimisi on jo:

1. Tunnista, kuka tekee jo tätä työtä epävirallisesti. Jokaisessa organisaatiossa on joku, joka on keksinyt agenttityövirrat, johon muut insinöörit menevät neuvoa ohjelmoinnista tai työkalujen asetuksesta. Se henkilö on proto-AI-ohjausinsinööri.
2. Tee se viralliseksi. Anna sille nimi, määräysvalta ja resursseja. Älä anna sen jäädä sivutehtäväksi, joka on kiinni jossakin toisessa “oikeassa” työssä.
3. Aloita varastojen valmistelusta. Ennen kuin investoit monimutkaisiin agenttityövirtoihin, varmista, että koodikokoelmasi on sellainen, jonka agentit voivat todella navigoida. Puhdasta rajapintaa, hyvää dokumentaatiota, kattavia testejä, yksinkertaista arkkitehtuuria.
4. Keskitä se, mikä toimii. Kun joku keksii ohjelmointistrategian tai työvirran, joka parantaa merkittävästi agenttien tuotoksia, kaappa se. Tee siitä oletusarvo koko tiimille, äläkä jätä sitä yhden henkilön pään sisään.
5. Mittaa järjestelmän tasolla. Älä seuraa vain yksittäisten työkalujen käyttöä. Mittaa, kuinka monta tehtävää agenteille on, miten paljon tarkastelua ja uudelleen työtä on, missä pullonkaulat ovat.

Uusi 10x

10x-insinöörin myytti oli aina yksilöllisistä sankareista. Yksi henkilö, joka ylittää jokaisen muun yliluonnollisen kykynsä ja kahvin ansiosta.

Todellisuus 10x-insinööristä AI-aikakaudella on järjestelmäajattelua. Se henkilö, joka tekee jokaisen muun insinöörin (ja jokaisen agentin) tuottavammaksi rakentamalla oikean infrastruktuurin, oikeat työvirrat, oikeat rajoitukset.

He eivät kirjoita 10-kertaista koodia. He rakentavat järjestelmän, joka kirjoittaa sen.

En ole varma, tuleeko tämä rooli kiteytyä täsmälleen siten, kuin olen kuvannut tässä. Mutta olen melko varma, että organisaatiot, jotka keksivät orkestraatiokerroksen (riippumatta siitä, mitä he lopulta sitä kutsuvat), ovat ne, jotka todella toteuttavat tuottavuusparannukset, joista kaikki muut puhuvat.