Den nye 10x-ingeniør skriver ikke 10 gange så meget kode. De bygger systemet, der skriver det.

10x-ingeniøren har været en Silicon Valley-myte i årtier. Den enlige genius, med hovedtelefoner på, producerer elegant kode i overmenneskelig hastighed. Vi har diskuteret, om de eksisterer, diskuteret, hvordan man ansætter dem, og stille resenteret enhver, der påstår at være en.

Men noget interessant skete på vejen til den AI-første fremtid: 10x-ingeniøren blev virkelig. De ser bare ikke ud, som vi forestillede os.

OpenAI delte nylig, hvordan et tre-mands hold brugte Codex til at afsende 1.500 pull-requests og omtrent en million linjer kode, uden at skrive en enkelt linje manuelt. Tre ingeniører, og ingen håndskrevne kode. Et produkt i produktion brugt af hundredvis af interne brugere.

Det er ikke 10x; det er nærmere 100x. Og den færdighed, der gjorde det muligt, var ikke at taste hurtigere eller kende mere om algoritmer. Det var at bygge systemet, der gjorde AI-agenter produktive: workflows, guardrails, verifikationsløkker, interfaces, som agenter kan tilslutte sig og mennesker kan gennemgå.

Jeg tror, dette er opkomsten af en ny nøglefunktion i ingeniørorganisationer. Jeg ville kalde det AI-Orkestreringsingeniør.

Three Disciplines Walk Into a Standup

Hvis du kigger på, hvad en AI-Orkestreringsingeniør faktisk gør, vil du genkende tre velkendte discipliner, der er fusioneret til en.

Det mest åbenlyse ingrediens er DevOps. DevOps centraliserede deployments-pipeline. Ét hold konfigurerede CI/CD-workflows, som hver ingeniør brugte, når de afsendte kode. AI-Orkestreringsingeniør gør det samme, men for agent-workflows. Det definerer, hvordan opgaver bliver tildelt agenter, hvordan outputs bliver valideret, hvordan retries og fallbacks fungerer. Det er den fælles infrastruktur, som agenter kører på.

Så er der arkitektur, som overlapper med DevOps mere, end man ville tro. Arkitekter beslutter, hvilke interfaces er låst, hvilke mønstre er gennemført, hvilke grænser ikke kan krydses. I en agent-først-verden betyder det endnu mere. Agenter har brug for rene, vel-dokumenterede kodebaser med klare kontrakter. AI-Orkestreringsingeniøren definerer disse begrænsninger, ikke kun for menneskelig læsbarhed, men for agent-forståelse. En rodet repository er ikke kun teknisk gæld mere. Det er en produktivitetsloft for hver agent, der rører det.

Det mindst forståede stykke er det AI-specifikke lag. Prompt-engineering, kontekststyring, modelvalg, agentkonfiguration. I dag gør de fleste ingeniører dette på en spredt, opgave-for-opgave-måde. Hver person finder ud af deres egen prompt-stil, deres egen agent-opstilling, deres egen workaround. AI-Orkestreringsingeniøren centraliserer dette. De bygger de fælles playbooks, de genbrugelige konfigurationer, den organisatoriske viden om, hvad der virker og hvad der ikke gør, på tværs af modeller og brugsområder.

Separat eksisterer disse tre funktioner i de fleste ingeniørorganisationer i dag. Argumentet er, at kombinationen af dem i en enkelt, central rol skaber noget kvalitativt anderledes.

The Showrunner Metaphor

En filminstruktør opererer ikke kameraet, spiller ikke i scenerne eller klipper ikke billederne. Men hver enkelt frame reflekterer deres beslutninger.

De vælger kompositionen af billedet, pacingen, tonen. De beslutter, hvornår de skal trykke ind og hvornår de skal trække tilbage. De sætter op miljøet (belysning, scene-design, blocking), så hver person på settet kan gøre deres bedste arbejde inden for en koherent vision. Crewet er individuelt talentfuldt, men uden den koordination, får man en rodet, der aldrig afsendes.

AI-Orkestreringsingeniør arbejder på samme måde. Agenterne er kapable. Modellerne er kraftfulde. Men uden nogen, der designer systemet, der koordinerer dem, definerer begrænsningerne, bygger feedback-løkkerne, strukturerer workflows, får man det, vi alle har oplevet: inkonsistente outputs, spildt compute, agenter, der arbejder i modsætning til hinanden, og ingeniører, der bruger mere tid på at fikse AI-genereret kode, end de ville have brugt på at skrive det selv.

Instruktøren gør filmen større end summen af dets dele. AI-Orkestreringsingeniøren gør det samme for agent-flåden.

Why Most Organizations Are Underinvesting

Her er, hvad jeg ser på tværs af industrien: virksomheder investerer massivt i AI-værktøjer og ikke nær nok i systemerne omkring dem.

Ingeniører får adgang til Copilot, Claude, Codex. De eksperimenterer individuelt. Nogle bliver power-brugere. De fleste når plateauet på “fancy autocomplete”-stadiet. De 20% produktivitetsgevinster, som studierne konstant rapporterer? Det er symptom på værktøjsniveau-adoption uden systemniveau-tænkning.

