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

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 anställer dem och tyst föraktat alla som påstår att de är en sådan.

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

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

Det är inte 10x; det är närmare 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, skyddsräcken, valideringslooparna, gränssnitten som agenter ansluter till och som människor granskar genom.

Jag tror att detta är framväxten av en ny nyckelfunktion i utvecklingsorganisationer. Jag skulle kalla det AI-Orkestreringsutveckling.

Three Disciplines Walk Into a Standup

Om du tittar på vad en AI-Orkestreringsutvecklare 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-Orkestreringsutveckling gör samma sak, men för agentarbetsflöden. Det definierar hur uppgifter tilldelas agenter, hur utdata valideras, hur omförsök 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 kanske tror. 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äl dokumenterade kodbas med tydliga kontrakt. AI-Orkestreringsutvecklaren definierar dessa begränsningar, inte bara för mänsklig läsbarhet, utan för agentfö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-engineering, kontextshantering, modellval, agentkonfiguration. Idag gör de flesta utvecklare detta på ett spridd, uppgift-för-uppgift-sätt. Varje person figurerar ut sin egen prompt-stil, sin egen agentuppställning, sina egna lösningar. AI-Orkestreringsutvecklaren centraliserar detta. De bygger de delade playbook, 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 Metaphor

En filmregissör opererar inte kameran, agerar i scenerna eller redigerar materialet. Men varje bildruta 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 levereras.

AI-Orkestreringsutveckling fungerar på samma sätt. Agenterna ä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äkningskraft, 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-Orkestreringsutvecklaren gör samma sak för agentflottan.

Varför de flesta organisationer underinvestera

Här är vad jag ser över hela 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 planar ut på “fancy autocomplete”-stadiet. De 20% produktivitetsvinster som studierna rapporterar? Det är symtomet på verktygsnivåanvändning utan systemnivåtänkande.

Organisationerna 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.

Vad rollen faktiskt ser ut som

En AI-Orkestreringsutvecklares dag-till-dag kan inkludera:

• Att designa agentarbetsflöden: definiera hur en funktionsbegäran blir en spec, blir en plan, blir parallella agentuppgifter, blir granskad och sammanfogad kod.
• Att bygga valideringsinfrastruktur: automatiserade tester, linter-regler, säkerhetsskanningar och utvärderingsramverk som agenter måste passera innan deras arbete får sammanfogas.
• Att 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.
• Att centralisera prompt- och kontextstrategier: delade systemprompt, hämtningspipelor, modellroutningsbeslut och konfigurationsmallar som hela teamet använder.
• Att övervaka och förbättra agentprestanda: spåra framgångsgrader, felmoder, kostnad per uppgift och tid-till-sammanfogning över agentflottan, sedan finjustera systemet baserat på data.

Den här personen sitter i 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önstret

I molnberäkningens tidiga dagar var distribution varje utvecklares sido-uppdrag. 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äningsinfrastruktur.

AI följer samma bana. Just nu är agentanvändning varje utvecklares sido-uppdrag. Varje person har sin egen prompt-stil, sina egna verktygspreferenser, sin egen mental modell för när AI hjälper och när den inte gör det. Organisationerna 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-praktiker överträffade de som saknade.

Skillnaden är hastighet. DevOps-omvandlingen tog ett decennium. Den här kan ta kvartal. även om jag kommer att medge 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, här är 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 vänder sig till för råd om prompting eller verktygsuppställning. Den personen är din proto-AI-Orkestreringsutvecklare.
2. Gör det explicit. Ge funktionen ett namn, ett mandat och resurser. Låt det inte förbli ett sido-projekt som är fäst vid 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 en persons 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 omarbetsfrekvenserna ser ut som, var flaskhalsarna är.

Den nya 10x

Myten om 10x-utvecklaren var 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 10 gånger så mycket kod. De bygger systemet som skriver den.

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 organisationerna som figurerar ut orkestreringslagret (oavsett vad de kommer att kalla det) kommer att vara de som faktiskt förverkligar produktivitetsvinster som alla andra bara pratar om.