Den nya 10x-utvecklaren skriver inte 10 gånger så mycket kod. De bygger systemet som skriver det.

10x-utvecklaren har varit en Silicon Valley-myth i decennier. Den ensamma geniet, med hörlurar på, producerar elegant kod i övermänsklig hastighet. Vi har debatterat om de existerar, diskuterat hur man rekryterar dem och tyst föraktat alla som påstår att de är en.

Men något intressant hände på vägen till AI-framtid: 10x-utvecklaren blev verklig. De ser bara inte ut som vi föreställt oss.

OpenAI delade nyligen hur ett trepersoners team använde Codex för att leverera 1 500 pull requests och ungefär en miljon rader kod, utan att skriva en enda rad manuellt. Tre utvecklare och noll manuell kod. En produkt som används av hundratals interna användare.

Det är inte 10x, det är snarare 100x. Och den färdighet som gjorde det möjligt var inte att skriva snabbare eller känna till fler algoritmer. Det var att bygga systemet som gör AI-agenter produktiva: arbetsflödena, skyddsbarriärerna, valideringslooparna, gränssnitten som agenter ansluter till och som människor granskar.

Jag tror att detta är början på en ny nyckelfunktion i utvecklingsorganisationer. Jag skulle kalla det AI-orchestreringsutveckling.

Tre discipliner går in i en standup

Om du tittar på vad en AI-orchestreringsutvecklare faktiskt gör, kommer du att känna igen tre bekanta discipliner som smälts samman till en.

Den mest uppenbara ingrediensen är DevOps. DevOps centraliserade distributionspipelinen. Ett team konfigurerade CI/CD-arbetsflödena som varje utvecklare använde när de skickade kod. AI-orchestreringsutveckling gör samma sak, men för agentarbetsflöden. Det definierar hur uppgifter tilldelas agenter, hur utdata valideras, hur omstarter och fallback-funktioner fungerar. Det är den delade infrastrukturen som agenter körs på.

Sedan finns det arkitektur, som överlappar med DevOps mer än du skulle förvänta dig. Arkitekter bestämmer vilka gränssnitt som är låsta, vilka mönster som tillämpas, vilka gränser som inte kan korsas. I en agent-baserad värld är detta viktigare än någonsin. Agenter behöver rena, väldokumenterade kodbasen med tydliga kontrakt. AI-orchestreringsutvecklaren definierar dessa begränsningar, inte bara för mänsklig läsbarhet, utan för agentens förståelse. En rörig repo är inte bara teknisk skuld längre. Det är en produktivitetsgräns för varje agent som rör vid den.

Den minst förstådda delen är det AI-specifika lagret. Prompt-teknik, kontextshantering, modellval, agentkonfiguration. Idag gör de flesta utvecklare detta på ett utspritt, uppgift-för-uppgift-sätt. Varje person kommer på sin egen prompt-stil, sin egen agentkonfiguration, sina egna lösningar. AI-orchestreringsutvecklaren centraliserar detta. De bygger de delade playbooken, de återanvändbara konfigurationerna, den organisatoriska kunskapen om vad som fungerar och vad som inte fungerar över modeller och användningsfall.

Separat finns dessa tre funktioner i de flesta utvecklingsorganisationer idag. Argumentet är att kombinera dem till en enda, centraliserad roll skapar något kvalitativt annorlunda.

The Showrunner-metoden

En filmregissör opererar inte kameran, spelar inte i scenerna eller redigerar materialet. Men varje bildram reflekterar deras beslut.

De väljer kompositionen, takten, tonen. De bestämmer när de ska zooma in och när de ska dra ut. De ställer in miljön (belysning, scenografi, blockering) så att varje person på sett kan göra sitt bästa arbete inom en sammanhängande vision. Teamet är individuellt begåvat, men utan den samordningen, får du en röra som aldrig skickas.

AI-orchestreringsutveckling fungerar på samma sätt. Agenter är kapabla. Modellerna är kraftfulla. Men utan någon som designar systemet som samordnar dem, definierar begränsningarna, bygger återkopplingslooparna, strukturerar arbetsflödena, får du vad vi alla har upplevt: inkonsekventa utdata, slösad beräkning, agenter som arbetar i korsande syften och utvecklare som tillbringar mer tid med att fixa AI-genererad kod än de skulle ha tillbringat med att skriva den själva.

Regissören gör en film som är större än summan av dess delar. AI-orchestreringsutvecklaren gör samma sak för agentflottan.

Varför de flesta organisationer underinvestera

Här är vad jag ser i branschen: företag investerar kraftigt i AI-verktyg och inte nästan tillräckligt i systemen runt dem.

Utvecklare får tillgång till Copilot, Claude, Codex. De experimenterar individuellt. Några blir kraftanvändare. De flesta når en platå vid “fancy autocomplete”-stadiet. De 20% produktivitetsvinster som studierna rapporterar? Det är symtomet på verktygsnivåadoption utan systemnivåtänkande.

