Den nye 10x-ingeniøren skriver ikke 10 ganger så mye kode. De bygger systemet som skriver det.

10x-ingeniøren har vært en Silicon Valley-myte i tiår. Den enlige geniet, med hodetelefoner på, produserer elegant kode i overmenneskelig hastighet. Vi har diskutert om de eksisterer, argumentert om hvordan man rekrutterer dem, og stille resentert noen som hevder å være en av dem.

Men noe interessant skjedde på veien til en AI-drevet fremtid: 10x-ingeniøren ble virkelig. De ser bare ikke ut som vi forestilte oss.

OpenAI delte nylig hvordan et tre-manns team brukte Codex til å levere 1 500 pull-forespørsler og omtrent en million linjer med kode, uten å skrive en enkelt linje manuelt. Tre ingeniører, og null håndskrevet kode. Et produksjonsprodukt brukt av hundrevis av interne brukere.

Dette er ikke 10x; det er nærmere 100x. Og ferdigheten som gjorde det mulig var ikke å taste raskere eller å kjenne til flere algoritmer. Det var å bygge systemet som gjorde AI-agenter produktive: arbeidsflytene, sikkerhetsmekanismene, verifiseringslukene, grensesnittene som agenter kobler til og mennesker gjennomgår.

Jeg tror dette er fremveksten av en ny nøkkelrolle i ingeniørorganisasjoner. Jeg ville kalle det AI-Orkestreringsingeniør.

Tre disipliner går inn i en standup

Hvis du ser på hva en AI-Orkestreringsingeniør faktisk gjør, vil du gjenkjenne tre kjente disipliner som er sammenslått til en.

Det mest åpenbare ingrediensen er DevOps. DevOps sentraliserte deployeringspipelinen. Én team konfigurerte CI/CD-arbeidsflytene som hver enkelt ingeniør brukte når de leverte kode. AI-Orkestreringsingeniør gjør det samme, men for agent-arbeidsflyter. Det definerer hvordan oppgaver blir tildelt agenter, hvordan utdata blir verifisert, hvordan retry og fallback fungerer. Det er den felles infrastrukturen som agenter kjører på.

Så er det arkitektur, som overlapper med DevOps mer enn du ville tro. Arkitekter bestemmer hvilke grensesnitt som er låst, hvilke mønster som er pålagt, hvilke grenser som ikke kan krysses. I en agent-drevet verden betyr dette enda mer. Agenter trenger rene, veldokumenterte kodebaserte grensesnitt med klare kontrakter. AI-Orkestreringsingeniøren definerer disse begrensningene, ikke bare for menneskelig lesbarhet, men for agent-forståelse. En rotete repo er ikke bare teknisk gjeld, men en produktivitetsgrense for hver agent som berører den.

Det minst forståtte delen er AI-spesifikke laget. Prompt-ingeniørarbeid, kontekststyring, modellvalg, agentkonfigurasjon. I dag gjør de fleste ingeniører dette på en spredt, oppgave-til-oppgave-måte. Hver person finner ut sin egen prompt-stil, sin egen agentoppsett, sin egen workaround. AI-Orkestreringsingeniøren sentraliserer dette. De bygger de felles playbookene, de gjenbrukbare konfigurasjonene, den organisatoriske kunnskapen om hva som fungerer og hva som ikke fungerer over modeller og brukstilfeller.

Separat eksisterer disse tre funksjonene i de fleste ingeniørorganisasjoner i dag. Argumentet er at å kombinere dem i en enkelt, sentral rolle skaper noe kvalitativt annerledes.

Showrunner-metoden

En filmregissør opererer ikke kameraet, spiller ikke i scenene eller klipper ikke sammen filmen. Men hver enkelt rame reflekterer deres beslutninger.

De velger komposisjonen av bildet, tempoen, tonen. De bestemmer når de skal zoome inn og når de skal trekke ut. De setter opp miljøet (lys, sett-design, blokkering) så hver person på settet kan gjøre sitt beste arbeid innenfor en samlet visjon. Mannskapet er individuelt talentfulle, men uten den koordineringen, får du en rot som aldri leveres.

AI-Orkestreringsingeniørarbeid fungerer på samme måte. Agentene er kapable. Modellene er kraftfulle. Men uten noen som designer systemet som koordinerer dem, definerer begrensningene, bygger tilbakekoblingslukene, strukturerer arbeidsflytene, får du hva vi alle har erfart: inkonsistente utdata, bortkastet beregning, agenter som arbeider i mot hverandre, og ingeniører som tilbringer mer tid på å fikse AI-generert kode enn de ville ha tilbrakt på å skrive den selv.

Regissøren gjør en film større enn summen av delene. AI-Orkestreringsingeniøren gjør det samme for agent-flåten.

Hvorfor de fleste organisasjoner underinvesterer

Her er hva jeg ser over hele industrien: selskaper investerer tungt i AI-verktøy og langt fra nok i systemene rundt dem.

Ingeniører får tilgang til Copilot, Claude, Codex. De eksperimenterer individuelt. Noen blir kraftbrukere. De fleste når plateauet på “fancy autocomplete”-stadiet. De 20% produktivitetsgevinstene som studier hele tiden rapporterer? Det er symptomet på verktøynivå-tilpasning uten systemnivå-tenkning.