Virksomhederne, der bryder igennem, dem, der rapporterer 2x eller større gennemløb, har noget til fælles. De har centraliseret orkestreringsarbejdet. Nogen (eller et team) ejer agent-workflows, repository-forberedelse, verifikations-infrastruktur, den fælles kontekst, som hver agent kan tilgå.

What the Role Actually Looks Like

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

• Design af agent-workflows: definition af, hvordan en funktionanmodning bliver en spec, bliver en plan, bliver parallelle agent-opgaver, bliver gennemgået og merged kode.
• Bygning af verifikations-infrastruktur: automatiserede tests, linting-regler, sikkerhedsskanninger og evalueringssystemer, som agenter må gå igennem, før deres arbejde bliver merged.
• Vedligeholdelse af repository-sundhed til agent-forbrug: dokumentation, klare interfaces, afhængighedsstyring og kodebase-forenkling, alt optimeret til agent-forståelse, ikke kun menneskelig læsbarhed.
• Centralisering af prompt- og kontekst-strategier: fælles system-prompts, hentnings-rørledninger, model-valgbeslutninger og konfigurations-templat, som hele teamet bruger.
• Overvågning og forbedring af agent-præstation: sporing af succes-rater, fejlmoder, omkostninger pr. opgave og tid-til-merge på tværs af agent-flåden, derefter justering af systemet baseret på data.

Denne person sidder på skæringen af platform-ingeniørarbejde, software-arkitektur og AI-ekspertise. De skriver ikke funktioner. De bygger systemet, der gør funktion-levering hurtig, pålidelig og skalerbar.

The Historical Pattern

I de tidlige dage af cloud-computing var deployment hver ingeniørs side-opgave. Hvert team havde deres egne scripts, deres egne server-konfigurationer, deres egen måde at få kode i produktion på. DevOps opstod for at centralisere dette arbejde, og Platform-ingeniørarbejde udviklede sig til at bygge det ind i fælles, selvbetjent infrastruktur.

AI følger den samme bue. Lige nu er agent-brug hver ingeniørs side-opgave. Hver person har deres egen prompt-stil, deres egne værktøjs-præferencer, deres egen mental model for, hvornår AI hjælper og hvornår det ikke gør. Virksomhederne, der centraliserer dette, der behandler det som infrastruktur snarere end individuel eksperimentering, vil trække foran på samme måde, som virksomheder med modne DevOps-praksis overhalede dem uden.

Forskellen er hastighed. DevOps-overgangen tog et årti. Denne kan tage kvartaler. selvom jeg vil indrømme, at denne forudsigelse antager, at virksomheder erkender mønsteret hurtigere, end de normalt gør.

The Path Forward

Hvis du er en ingeniørleder, her er, hvad jeg ville foreslå, selvom din kilometer-værdi vil variere afhængigt af, hvor langt dit team allerede er.

1. Identificér, hvem der allerede gør dette arbejde uofficielt. Hver virksomhed har nogen, der har figureret ud, hvordan agent-workflows, hvem andre ingeniører går til for råd om prompting eller værktøjs-opstilling. Den person er din proto-AI-Orkestreringsingeniør.
2. Gør det eksplicit. Giv funktionen et navn, en mandat og ressourcer. Lad det ikke forblive et side-projekt knyttet til nogen “rigtig” job.
3. Start med repository-klarhed. Før du investerer i avancerede agent-workflows, sikr dig, at din kodebase er noget, agenter kan faktisk navigere. Rene interfaces, god dokumentation, omfattende tests, forenket arkitektur.
4. Centraliser, hvad der virker. Når nogen opdager en prompt-strategi eller workflow-mønster, der dramatisk forbedrer agent-output, fang det. Gør det til standarden for hele teamet, ikke stamme-viden låst i én persons hoved.
5. Mål på systemniveau. Sporet ikke kun individuel værktøjs-brug. Sporet, hvor mange opgaver agenter gennemfører fra ende til anden, hvad gennemløbs- og omarbejdningssatserne ligner, hvor flaskehalsene er.

The New 10x

Myten om 10x-ingeniøren var altid om individuel heroisme. En person, der overgår alle andre gennem ren talent og koffein.

Realiteten om 10x-ingeniøren i AI-æraen handler om systemtænkning. Personen, der gør hver anden ingeniør (og hver agent) mere produktiv ved at bygge den rigtige infrastruktur, de rigtige workflows, de rigtige begrænsninger.

De skriver ikke 10 gange så meget kode. De bygger systemet, der skriver det.

Jeg er ikke sikker på, at denne rolle vil krystallisere præcis, som jeg har beskrevet det her. Men jeg er ret sikker på, at virksomhederne, der figurerer ud orkestrerings-laget (uanset, hvad de ender med at kalde det), vil være dem, der faktisk realiserer produktivitetsgevinsterne, som alle andre kun taler om.