Slik maksimerer du agentiske arbeidsflyter

Se for deg dette scenariet: Du lener deg tilbake med kaffekoppen, mens en ivrig, digital assistent tar seg av grovarbeidet i koden din. Dette er ikke lenger en fjern fremtidsdrøm, men en høyst reell mulighet hvis du skrur sammen verktøykassen din riktig.

‍

I dette innlegget skal vi se på konseptet jeg har valgt å kalle "Vibe-Maxxing" i utviklersammenheng. Kort forklart handler det om å systematisk optimalisere arbeidsflyten for å oppnå ett hovedmål: Maksimere kvaliteten på AI-generert kode og minimere tiden du bruker på manuell tasting.

‍

NB: Erfaringene her er basert på arbeid i Greenfield-prosjekter med små team og moderne kodebaser (hovedsakelig TypeScript/Next.js). Din situasjon kan variere, men prinsippene er forhåpentligvis nokså generelle.

‍

Hva er egentlig "Vibe-Maxxing"?

‍

Begrepet "Maxxing" er internettslang for å ta en hvilken som helst aktivitet og optimalisere den til det ekstreme. For oss utviklere betyr "Vibe-Maxxing" å flytte fokuset fra å bare bruke AI-verktøy, til å orkestrere dem strategisk.

Målet er tredelt:

1. Øke leveransetempoet:  Flytte fokus fra syntaks til problemløsning for å shippe funksjonalitet raskere.
2. Skalere egen kapasitet:  La én utvikler gjøre jobben til flere ved å maksimere autonomi i trygge omgivelser.
3. Heve kvaliteten:  Bruke den innsparte tiden på bedre arkitektur, testing og robusthet, heller enn å taste boilerplate.

Hensikten er altså ikke bare å jobbe annerledes, men å drastisk øke output per time . Ved å la AI ta seg av implementasjonsdetaljene, frigjør du kognitiv kapasitet til de vanskelige problemene – de som faktisk skaper verdi for brukerne. Det handler om overgangen fra å være en håndverker som legger murstein, til å bli arkitekten som sørger for at hele bygget reiser seg.

‍

La meg likevel være krystallklar: Dette er ikke en magisk pille som fjerner behovet for teknisk kompetanse. Tvert imot. Som vi skal se nærmere på mot slutten, introduserer denne arbeidsflyten nye risikoer vi ikke har hatt før. Men gevinsten ved å navigere dem riktig, er enorm.

‍

Så, før vi slipper AI-en løs, må vi sette opp noen sikkerhetsnett.

‍

Mentale modeller og sikkerhetsnett

‍

Det viktigste prinsippet for agentisk koding er enkelt: Kontekst er konge.

AI-kvalitet er direkte proporsjonalt med kvaliteten på konteksten du gir. Eller som jeg liker å si til meg selv:

"Shit in, shit out. Good shit in, good shit out" .

Hvis du fôrer modellen med dårlige beskrivelser eller utdatert dokumentasjon, får du ubrukelig kode tilbake. Det samme gjelder hvis du ikke gir modellen tilstrekkelig kontekst rundt problemet som skal løses.

Den mest nyttige mentale modellen er å behandle AI-agenten som en svært kapabel juniorutvikler . Hva ligger egentlig i begrepet "kapabel" her? Spør du meg handler det om at:

• Den kan lese dokumentasjon lynraskt...
• ...men den trenger tilstrekkelig kontekst for å ta gode beslutninger.
• Uten veiledning vil den høyst sannsynlig velge feil retning for implementasjon.
• Din rolle endres derfor fra å være "bare en utvikler" til å bli en teknisk leder som orkestrerer prosessen og kvalitetssikrer arbeidet.

Velg din verktøykasse

‍

Du trenger ikke det dyreste bedriftsabonnementet for å få dette til å flyte. Her er oppsettet som gir meg mest verdi for pengene:

1. Claude Code  ($100/mnd)
   Dette er motoren i oppsettet. Claude Code håndterer komplekse prosjekter, arkitekturforståelse og konsistens på tvers av store kodebaser bedre enn det meste annet akkurat nå.
   
2. Windsurf   (Gratisversjon)
3. SuperWhisper  (Gratis/Lokalt)
   Dette er den hemmelige ingrediensen. SuperWhisper lar deg snakke direkte til AI-en med lokal transkribering på Mac-en din. Mer om dette senere.
   

Arbeidsflyten: Planlegging vs. Gjennomføring

‍

For å lykkes må du vite når du skal bremse og når du kan gi gass.

Vi skiller mellom to moduser:

‍

1) Plan Mode (Tenkeboksen)

