Individual contributor som builder operator
Den som direkt skapar och driver saker i bolaget. Inte begränsat till ingenjörer. Alla bygger, ops, support, sales. Alla kommer till möten med en fungerande prototyp, inte en pitch deck.
bygger och körOm du slutar tänka på AI som ett tillägg och börjar bygga bolaget som ett intelligent system, växer hastigheten och förmågan med ungefär två tiopotenser. Här är vad det betyder konkret, modul för modul.
Det första du behöver byta är inte verktyg, det är hur du tänker om vad ett bolag är. AI är inte ett tillägg till befintliga flöden, det är skalbenet.
De flesta pratar om AI i termer av produktivitet. Vi behöver lägga in en copilot, vi behöver göra ingenjörerna snabbare, vi behöver skicka fler features. Den framingen missar skiftet. Det handlar mindre om en produktivitetsboost och mer om helt nya förmågor. Rätt person med AI-verktyg kan idag bygga features som tidigare krävde ett helt team eller bara inte gick att bygga alls.
När du börjar tänka på AI i termer av nya förmågor får det flera konsekvenser för hur du driver bolaget. På högsta nivå, AI ska inte vara ett verktyg ditt bolag använder. Det ska vara det operativsystem ditt bolag körs på. Varje flöde, varje beslut, varje process går genom ett intelligent lager som lär sig och blir bättre.
Lägg in copilot i befintliga flöden. Gör ingenjörerna snabbare. Skicka fler features. Effekten är inkrementell.
Bygg om flödena så de går genom ett intelligent lager. En person med tillgång till hela kontexten kan göra det som tidigare krävde ett team.
Produktivitetslinsen är fel lins. Det är inte 20 procent snabbare ingenjörer du jagar. Det är helt nya saker som blir möjliga att bygga, av människor som tidigare inte kunde bygga dem.
Det här betyder konkret att varje viktig process i bolaget ska fångas av ett intelligent closed loop. Ett closed loop tar in information, matar tillbaka den i ett intelligent system, och förbättrar processen över tid. Det är skiftet du ska bygga runt.
Open loops är system utan återkoppling. Closed loops mäter sin egen output och justerar processen. Det är skillnaden mellan ett bolag som glömmer och ett bolag som lär sig.
Har du läst styrteknik eller reglerteknik känner du igen begreppen direkt. Ett open loop är ett styrt system utan feedback. Du fattar ett beslut, du utför det, du mäter inte systematiskt utfallet, du justerar inte processen. Open loops är inneboende lossy, de tappar information längs vägen. Ett closed loop, däremot, är självreglerande. Det övervakar sin egen output och justerar processen för att bättre nå det uppsatta målet.
I den gamla världen kördes bolag i princip som open loops. Beslut, utförande, vidare. Statusrullar uppåt som var super lossy. Med självförbättrande agenter ska ditt bolag istället köras som ett closed loop. Closed loops är extremt kraftfulla för både korrekthet och stabilitet.
| Egenskap | Open loop | Closed loop |
|---|---|---|
| Återkoppling | Ingen systematisk mätning av utfall | Output mäts kontinuerligt och matas tillbaka i processen |
| Information | Lossy, tappar detalj vid varje steg | Rik på artefakter, varje handling lämnar spår |
| Beteende | Statisk, kör samma process tills någon ändrar den | Självreglerande, justerar sig efter målet |
| Korrekthet | Beror på den enskilda människans omdöme | Stabilitet och korrekthet byggs in i systemet |
| Skalning | Skalar genom att lägga till människor | Skalar genom att lägga till intelligens |
Tänk på bolaget som en termostat, inte som en spis. En spis kör sin process oavsett vad som händer i rummet. En termostat mäter, jämför, justerar, om och om igen. Ett AI-native bolag är en termostat med agenter i mitten.
När du har bestämt dig för att closed loop är ramen, blir nästa fråga praktisk. Vad behöver finnas på plats för att loopen ska kunna sluta sig? Svaret är att hela organisationen måste bli läsbar för AI:n i mitten. Det är nästa modul.
För att kunna bygga closed loops behöver hela bolaget bli queryable. Allt viktigt som händer ska lämna en artefakt som intelligensen i mitten kan lära av.
Den övergripande principen är enkel. För att modeller ska kunna ge sin fulla kapacitet behöver du ge dem lika mycket kontext som du skulle ge en anställd. När du gör det, slutar bolaget köras som ett open loop där information är fragmenterad och tolkas manuellt. Det blir istället ett closed loop-system. Status, beslut och utfall fångas kontinuerligt och matas tillbaka in i intelligenslagret. Resultatet är ett system som alltid har en uppdaterad bild av vad som faktiskt händer.
Om en viktig sak händer i bolaget och det inte finns kvar någon artefakt efter den, har du tappat data som loopen behövde för att stänga sig. Bygg som om allt ska kunna queryas av en agent som inte var i rummet.
Det här går mot intuitionen för många team. Det känns som ineffektiv ceremoni i början. Poängen är att artefakterna inte är till för människor, de är näring åt intelligenslagret. Och när intelligenslagret kan se hela bolaget, blir det rapporterna, sammanfattningarna och planerna som tidigare krävde människor med titeln "manager".
Tag engineering management och sprintplanering som ett konkret case. När agenten ser hela kontexten samtidigt händer två saker. Sprintarna blir halverade i tid, output blir närmare 10x.
Här är hur det kan se ut i praktiken. Du har en agent som har access till hela kontexten samtidigt. Då kan den analysera vad som faktiskt skickades i förra sprinten och hur väl det mötte kundernas faktiska behov. Inte vad någon manager rapporterade i rollupen, vad som verkligen hände.
Allt som är planerat, pågående och stängt. Inklusive kommentarer, prioriteringar och hur tickets rört sig genom kolumnerna.
De informella besluten, blockerarna, "förresten, jag tror vi behöver tänka om här", arkitekturdiskussionerna. Det som inte hamnar i tickets men driver vad som faktiskt byggs.
Supportärenden, churn-mejl, feature requests. Det här är signalen om vad kunderna faktiskt försöker göra med produkten.
Vad som har mergeats, vad som ligger i review, vad som är öppet. Tillsammans med diffarna, inte bara titlarna.
Vad var målet med kvartalet, vilka tradeoffs godkändes, vilka principer styr prio. Agenten behöver veta vart bolaget försöker ta sig, inte bara vad som händer just nu.
Säljaren hör saker om kundens kontext som ingenjören aldrig hör. Standup-inspelningar visar var teamet hänger upp sig i realtid. Det här är guld för en agent som ska föreslå nästa sprint.
När agenten har det här kan den gå ett steg längre. Med full visibility över vad som har skickats, vad som fungerade och vad som inte gjorde det, kan den börja titta framåt. Den kan föreslå sprintplaner för ingenjörerna som är dramatiskt mer förutsägbara och precisa, och som faktiskt håller.
Sprinttiden halveras, och man får ut nära 10x mer per sprint. Dagarna med ankarbaserade manager-statusrullar som var super lossy är slut. Det som krävde konstant koordination blir läsbart och queryable som default.
Att ge agenten access till ett par källor och förvänta sig allt. Linear plus GitHub räcker inte. Då sammanfattar agenten det den ser och missar precis det som driver allt resten, kundkontext och informellt resonemang i Slack och säljsamtal.
Den andra fallgropen är att låta sammanfattningarna ersätta detaljen. Agenten ska kunna gå tillbaka till råmaterialet när du frågar varför. Annars har du återskapat ankarbaserad manager-statusrullen, bara med en LLM som speaker.
Plocka ett team, en sprint, en fråga. Till exempel, "vad faktiskt skickade vi förra sprinten och hur väl mötte det det här kvartalets mål?" Ge agenten access till Linear, GitHub, kvartalsplanen och en kanal med kundfeedback. Be om svaret som ett dokument med citat och länkar.
När du ser hur mycket bättre svaret blir än det manager-rapporterade vet du också hur stor lift det är. Skala sen åt sidan ett team i taget, inte allt på en gång.
När du sett det här fungera en gång på riktigt, slutar du tvivla på premissen. Det här är, för team som kört det på riktigt, en gamechanger. Det som tidigare krävde konstant mänsklig koordination blir läsbart och queryable som default.
Det finns ett nytt paradigm för hur bolag med högst velocity bygger mjukvara. Tänk på det som nästa evolution av TDD. Människan skriver spec och tester, agenterna skriver implementationen.
Är du bekant med test-driven development, TDD, kan du se det här som nästa steg. Med en software factory skriver människan en spec och en uppsättning tester som definierar success. Sen genererar AI-agenter implementation och kod, och itererar tills testerna passerar. Människan definierar vad som ska byggas och dömer av outputen. Själva koden är agentens jobb.
Vissa bolag har redan pushat det här så långt att deras repon inte innehåller någon handskriven kod alls, bara specs och test-harnesses. Stronghold är ett exempel på hur det kan göras. Deras slutmål var ett system som i princip eliminerar behovet av att en människa skriver eller granskar kod. För att nå dit byggde de sin egen software factory där specs och scenariobaserade valideringar driver agenter att skriva tester och iterera på koden tills den möter en probabilistisk satisfaction-tröskel, och fungerar.
Spec, design, implementation, tester, review, merge. Varje steg är en människa. Varje växling mellan människor är en lossy överlämning.
Spec och tester är källan till sanning. Agenter skriver, kör, itererar. Människan dömer av output och justerar spec eller test om det behövs.
Du programmerar inte längre datorn med kod, du programmerar agenten med spec och valideringar. Det är där värdet ligger. Att skriva tydliga acceptanskriterier blir den nya "engineering skill".
Det är så du når den tusenfaldiga, eller till och med tiotusenfaldiga, ingenjören som man pratar om. Genom att omge en enskild ingenjör med ett system av agenter som låter den bygga saker som tidigare aldrig hade gått att bygga med ett rimligt headcount. Eran med 1 000x- och 10 000x-ingenjören är inte ett löfte längre, den är här för de team som bestämmer sig för att bygga sin egen factory.
Det här fungerar bäst när du redan har queryable organization från modul 03 på plats. Spec och tester kan automatiseras längre och längre när agenten kan dra kontext från det riktiga bolaget, inte bara från det du orkat skriva ner i prompten.
När du bygger så här, med loops överallt, queryable organization och software factories, slutar den klassiska management-hierarkin att vara meningsfull. Du behöver tre roller, inte sju lager.
I den gamla världen behövde du middle managers och koordinatorer för att routea information ineffektivt upp och ner i organisationen. I den nya världen är det intelligenslagret som har den rollen. Om ditt bolag är queryable, artefaktrikt och läsbart för en AI ska du ha nästan inget human middleware kvar.
Det här spelar roll därför att bolagets velocity bara är så snabb som dess informationsflöde. Varje lager av människor som routear information du tar bort är direkt hastighetsvinst. Behåller du samma org chart och management-struktur, har du missat skiftet helt. Bolaget självt måste byggas om som ett intelligenslager med människor vid kanten som vägleder det, snarare än som något som routar information genom det.
Den som direkt skapar och driver saker i bolaget. Inte begränsat till ingenjörer. Alla bygger, ops, support, sales. Alla kommer till möten med en fungerande prototyp, inte en pitch deck.
bygger och körFokus på strategi och kundutfall. Inte en klassisk manager. Det här är personen med ett tydligt ansvar för ett resultat. En person, ett utfall. Ingen att gömma sig bakom.
äger ett utfallBygger fortfarande, coachar fortfarande, leder genom exempel. Är du grundaren behöver det här vara du i fronten. Du visar teamet hur massiva kapacitetsvinster ser ut. Du delegerar inte AI-strategin till någon annan.
visar i frontenÄr du på väg att lägga till en roll vars enda jobb är att samla information från en grupp och rapportera vidare till en annan grupp, har du just skapat human middleware. Lägg pengarna på tokens istället, och se till att intelligenslagret kan göra samma jobb.
Den här strukturen är inte främst en kostnadsbesparing. Den är en hastighetsöverlägsenhet. Ett bolag som inte behöver vänta på att information ska bubbla genom fem lager innan ett beslut kan tas är ett bolag som rör sig i en annan tempo.
Det kritiska skiftet är inte att maximera headcount, det är att maximera tokenanvändningen. De bästa bolagen är token-maxers. Det betyder, ja, en obekvämt hög API-räkning.
Tänk på trade-offen så här. En person med AI-verktyg kan vara ekvivalenten av vad som tidigare krävde ett stort engineering-team i ett pre-AI-bolag. Det innebär dramatiskt slankare engineering, design, HR och admin. Och därför ska du vara villig att köra en obekvämt hög API-räkning, eftersom den ersätter det som annars hade krävts av ett betydligt dyrare och uppblåst headcount.
| Optimerar för | Gammal modell | Token-maxers |
|---|---|---|
| Tillväxtknapp | Anställ fler | Öka API-budget och bygg fler agentflöden |
| Bästa månadsutgift | Headcount, kontor, verktyg per anställd | Tokens, modeller, compute, finetune |
| När det bränns | Du frågar HR och rekryterar | Du tittar på vilka loops som inte sluter sig och ger agenter mer kontext |
| Smärtgräns | Budget för löner och rekrytering | Obekvämt hög API-räkning som du ändå vet är värd det |
Ett anställningsbeslut är 500 000 till 2 miljoner kronor per år, plus ramp, plus indirekta kostnader. En API-räkning som dubblas är några tiotusen kronor i månaden. Räkna varje gång du tänker "vi behöver anställa någon för det här". Frågan är, kan vi köpa det med tokens istället?
Det här är inte ett argument för att aldrig anställa. Det är ett argument för att default ska vara token, inte människa. Människan ska vara där det krävs omdöme, smak, ansvar, kundkontakt och förhandling. Allt annat, börja med tokens.
Du lägger sex månader på en sökprocess, sex månader på ramp. Ett år senare har du en process som inte är fundamentalt annorlunda än innan, bara med fler munnar.
Du tittar på var artefakter saknas, var agenter inte har kontext, var en spec eller test skulle hjälpa. Sex veckor senare har du ett system, inte en ny anställd.
Du kan inte outsourca conviction om kraften i de här verktygen. Du bygger den själv genom att faktiskt sitta med en coding agent tills dina egna antaganden om vad som är möjligt börjar spricka.
Det viktigaste i hela den här diskussionen är, paradoxalt nog, det du inte kan läsa dig till. Du behöver utveckla övertygelsen själv genom att sitta med kodande agenter och använda dem tills du börjar bryta dina egna förhandsbilder av vad som nu är möjligt att bygga. Ingen annan kan göra det åt dig.
Inte "när jag får tid". Inte "när nästa demo är klar". En fast lucka. Två till fyra timmar. Lägg den i kalendern som ett möte med dig själv.
Inte en demo. Inte en POC du sett tio gånger. Något i ditt riktiga bolag som du tidigare avfärdade som "för stort att ta tag i". Den här gången tar du tag i det med en agent vid sidan.
Skriv ner det. Inte i huvudet, på riktigt. "Jag trodde det här skulle ta tre dagar, det tog tre timmar." "Jag trodde det krävde en ingenjör, jag gjorde det själv." Det är där dina priors spricker.
Är du grundaren ska teamet se hur du jobbar med verktygen. Inte i en e-postsignatur, i en demo. Visa konkret hur en eftermiddag blev till något som tidigare hade krävt en sprint.
Är du tidig fas, har du en enorm fördel i att komma ifatt på det här. Du har inga legacy-system att vrida om. Du har inte tusentals människor att omskola. Du är liten nog att bygga bolaget rätt från dag ett. Designa system, flöden och kultur runt AI från start, och du kan operera 1 000x snabbare än inkumbenterna.
Det omvända gäller för existerande bolag. De ska upprätthålla och växa en levande produkt samtidigt som de avvecklar år av standard operating procedures och kärngrundsantaganden om hur mjukvara byggs. Vissa lyckas genom att starta små interna skunk works-team som bygger AI-native system från scratch, skilt från kärnverksamheten. Men för de flesta innebär varje förändring av kärnprocesser en risk att bryta något som redan fungerar. Av sin natur har stora bolag mycket svårare att bli AI-native.
Startups har inte den begränsningen. Och det är en betydande edge att utnyttja. Du kan designa system, flöden och kultur runt AI från start, och som ett resultat operera tusen gånger snabbare än inkumbenterna. Men ingen kan ge dig övertygelsen om det. Du måste sitta ned med verktygen, idag, och se det själv.
Tre frågor som testar att de viktigaste principerna sitter. Klicka på det svar du tror är rätt. Du får direkt feedback.
Bra. Du har de viktigaste delarna på plats.
Nu vet du vad ett closed-loop-bolag faktiskt är, hur du gör organisationen läsbar för AI, och varför nästa anställning kanske inte ska vara en anställning alls. Det som händer nu beror på vad du gör i morgon.
Onsdagar. Kort, lågmält, på svenska. Ett mejl i veckan från någon som faktiskt sitter med verktygen och bygger.
Onsdagar. Under 5 minuters läsning. Inga skräpmejl. Du kan när som helst avregistrera dig.