Hur en uppgift blir produktion
Så arbetar jag faktiskt 2026: varje uppgift passerar först två filter — kan manuellt arbete undvikas helt och kan skrivandet snabbas upp — och når koden först därefter. Nedan hela kedjan, steg för steg.
Förutsättning — ägare eller utförareFiltret fungerar bara när jag äger mitt område
Promova byggde om mitt sätt att tänka: inte bara vara utvecklare, utan validera varje uppgift som når mig. Inte ”hur bygger jag det här” utan ”vad gör det för affären”. Det filtret fungerar dock bara under ett villkor.
Uppgiften går genast genom filtret. Jag svarar för resultatet, så jag har rätten att säga ”det här borde inte byggas alls” eller ”det här borde inte jag bygga”.
Inget filter. Det finns en uppgift, en deadline och en leverans. Inget fel med det — det är helt enkelt ett annat avtal.
Skillnaden är inte skicklighet, utan mandat. En självständig enhet som helt äger sitt område kostar företaget mindre än en utförare — för den bygger inte det onödiga.
Före koden
En uppgift kommer in
Jag börjar inte med ”hur bygger jag det här”. Första frågan är vad det gör för affären; den andra om det över huvud taget måste byggas för hand, av mig.
Filter ett — går allt handarbete att undvika?
Tre utvägar, och alla tre svarar på en fråga: vem gör det här hädanefter. Tar uppgiften någon av dem slutar den vara min, och min kapacitet står fri för arbete som verkligen behöver en utvecklare.
utgångar ur pipelinen- Agenten sköter det
Ställs in en gång och kommer aldrig tillbaka till någon. Därefter kör en agent och slutför den helt på egen hand, utan någon inblandning.
Automatisk kodgranskning · analytics hamnar direkt i en egen Slack-kanal i stället för att dra loggar för hand
- Beställaren sköter det
Uppgiften når mig aldrig. Den som behöver den gör den själv tillsammans med AI — min del är att bygga vägen en gång.
Outreach-utskick · influencer-plattform
- Teamet sköter det
En funktion eller plugin insydd i systemet, där teamet gör ändringarna själv — utan ticket, utan utvecklare.
Redirect-plugin i CMS:et som SEO-teamet äger
Filter två — snabba upp själva skrivandet
Uppgiften klarade filter ett, alltså är den min. Nästa fråga: är det rutin i kodtermer? Om mönstret upprepas — knappstilar, en återkommande struktur — skriver jag först en skill för det och sedan koden. Längre en gång, snabbare varje gång sedan.
Beslut
Plan mode — analys före en enda rad
Jag måste leva mig igenom koden, inte få den. Planen avgör vem som skriver den.
- Jag kan inte den här koden
- Jag skriver den själv.
- Jag kan den här koden
- Agenten skriver, jag granskar varje diff — här vet jag hur korrekt kod ser ut.
- Kunde den inte, men planen gjorde den tydlig
- Nu kan jag den. Agenten skriver, jag stämmer av rad för rad mot planen.
Leverans
Implementering
Den som planen valde börjar skriva — jag eller agenten. Oavsett vilket går inget vidare förrän jag läst diffen.
Kontroller i dev — automatiserade
Agenten driver kontrollerna: den kör flödet genom Playwright eller läser fel direkt från Next.js-dev-servern via MCP. Det går utan tillsyn — jag läser vad den rapporterar och avgör vad som händer sedan.
Kontroller i build-läge
Dev ljuger. Andra chunks, andra optimeringar, annat beteende. Något som funkar i dev och dör i build är en klassiker, så build får sitt eget svep — återigen drivet av agenten, och återigen läst av mig.
Enhetstester + Playwright
Först när det verkligen funkar. Enhetstester för logiken, Playwright för flödet — utkastet skrivs av agenten, sedan granskar och rättar jag.
Staging — mitt eget svep
Ett medvetet svep för hand innan någon annan ser det. Lokalt bara när uppgiften är känslig. Sedan går det till QA — i den ordningen, inte tvärtom.
Pull request
Granskas av agenter med de skills som äger den zonen av projektet: en prestandaändring prövas mot prestandareglerna, en betalningsändring mot betalningsreglerna.
Produktion
Release.
Slutkontroll
QA i produktion. Håller det — klart.
- OOP
- SOLID
- DRY
- KISS
- YAGNI
- CI/CD
Genom att kunna de arkitektoniska metoderna och hålla stegens ordning går det att skriva kod snabbt och bra på samma gång. Farten kommer ur ordningsföljden, inte ur snabbare knapptryck.
Expertis i en specifik teknik ger alltid bättre kod — det är inte upp till diskussion. Men den överförs inte: byter du stack börjar du om. Förståelsen för utvecklingsflödet, för arkitektur och för principer överförs helt. Det är den som gör det möjligt att arbeta i en kodbas du ännu inte kan: plan mode (steg 04) visar hur just det här projektet är byggt, och att bedöma om en lösning är rätt kan du redan.