Skip to main content

Hvordan en opgave bliver til produktion

Sådan arbejder jeg reelt i 2026: hver opgave passerer først to filtre — kan manuelt arbejde undgås helt, og kan skrivningen gøres hurtigere — og når først derefter koden. Nedenfor hele kæden, trin for trin.

Forudsætning — ejer eller udførerFilteret virker kun, når jeg ejer mit område

Promova byggede min tankegang om: ikke bare at være udvikler, men at validere hver opgave, der når mig. Ikke »hvordan bygger jeg det her« men »hvad gør det for forretningen«. Det filter virker dog kun under én betingelse.

Jeg ejer mit område

Opgaven går straks gennem filteret. Jeg står til ansvar for resultatet, så jeg har ret til at sige »det her bør slet ikke bygges« eller »det her bør ikke bygges af mig«.

Jeg er udfører

Intet filter. Der er en opgave, en deadline og en levering. Der er ikke noget galt med det — det er simpelthen en anden aftale.

Forskellen er ikke evner, men mandat. En selvstændig enhed, der fuldt ud ejer sit område, koster virksomheden mindre end en udfører — fordi den ikke bygger det unødvendige.

Før koden

  1. En opgave kommer ind

    Jeg starter ikke med »hvordan bygger jeg det her«. Det første spørgsmål er, hvad det gør for forretningen; det andet, om det overhovedet skal bygges i hånden, af mig.

  2. Filter et — kan alt håndarbejde undgås?

    Tre udveje, og alle tre svarer på ét spørgsmål: hvem gør det her fremover. Tager opgaven en af dem, holder den op med at være min, og min kapacitet står fri til arbejde, der faktisk kræver en udvikler.

    udgange fra pipelinen
    • Agenten gør det

      Sættes op én gang og vender aldrig tilbage til nogen. Derfra kører en agent og fuldfører den helt selv, uden nogen involvering.

      Automatisk kodegennemgang · analytics lander direkte i en dedikeret Slack-kanal i stedet for at trække logs i hånden

    • Bestilleren gør det

      Opgaven når mig aldrig. Den, der har brug for den, gør den selv sammen med AI — min del er at bygge vejen én gang.

      Outreach-udsendelse · influencer-platform

    • Teamet gør det

      En funktion eller plugin syet ind i systemet, hvor teamet selv laver ændringerne — uden ticket, uden udvikler.

      Redirect-plugin i CMS'et, som SEO-teamet ejer

  3. Filter to — at gøre selve skrivningen hurtigere

    Opgaven overlevede filter et, altså er den min. Næste spørgsmål: er det rutine i kodemæssig forstand? Gentager mønsteret sig — knapstile, en tilbagevendende struktur — skriver jeg først en skill til det og derefter koden. Længere én gang, hurtigere hver gang derefter.

Beslutning

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

    Jeg skal leve mig igennem koden, ikke få den. Planen afgør, hvem der skriver den.

    Jeg kender ikke denne kode
    Jeg skriver den selv.
    Jeg kender denne kode
    Agenten skriver den.
    Kendte den ikke, men planen gjorde den klar
    Agenten skriver den.

Levering

  1. Implementering

    Den, planen valgte, begynder at skrive — jeg eller agenten.

  2. Tjek i dev — agenten

    Agenten tjekker, ikke mig: den kører flowet gennem Playwright eller læser fejl direkte fra Next.js-dev-serveren via MCP. Ingen af min kapacitet går her.

  3. Tjek i build-tilstand — agenten

    Dev lyver. Andre chunks, andre optimeringer, anden opførsel. Noget der virker i dev og dør i build er en klassiker, så build får sit eget gennemløb — igen drevet af agenten.

  4. Enhedstest + Playwright

    Først når det faktisk virker. Enhedstest for logikken, Playwright for flowet — også skrevet af agenten.

  5. Staging — her træder jeg ind

    Det første sted, jeg selv tjekker i hånden. Lokalt kun når opgaven er følsom. Derefter går det til QA — i den rækkefølge, ikke omvendt.

  6. Pull request

    Gennemgået af agenter med de skills, der ejer den zone af projektet: en performance-ændring holdes op mod performance-reglerne, en betalingsændring mod betalingsreglerne.

  7. Produktion

    Release.

  8. Sluttjek

    QA i produktion. Holder det — færdig.

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

Ved at kende de arkitektoniske praksisser og holde rækkefølgen på trinnene kan man skrive kode hurtigt og godt på samme tid. Farten kommer fra rækkefølgen, ikke fra hurtigere tastning.

Ekspertise i én bestemt teknologi giver altid bedre kode — det er ikke til diskussion. Men den overføres ikke: skifter du stack, begynder du forfra. Forståelsen af udviklingsflowet, af arkitektur og af principper overføres fuldt ud. Det er den, der gør det muligt at arbejde i en kodebase, du endnu ikke kender: plan mode (trin 04) viser, hvordan netop dette projekt er sat sammen, og at vurdere, om en løsning er den rigtige, kan du allerede.