Når du skal bygge en større feature, start her. Skru på “Extended Thinking” og lag en detaljert implementasjonsplan.

• Jeg pleier å be om et "research doc" som lagres som en markdown-fil i roten av prosjektet. Dette kan jeg sjekke inn i versjonskontroll eller slette når jeg er ferdig med å implementere den nye funsjonaliteten.
• Dette løser problemet med at AI-modellen "glemmer" kontekst i lange chatter.
• Du kan enkelt starte en ny sesjon, dra inn plan-filen, og fortsette der dere slapp.

Nøkkelen til suksess her er struktur: Be eksplisitt om at planen deles inn i faser og sub-faser . Dette tvinger modellen til å tenke sekvensielt og logisk på avhengigheter. Ved å låse rekkefølgen på hva som må gjøres, unngår du at agenten prøver å "male veggene før grunnmuren er støpt", og du beholder full kontroll over progresjonen.

‍

2) Auto-Edit Mode (Gjennomføring)

Når planen er lagt og dere er enige om retningen, skrur du på "auto-edit". Her får agenten lov til å skrive og endre filer selv. Din jobb er å overvåke og ta stikkprøver av kritisk forretningslogikk.

‍

Stemmestyrt utvikling

Det høres kanskje rart ut å snakke til datamaskinen din, men her ligger det en enorm produktivitetsgevinst. Å beskrive kompleks forretningslogikk muntlig er ofte langt mer presist og raskere enn å skrive det ned. Mitt råd er å finne et stille rom, lukk øynene, og forklar problemet som om du snakket til en kollega.

‍

Superwhisper transkriberer tankene dine lokalt, og du kan lime en perfekt formulert, detaljert instruks rett inn i terminalen. Det gir AI-en en dybde i konteksten som er vanskelig å oppnå via tastaturet.

Trygge omgivelser gir maksimal autonomi

Mange er skeptiske til å gi AI for mye autonomi. Løsningen er å skape en sandkasse hvor det er trygt å feile.

Lokal utvikling er perfekt for dette.

• Ingen risiko for produksjonsdata:  La AI-en herje med din lokale database.
• Rask gjenoppretting:  Hvis agenten roter det til, kan du resette databasen og seede den på nytt på sekunder.

Gi agenten tilgang til databaseverktøyene dine. La den generere migrasjoner, kjøre dem, oppdatere typesystemet og verifisere at alt henger sammen. Når AI-en forstår hele dataflyten – fra databaseskjema til frontend-typer – får du en selvforsterkende effekt hvor typesikkerheten fungerer som en veileder for AI-en.

‍

Fra System Prompts til Claude Skills

Tidligere brukte vi gjerne en CLAUDE.md i roten av prosjektet for å styre AI-ens oppførsel. Nå har vi noe enda bedre: Claude Skills .

‍

La oss ta den tekniske forklaringen først: Skills er rett og slett mapper som inneholder instruksjoner, skript og ressurser som Claude kan laste inn ved behov. I stedet for å mate AI-en med en enorm "wall of text" hver gang, skanner Claude nå tilgjengelige skills og laster kun inn den informasjonen som er relevant for oppgaven den skal løse akkurat nå. Tenk på det som skreddersydd opplæringsmateriell som gjør agenten til en spesialist på akkurat din kodebase. Det er modulært, effektivt og kan til og med inkludere kjørbar kode.

‍

For å bruke en litt mer visuell analogi: Tenk på filmen "The Matrix", der Neo lærer Kung Fu ved å laste det rett inn i hjernen sin. Claude Skills fungerer på samme måte. Ved å definere ferdigheter i .claude/skills/ -mappen, institusjonaliserer du prosjektets konvensjoner.

‍

Nå tenker du kanskje: "Hvis jeg har en stor og lang skill, vil ikke det sprenge kontekstvinduet?" Svaret er nei. I utgangspunktet er det kun metadataen på toppen av filen som lastes inn i kontekst:

---
name: ui-patterns
description: Apply consistent UI component patterns for the Next.js project. Use when building forms, dialogs, notifications, loading states, or any UI components. Ensures proper dark mode support, responsive behavior, animations, and adherence to the project's component library hierarchy.
---

<!-- Resten av skill kommer her... -->

Claude leser denne metadataen når du starter en ny chat. Hvis – og bare hvis – den avgjør at denne ferdigheten er relevant for oppgaven du ber om, lastes resten av dokumentet inn. Dette holder agenten rask og kontekst-effektiv. Hver gang du starter en ny sesjon, "husker" agenten disse ferdighetene. Dette sikrer at koden som produseres følger teamets standarder.

