Skip to main content

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.

Jag äger mitt område

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

Jag är utförare

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

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

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

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

  1. 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 den.
    Kunde den inte, men planen gjorde den tydlig
    Agenten skriver den.

Leverans

  1. Implementering

    Den som planen valde börjar skriva — jag eller agenten.

  2. Kontroller i dev — agenten

    Agenten kontrollerar, inte jag: den kör flödet genom Playwright eller läser fel direkt från Next.js-dev-servern via MCP. Ingen av min kapacitet går åt här.

  3. Kontroller i build-läge — agenten

    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.

  4. Enhetstester + Playwright

    Först när det verkligen funkar. Enhetstester för logiken, Playwright för flödet — skrivna av agenten de också.

  5. Staging — här kliver jag in

    Första stället jag själv kollar för hand. Lokalt bara när uppgiften är känslig. Sedan går det till QA — i den ordningen, inte tvärtom.

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

  7. Produktion

    Release.

  8. Slutkontroll

    QA i produktion. Håller det — klart.

Grund
  • 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.