De organisationer som bryter igenom, de som rapporterar 2x eller större genomströmning, har något gemensamt. De har centraliserat orkestreringsarbetet. Någon (eller något team) äger agentarbetsflödena, repo-förberedelsen, valideringsinfrastrukturen, den delade kontexten som varje agent kan komma åt.

hur rollen faktiskt ser ut

En AI-orchestreringsutvecklares dag-till-dag kan innehålla:

• Designa agentarbetsflöden: definiera hur en funktionsbegäran blir en spec, blir en plan, blir parallella agentuppgifter, blir granskad och sammanfogad kod.
• Bygga valideringsinfrastruktur: automatiserade tester, lint-regler, säkerhetsskanningar och utvärderingsramverk som agenter måste passera innan deras arbete sammanfogas.
• Underhålla repo-hälsa för agentkonsumtion: dokumentation, tydliga gränssnitt, beroendehantering och kodbasförenkling, allt optimerat för agentförståelse, inte bara mänsklig läsbarhet.
• Centralisera prompt- och kontextstrategier: delade systemprompt, hämtningspipeliner, modellroutningsbeslut och konfigurationsmallar som hela teamet använder.
• Övervaka och förbättra agentprestanda: spåra framgångsgrader, felmodus, kostnad per uppgift och tid-till-sammanfogning över agentflottan, sedan justera systemet baserat på data.

Den här personen sitter vid skärningspunkten mellan plattformsutveckling, programvaruarkitektur och AI-expertis. De skriver inte funktioner. De bygger systemet som gör funktionsleverans snabb, tillförlitlig och skalbar.

Den historiska mönster

I molntjänstens tidiga dagar var distribution varje utvecklares sidouppgift. Varje team hade sina egna skript, sina egna serverkonfigurationer, sitt eget sätt att få kod i produktion. DevOps uppstod för att centralisera det arbetet, och plattformsutveckling utvecklades för att bygga det till delad, självbetjänande infrastruktur.

AI följer samma bana. Just nu är agentanvändning varje utvecklares sidouppgift. Varje person har sin egen prompt-stil, sin egen verktygspreferens, sin egen mental modell för när AI hjälper och när det inte gör det. De organisationer som centraliserar detta, som behandlar det som infrastruktur snarare än individuell experiment, kommer att dra ifrån på samma sätt som organisationer med mogna DevOps-praxis överträffade de som saknade.

Skillnaden är hastighet. DevOps-omvandlingen tog ett decennium. Den här kan ta kvartal. även om jag medger att den förutsägelsen antar att organisationer känner igen mönstret snabbare än de vanligtvis gör.

Vägen framåt

Om du är en utvecklingsledare, så är detta vad jag skulle föreslå, även om din miljö kommer att variera beroende på hur långt ditt team redan har kommit.

1. Identifiera vem som redan gör det här arbetet informellt. Varje organisation har någon som har figurerat ut agentarbetsflödena, som andra utvecklare går till för råd om prompt eller verktygsinställning. Den personen är din proto-AI-orchestreringsutvecklare.
2. Gör det explicit. Ge funktionen ett namn, ett mandat och resurser. Låt det inte förbli ett sidoprojekt som är knutet till någons “riktiga” jobb.
3. Börja med repo-beredskap. Innan du investerar i sofistikerade agentarbetsflöden, se till att din kodbas är något som agenter faktiskt kan navigera. Rena gränssnitt, bra dokumentation, omfattande tester, förenklad arkitektur.
4. Centralisera vad som fungerar. När någon upptäcker en prompt-strategi eller arbetsflödesmönster som dramatiskt förbättrar agentutdata, fånga det. Gör det till standard för hela teamet, inte stamkunskap låst i någons huvud.
5. Mät på systemnivå. Spåra inte bara individuell verktygsanvändning. Spåra hur många uppgifter agenter slutför från början till slut, vad gransknings- och omgöringsfrekvenserna ser ut, var flaskhalsarna är.

Den nya 10x

Myten om 10x-utvecklaren handlade alltid om individuella hjältedåd. En person, som överträffar alla andra genom ren talang och koffein.

Verkligheten om 10x-utvecklaren i AI-eran handlar om systemtänkande. Personen som gör varje annan utvecklare (och varje agent) mer produktiv genom att bygga rätt infrastruktur, rätt arbetsflöden, rätt begränsningar.

De skriver inte 10x så mycket kod. De bygger systemet som skriver det.

Jag är inte säker på att den här rollen kommer att kristallisera exakt som jag har beskrivit den här. Men jag är ganska säker på att de organisationer som figurerar ut orkestreringslagret (oavsett vad de kommer att kalla det) kommer att vara de som faktiskt realiserar produktivitetsvinster som alla andra bara pratar om.