
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 universelle.
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:
Men før vi slipper AI-en løs, må vi sette opp noen 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:
Du trenger ikke det dyreste bedriftsabonnementet for å få dette til å flyte. Her er oppsettet som gir meg mest verdi for pengene:
For å lykkes må du vite når du skal bremse og når du kan gi gass. Vi skiller mellom to moduser:
Når du skal bygge en større feature, start her. Skru på Thinking-evner og lag en detaljert implementasjonsplan.
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.
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.
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.
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.
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.
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.
---
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.
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:
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.
La oss zoome ut litt. Dette handler 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.
Når du dokumenterer arbeidsflyter slik vi har gått gjennom her 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.
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.
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.
Til slutt, here's the kicker – den praktiske demonstrasjonen av alt jeg nettopp har snakket om.
Dette blogginnlegget er basert på en presentasjon jeg har laget tidligere. Hele grunnlaget for den presentasjonen – fra idémyldring til ferdig slide-deck – ble generert på ca. 50 minutter ved å bruke nettopp disse metodene.
Slik så prosessen ut:
Dette blogginnlegget er i seg selv bare et nytt "format" av den samme konteksten. (Og husk: Kontekststyring er, som nevnt tidligere, det aller viktigste vi driver med når vi jobber med agentisk AI). Ved å kombinere riktig kontekst, stemmestyring og agentiske verktøy, flytter vi oss fra å være de som taster koden, til å være arkitektene som designer systemene som bygger den.

Magnus bygger AI i Capra, nå på Gjensidiges «Hei, huset!». Han er opptatt av AI som fungerer i praksis og av å rigge tverrfaglige team for en AI-first arbeidsform. Det skriver han om og holder foredrag om.