En viktig fotnote: Dette er ikke bare for oss utviklere. Anthropic har laget skills for å generere Word-dokumenter, Excel-ark og PowerPoint-presentasjoner . Disse er tilgjengelige for å brukes direkte i Claude Desktop. Det betyr at kollegaer innen ledelse, salg eller administrasjon kan dra nytte av nøyaktig samme teknologi for sine arbeidsflyter, helt uten å måtte forholde seg til markdown eller kode.

‍

AI-assistert debugging:  console.log  er din venn

Da jeg startet som utvikler, fikk jeg alltid den samme strenge beskjeden i Pull Request-reviews: "Fjern alle console.logs før du merger!" Det var nesten som en dødssynd å la en logg bli igjen. Jeg forstår jo hvorfor – vi vil ha ren og ryddig kode i produksjon – men jeg tror det ga meg et slags underbevisst traume. En liten stemme i bakhodet som hvisket at det å strø om seg med logger var uprofesjonelt.

‍

Vel, i en agentisk arbeidsflyt er det på tide å ignorere den stemmen. Ikke skam deg over å bruke console.log overalt når du utvikler. Det viser seg faktisk å være skikkelig nyttig noen ganger.

‍

Her er en situasjon vi alle kjenner: En "stille feil". Alt ser riktig ut når du sender inn det skjemaet i frontenden, ingen feilmeldinger kastes, men dataene havner ikke i databasen. I stedet for å stirre blindt på koden eller steppe manuelt gjennom linje for linje, gjør jeg følgende:

1. Be om instrumentering:  Jeg ber AI-agenten om å legge til omfattende logging gjennom hele dataflyten – fra frontend til backend.
2. Manuell testing:  Jeg tester for å gjenskape feilen i applikasjonen og kopierer hele logg-suppa fra terminalen. Husk å fjerne sensitiv informasjon før du gir det til AI-modellen din.
3. Kollaborativ analyse:  Jeg limer loggene tilbake til AI-en og ber den analysere dataflyten.

Mønstergjenkjenning er en av AI-ens største styrker. Den vil ofte se nøyaktig hvor dataene endrer form eller forsvinner mye raskere enn du klarer selv. Når feilen er funnet og fikset, kan du be agenten om å rydde opp og fjerne loggene igjen. Alternativt kan du bare kjøre git reset --hard , men husk å være flittig til å sjekke inn endringene dine i versjonskontroll. Enkelt, smertefritt, og veldig effektivt.

‍

Trade-offs: Baksiden av medaljen

Er det bare fordeler? Absolutt ikke. Som med all teknologi som lover ti-dobling av effektivitet, finnes det ingen gratis lunsj. Når vi overlater skrivingen til AI, introduserer vi nye risikoer som vi må være smertelig klar over for å lykkes.

Her er noen av de største fellene å være bevisst på:

‍

1. Illusjonen av kompetanse (”The Illusion of Competence”)

Det er farlig lett å bli blendet av hvor raskt koden genereres. Koden ser ren ut, den kjører, og testene passerer kanskje til og med. Men når du ikke har skrevet linjene selv, mister du den dype, intuitive forståelsen av hvordan ting henger sammen under panseret.

• Motgift:  Du må være enda nøyere i code reviews enn før. Ikke bare se etter om koden virker, men om den følger arkitekturen og kloke valg en dyktig utvikler ville tatt. Behandle AI-ens genererte kode som om den kom fra en nyansatt som ikke kjenner domenet ennå.

2. Spagetti i lysets hastighet

AI er ekstremt dyktig til å skrive dårlig kode veldig raskt hvis du (uvitende) ber den om det. Hvis du blir slapp med kontekststyringen (Plan Mode) og bare kaster tilfeldige kommandoer på agenten, vil du produsere teknisk gjeld raskere enn noe menneske klarer.

• Motgift:  Vær nådeløs på struktur. Hvis "Research Doc"-et ditt er dårlig, blir koden dårlig. Aldri hopp over planleggingsfasen på komplekse oppgaver.

3. Avhengighet og "Muscle Memory"

Når du slutter å skrive boilerplate-kode, begynner syntax-hukommelsen å bli rusten. Er det et problem? Kanskje. Hvis du plutselig må debugge en kritisk feil uten AI-verktøyene dine, kan du føle deg handikappet.

• Motgift:  Vibe-Maxxing handler ikke om å skru av hjernen, men om å skru den  på  et høyere abstraksjonsnivå. Du bytter ut tasting med systemtenkning, men du må fortsatt forstå fundamentet for å kunne styre skuta.

4. Hallusinerte pakker og sikkerhetshull

