Skip to main content

Hvordan en oppgave blir produksjon

Slik jobber jeg faktisk i 2026: hver oppgave går først gjennom to filtre — kan manuelt arbeid unngås helt, og kan skrivingen gjøres raskere — og når koden først etterpå. Under følger hele kjeden, steg for steg.

Forutsetning — eier eller utførerFilteret virker bare når jeg eier mitt område

Promova bygde om måten jeg tenker på: ikke bare være utvikler, men validere hver oppgave som når meg. Ikke «hvordan bygger jeg dette» men «hva gjør det for forretningen». Men det filteret virker bare under én betingelse.

Jeg eier mitt område

Oppgaven går straks gjennom filteret. Jeg svarer for resultatet, så jeg har tyngden til å si «dette bør ikke bygges i det hele tatt» eller «dette bør ikke jeg bygge».

Jeg er utfører

Ingen filter. Det finnes en oppgave, en frist og en leveranse. Ingenting galt med det — det er rett og slett en annen avtale.

Forskjellen er ikke ferdighet, men mandat. En selvstendig enhet som fullt ut eier sitt område koster selskapet mindre enn en utfører — fordi den ikke bygger det unødvendige.

Før koden

  1. En oppgave kommer inn

    Jeg starter ikke med «hvordan bygger jeg dette». Første spørsmål er hva det gjør for forretningen; det andre er om det i det hele tatt må bygges for hånd, av meg.

  2. Filter én — kan alt håndarbeid unngås?

    Tre utveier, og alle tre svarer på ett spørsmål: hvem gjør dette fra nå av. Tar oppgaven en av dem, slutter den å være min, og kapasiteten min blir stående fri til arbeid som faktisk trenger en utvikler.

    utganger fra pipelinen
    • Agenten gjør det

      Settes opp én gang og kommer aldri tilbake til noen. Deretter kjører en agent og fullfører den helt på egen hånd, uten noen involvering.

      Automatisk kodegjennomgang · analytics havner rett i en egen Slack-kanal i stedet for å hente logger for hånd

    • Bestilleren gjør det

      Oppgaven når meg aldri. Den som trenger den, gjør den selv sammen med KI — min del er å bygge veien én gang.

      Outreach-utsending · influencer-plattform

    • Teamet gjør det

      En funksjon eller plugin sydd inn i systemet, der teamet gjør endringene selv — uten ticket, uten utvikler.

      Redirect-plugin i CMS-et som SEO-teamet eier

  3. Filter to — å gjøre selve skrivingen raskere

    Oppgaven overlevde filter én, altså er den min. Neste spørsmål: er dette rutine i kodesammenheng? Gjentar mønsteret seg — knappestiler, en tilbakevendende struktur — skriver jeg først en skill for det og deretter koden. Lengre én gang, raskere hver gang etterpå.

Beslutning

  1. Plan mode — analyse før en eneste linje

    Jeg må leve meg gjennom koden, ikke få den. Planen avgjør hvem som skriver den.

    Jeg kjenner ikke denne koden
    Jeg skriver den selv.
    Jeg kjenner denne koden
    Agenten skriver den.
    Kjente den ikke, men planen gjorde den klar
    Agenten skriver den.

Levering

  1. Implementering

    Den planen valgte, begynner å skrive — jeg eller agenten.

  2. Sjekker i dev — agenten

    Agenten sjekker, ikke jeg: den kjører flyten gjennom Playwright eller leser feil rett fra Next.js-dev-serveren via MCP. Ingen av kapasiteten min går med her.

  3. Sjekker i build-modus — agenten

    Dev lyver. Andre chunks, andre optimaliseringer, annen oppførsel. Noe som funker i dev og dør i build er en klassiker, så build får sin egen runde — igjen drevet av agenten.

  4. Enhetstester + Playwright

    Først når det faktisk funker. Enhetstester for logikken, Playwright for flyten — skrevet av agenten de også.

  5. Staging — her trer jeg inn

    Første punkt jeg selv sjekker for hånd. Lokalt bare når oppgaven er følsom. Deretter går det til QA — i den rekkefølgen, ikke omvendt.

  6. Pull request

    Gjennomgått av agenter med de skillene som eier den sonen av prosjektet: en ytelsesendring prøves mot ytelsesreglene, en betalingsendring mot betalingsreglene.

  7. Produksjon

    Release.

  8. Sluttsjekk

    QA i produksjon. Holder det — ferdig.

Fundament
  • OOP
  • SOLID
  • DRY
  • KISS
  • YAGNI
  • CI/CD

Ved å kunne de arkitektoniske praksisene og holde rekkefølgen på stegene kan man skrive kode raskt og godt samtidig. Farten kommer fra rekkefølgen, ikke fra raskere tasting.

Ekspertise i én bestemt teknologi gir alltid bedre kode — det er ikke til diskusjon. Men den overføres ikke: bytter du stack, starter du på nytt. Forståelsen av utviklingsflyten, av arkitektur og av prinsipper overføres fullt ut. Det er den som gjør det mulig å jobbe i en kodebase du ennå ikke kjenner: plan mode (steg 04) viser hvordan akkurat dette prosjektet er satt sammen, og å vurdere om en løsning er riktig, kan du allerede.