Organisasjonene som bryter gjennom, de som rapporterer 2x eller større gjennomstrømming, har noe til felles. De har sentralisert orkestreringsarbeidet. Noen (eller noen team) eier agent-arbeidsflytene, repository-forberedelsen, verifiseringsinfrastrukturen, den felles konteksten som hver enkelt agent kan aksessere.

Hva rollen faktisk ser ut som

En AI-Orkestreringsingeniørs dag-til-dag-arbeid kan inkludere:

• Design av agent-arbeidsflyter: definere hvordan en funksjonsforespørsel blir en spesifikasjon, blir en plan, blir parallele agent-oppgaver, blir gjennomgått og slått sammen kode.
• Bygging av verifiseringsinfrastruktur: automatiserte tester, lint-regler, sikkerhetsskanninger og evalueringssystemer som agenter må bestå før deres arbeid blir slått sammen.
• Vedlikehold av repository-helse for agent-forbruk: dokumentasjon, klare grensesnitt, avhengighetsstyring og kodebase-forenkling, alt optimalisert for agent-forståelse, ikke bare menneskelig lesbarhet.
• Sentralisering av prompt- og kontekst-strategier: felles system-prompts, henting-pipelines, modell-rutingsbeslutninger og konfigurasjonsmal som hele teamet bruker.
• Overvåking og forbedring av agent-ytelse: sporing av suksessrater, feilmoduser, kostnad per oppgave og tid-til-sammenligning over agent-flåten, og deretter justering av systemet basert på data.

Denne personen sitter i skjæringspunktet mellom plattform-ingeniørarbeid, programvare-arkitektur og AI-ekspertise. De skriver ikke funksjoner. De bygger systemet som gjør funksjonslevering rask, pålitelig og skalerbar.

Den historiske mønster

I de tidlige dagene av skytjenester var deployering hver enkelt ingeniørs sideoppdrag. Hvert team hadde sine egne skript, sine egne server-konfigurasjoner, sine egne måter å få kode inn i produksjon på. DevOps oppstod for å sentralisere dette arbeidet, og plattform-ingeniørarbeid utviklet seg til å bygge det inn i felles, selvbetjent infrastruktur.

AI følger samme bue. Nå er agent-bruk hver enkelt ingeniørs sideoppdrag. Hver person har sin egen prompt-stil, sine egne verktøy-preferanser, sin egen mentale modell for når AI hjelper og når det ikke gjør. Organisasjonene som sentraliserer dette, som behandler det som infrastruktur i stedet for individuell eksperimentering, vil trekke foran på samme måte som organisasjoner med modne DevOps-praksiser overgikk de uten.

Forskjellen er hastighet. DevOps-overgangen tok et tiår. Denne kan ta kvartaler. selv om jeg vil innrømme at denne forutsigelsen antar at organisasjoner gjenkjenner mønsteret raskere enn de vanligvis gjør.

Veien fremover

Hvis du er en ingeniørleder, her er hva jeg ville foreslå, selv om din kilometeravstand vil variere avhengig av hvor langt ditt team allerede er.

1. Identifiser hvem som allerede gjør dette arbeidet uoffisielt. Hvert selskap har noen som har funnet ut agent-arbeidsflytene, som andre ingeniører går til for råd om prompting eller verktøyoppsett. Den personen er din proto-AI-Orkestreringsingeniør.
2. Gjør det eksplisitt. Gi funksjonen et navn, et mandat og ressurser. La det ikke forbli et sideprosjekt knyttet til noen “ekte” jobb.
3. Start med repository-klarhet. Før du investerer i sofistikerte agent-arbeidsflyter, sikre deg at din kodebase er noe agenter faktisk kan navigere. Rent grensesnitt, god dokumentasjon, omfattende tester, forenklet arkitektur.
4. Sentraliser hva som fungerer. Når noen oppdager en prompt-strategi eller arbeidsflyt-mønster som dramatisk forbedrer agent-utdata, fange det. Gjør det til standard for hele teamet, ikke stamme-kunnskap låst i en persons hode.
5. Mål på systemnivå. Sporet ikke bare individuell verktøybruk. Sporet hvor mange oppgaver agenter fullfører fra ende til ende, hva gjennomgangs- og omarbeidingsrater ser ut til, hvor flaskenakken er.

Den nye 10x

Myten om 10x-ingeniøren var alltid om individuelle heltebedrifter. En person, overgående alle andre gjennom ren talent og kaffe.

Realiteten om 10x-ingeniøren i AI-æraen er om systemtenkning. Personen som gjør hver enkelt annen ingeniør (og hver enkelt agent) mer produktiv ved å bygge riktig infrastruktur, riktige arbeidsflyter, riktige begrensninger.

De skriver ikke 10 ganger så mye kode. De bygger systemet som skriver det.

Jeg er ikke sikker på at denne rollen vil krystallisere nøyaktig som jeg har beskrevet den her. Men jeg er ganske sikker på at organisasjonene som finner ut orkestreringslaget (uansett hva de ender opp med å kalle det) vil være de som faktisk realiserer produktivitetsgevinstene alle andre bare snakker om.