En av de skumleste feilene AI-modeller gjør, er såkalt Package Hallucination . AI-en kan finne på å foreslå et bibliotek som høres logisk ut (f.eks. npm install react-fast-crypto-hook ), men som faktisk ikke eksisterer.

‍

Dette har gitt opphav til fenomenet Slopsquatting . Ondsinnede aktører overvåker hvilke pakkenavn AI-ene ofte hallusinerer om, og kommer dem i forkjøpet ved å registrere disse navnene på pakkeregistre som NPM eller PyPI – fylt med skadelig kode. Hvis du har en arbeidsflyt der du blindt aksepterer terminalkommandoer fra verktøy som Claude (slik man fort gjør i "Auto-Edit Mode"), kan du intetanende installere malware rett inn i prosjektet ditt. I tillegg kan AI-en fint foreslå kode som er sårbar for injections, rett og slett fordi den mangler den fulle sikkerhetskonteksten.

• Motgift:  Aldri kjør  npm install  (eller tilsvarende) blindt på en pakke du ikke kjenner. Sjekk alltid at pakken er legitim, vedlikeholdt og har en historikk. Behandle all AI-generert kode som "untrusted input" frem til du har verifisert den

Den ivrige assistenten vi møtte innledningsvis vil deg bare vel, men den vet ikke bedre. Uten dine kritiske øyne leverer den gjerne ondsinnede pakker og sikkerhetshull med et stort smil – rett og slett fordi den ikke forstår konsekvensene.

‍

Meta-lærdommer: Hvorfor gjøre dette?

La oss zoome ut litt. I grunn handler dette om mye mer enn bare å spare noen tastetrykk eller kodingseffektivitet. Etter min mening handler dette om skalering av kompetanse og hvordan vi tenker rundt kunnskap i en organisasjon.

‍

Institusjonell hukommelse og onboarding

Når du dokumenterer arbeidsflyter slik vi har gått gjennom i denne posten, bygger du en robust institusjonell hukommelse. Hva skjer når en nøkkelperson slutter? I tradisjonelle team forsvinner ofte masse "taus kunnskap" ut døra. Med denne tilnærmingen er kunnskapen kodifisert i verktøyene, ikke bare i hodene til folk.

‍

Dette gir en ekstrem gevinst ved onboarding. En nyutdannet utvikler (eller en ny senior for den saks skyld) kan komme inn i prosjektet og være produktiv i løpet av dager, ikke uker eller måneder . Hvorfor? Fordi "hvordan vi gjør ting her" – arkitekturvalg, UI-mønstre, databasekonvensjoner – allerede ligger klart som ferdigheter i AI-agenten de skal samarbeide med. Det gir dem et stillas å bygge på fra første time.

‍

Konkurransefortrinn

Dette er kanskje litt "høytflyvende", men jeg mener oppriktig at det ligger et betydelig konkurransefortrinn her. Et konsulenthus eller en produktavdeling som har institusjonalisert disse ferdighetene, starter ikke fra null hver gang.

‍

Hvis du systematisk gjenbruker og forbedrer dine Claude Skills på tvers av prosjekter, gjerne tilpasset samme tech stack, leverer du raskere og med høyere kvalitet enn konkurrenten som fortsatt sitter og skriver boilerplate-kode manuelt. I det lange løp betyr det evnen til å ta på seg flere eller større prosjekter, som igjen betyr høyere inntekt for organisasjonen.

‍

Den dypeste innsikten

Agentisk utvikling handler dypest sett ikke om kode. Det handler om å hente ut, strukturere og skalere menneskelig ekspertise til et nivå som tidligere var utilgjengelig for oss.

‍

Hvordan dette innlegget (egentlig) ble til

Til slutt, her kommer "the kicker" – demonstrasjonen av alt jeg nettopp har snakket om.

Du lurer kanskje på hvor lang tid det tok å skrive dette innlegget? Svaret er at jeg nesten ikke har skrevet det. Hele teksten du nå har lest, er basert på en presentasjon jeg genererte for et foredrag – og prosessen beviser nøyaktig det jeg har fortalt om.

Slik var arbeidsflyten fra idé til ferdig bloggpost, gjennomført på drøye timen:

1. Fase 1: Stemmestyrt "Brain Dump"
2. Fase 2: Fra tale til presentasjon
3. Fase 3: Fra presentasjon til bloggpost

Det du leser nå, er altså bare et nytt "format" av den samme konteksten. Jeg har ikke tastet selve teksten; jeg har orkestrert innholdet.

‍

Ved å kombinere riktig kontekst, stemmestyring og agentiske verktøy, flytter vi oss fra å være de som taster ordene (eller koden), til å være arkitektene som former budskapet.