Fra 8 timer til 47 minutter - 12 bevist AI-kodingsstrategier

AI bygget en funksjon på 47 minutter, noe som ville ha tatt 8 timer arbeid for noen år siden. Men her er det som ingen forteller deg: uten de rette strategiene, vil den samme AI kaste bort tre timer på å bygge feil ting.

Hei, jeg er Chuck, og jeg har skrevet kode i 30 år. I 2023 innså jeg at jeg enten måtte omfavne AI eller finne en ny karriere. Jeg valgte å omfavne det. Siden da har jeg bygget et dusin applikasjoner ved hjelp av kodingsagenter, og i dag deler jeg alle strategiene jeg har lært med deg.

AI endrer alt, mest merkbart akselererer det alt. Det som tok en dag tar nå en time.

Hastigheten betyr noen få ting:

For det første, er tilbakemeldingssyklusen din mye raskere, feil og feil retninger dukker opp raskere, og å komme til suksess dukker opp raskere.

For det andre, er mye kode nå engangs. Det er kostnadseffektivt primært å skrive og kassere i stedet for å skrive og refaktorere.

For det tredje, dukker programvareudviklingshull som tok år å løpe inn i nå opp i løpet av uker eller måneder.

For det fjerde, uten veiledning, går AI raskt av sporet og over kanten.

I min tid med kodingsagenter som Cursor har jeg oppdaget 12 strategier som hjelper til med å holde AI fra å gå over kanten. Disse ble lært på den harde måten, gjennom prøving og feiling.

1. Bruk Agent.md

En av mange ting jeg la merke til om LLM-er er at de alle vil legge til “fallbacks.”

Fallbacks er betinget kode som kjøres når den første betingelsen mislykkes. Dette er flott når koden din skal til Mars, men det meste av koden går ikke til Mars, i hvert fall ikke min. For å gjøre det verre, er Fallbacks iboende buggy og er ikke nødvendig det meste av tiden.

Det er her en Agent.md-fil kommer inn. Du kan instruere LLM-en til ikke å bruke fallbacks. Faktisk kan du fortelle den å gjøre hva som helst. Alt du ville legge til en prompt kan legges til Agent.md. Filen legges automatisk til hver ny kontekst.

For øyeblikket har hver kodingsagent sin egen agent.md-fil. Cursor kaller deres .cursorrules, Claude Code kaller deres claude.md. Jeg mistenker at kodingsagenter snart vil standardisere på et felles navn.

I min Agent.md definerer jeg programvaremønstrene, teststrategi og arkitekturen jeg vil bruke. Alt jeg finner at agenten gjør gjentatte ganger på grunn av mangel på kontekst eller retning, legger jeg til filen.

Her er en lenke til et depot med agentregler.

Når Agent.md-filen er satt opp, vil du bruke AI uhindret.

2. Full gass

Både Claude Code og Cursor AI starter i en “sikker modus” ut av boksen. Sikker modus krever tillatelse for hver verktøykall. Etter noen få minutter med å godkjenne HVER verktøykall, var jeg ferdig med sikker modus.

Heldigvis lar hver kodingsagent deg velge bort “sikker modus”. Risikoen er at AI kan gå av og gjøre uønskede ting, men i tiden jeg har brukt kodingsagenter, har jeg aldri opplevd at det gjør noe irreversibelt.

Jeg holder øye med hva LLM-en gjør, men jeg er ikke komfortabel med å gå bort fra kodingsagenten ennå.

Ærlig talt, med mindre du ber LLM-en om å arbeide med live produksjonskode, og jeg vet ikke hvorfor du ville ha sikker modus.

Nå som du har frigjort kodingsagenten din, må vi definere problemet.

3. Definere problemet ditt

AI er en bokstavelig tolker. Du får det du ber om, noe som betyr at vage spørsmål gir vage resultater.

Jeg har funnet at det å gi AI detaljerte krav og be om en “vurdering” gir de beste resultatene. Dette lar AI se etter hull i designet og svare med oppfølgingsspørsmål. Etter et par frem-og-tilbake, vil du ha en solid plan.

I nylige utgivelser har både Cursor og Claude Code lagt til “Plan Mode,” som formaliserer prosessen ovenfor.

Jeg tar det et skritt videre og lar en annen LLM gjennomgå planen. For eksempel bruker jeg ChatGPT for den første AI-vurderingen. Det genererer et markdown-dokument med alle kravene. Jeg gir deretter det dokumentet til Claude for tilbakemelding, og Claudes andre gjennomgang finner alltid manglende hull.

Dette er en smakssak, men AI har en tendens til å over-arkitekturere for meg. Igjen, AI ser ut til å tro at koden er på vei til Mars.

Når du har blitt enig om en plan, be AI om å lagre den i et dokument i prosjektet ditt.

Noe som bringer meg til neste punkt.

4. Lag en faseinndelt plan

Deling av store funksjoner i håndterbare faser og oppgaver

Etter at du har opprettet en plan, be AI om å dele arbeidet opp i faser. Du vil ha små arbeidsenheter; jo mindre, jo bedre. Jo mindre enheten, jo høyere sjanse for suksess.

Noen kodingsagenter gjør dette ut av boksen, men hvis de ikke gjør det, be dem om det.

Den beste planen vil fortsatt mislykkes hvis du ikke kan spore fremdriften. Det er her sjekklister kommer inn.

5. Be om en sjekkliste

Be AI om en sjekkliste og fortell den at du trenger en for å spore fremdriften. Mange av kodingsagentene har lagt sjekklisten til agentprompten og brukergrensesnittet, men noen ganger trenger jeg fortsatt en sjekkliste for å spore fremdriften eller spore langvarig arbeid.

Sjekklisten gir også AI noe å måle seg mot, så den vet når den er ferdig.

Sjekklister er flotte, men hvordan spenner vi kontekster med sjekklister? Det er her overføringsdokumentet vårt kommer inn.

6. Lag et overføringsdokument

Hva er et overføringsdokument?

Et overføringsdokument er en høynivåbeskrivelse av applikasjonen. Formålet er å bringe en tom kontekst opp til hastighet på applikasjonens domene, kode og arkitektur.

Ideelt sett plukker agenten opp i samme tempo som den forrige konteksten sluttet.

I Agents.MD instruerer jeg agenten om å oppdatere overføringsdokumentet mitt med høynivåendringer. Det vi ikke vil ha er hver detalj i dokumentet; jeg trenger et høynivåsammendrag, og jeg lar AI bestemme hva det er.

Arbeidsflyten min går litt slik:

Hver gang jeg startet en ny kontekst, inkluderte jeg overføringsdokumentet mitt og instruerte AI om den nye funksjonen. AI plukker opp oppgaven og begynner å arbeide som om den har vært på prosjektet i 6 måneder.

Overføringsdokumentet er flott for mindre applikasjoner, men i større applikasjoner bruker det for mange tokens og er ikke praktisk. Jeg vurderer andre alternativer, for eksempel en vektordatabase eller en grafdatabase.

Men jeg eksperimenterer fortsatt.

Jeg ville gjerne høre hvordan du nærmer deg dette problemet. Legg igjen en kommentar nedenfor.

Selv med sjekklister og et overføringsdokument gjør AI feil. Det er her commits kommer inn.

7. Sjekk inn ofte

Gjør små commits. Små commits lar deg gå tilbake til en kjent god tilstand. Jeg har funnet at noen ganger AI går ned i kaninhullet, og det er ingen gjenoppretting.

Bare tilbakestill.

8. Tilbakestill konteksten

Vær hensynsløs når du tilbakestiller konteksten.

Noen ganger går AI ned en feil vei eller gjør en feil, skap og start på nytt. Når alle dokumentene dine er i orden, er det enkelt å starte en ny kontekst. Dette er genialiteten i overføringsdokumentet.

Men jeg skal være ærlig, når jeg arbeider med AI – jeg humaniserer AI fordi det føles som om jeg arbeider med et annet menneske, og å trykke på den tilbakestillingsknappen tuller noen ganger med menneskeligheten min.

En måte å begrense kaninhullene på er gjennom testing.

9. Testing

Da jeg var programvareingeniør, var testing forferdelig. Å skrive testkode er noe av det mest kjedelige arbeidet for en programvareingeniør.

Med AI er det ingen grunn til at du ikke skal teste koden din. AI vil skrive alle testene for deg. Faktisk kan du spesifisere 80% testdekning i agent.md, og kodingsagenten legger magisk til testene.

Jeg har funnet testing fordelaktig; utover kvalitetskomponenten gir det AI en struktur for å validere arbeidet sitt. Dette fører til kode av høyere kvalitet og bedre bruk av AI.

En advarsel, jeg lar ofte AI gjøre kodendringer uten å oppdatere testene. Etter at koden fungerer, ber jeg AI om å oppdatere testene. Noen ganger tar AI testene for alvorlig og endrer produksjonskode for å matche testene, og angrer alle endringene vi nettopp gjorde.

En annen måte jeg har funnet for å forbedre kvaliteten på er gjennom automatisering.

10. Automatiser, automatiser, automatiser

Gjør ting så enkelt som mulig.

Før AI hørte jeg ofte: “Engangsdeployments, det ville vært flott, men vi har ikke tiden.” Nå er det ingen unnskyldning, AI vil automatisere alt for deg.

Målet mitt er å ha hver handling være en enkelt kommando. For eksempel:

• Hvis jeg vil starte applikasjonen? ./start.sh.
• Jeg vil kjøre testene. ./test.sh.
• Distribuere applikasjonen? Du gjettet det ./deploy.sh

Automatisering tjener to formål:

• For det første sparer det deg tid.
• For det andre fjerner det menneskelig feil fra prosessen.

Ethvert sted der det er friksjon og flere trinn, vil jeg automatisere det bort. Men for å løse de mer komplekse problemene, trenger jeg noen ganger mer kapable LLM-er.

11. Bruk den beste LLM-en

Ikke spar på modellytelse. De nyeste modellene er dyre, men i et forsøk på å spare penger, kan de ende opp med å koste deg.

Av og til anbefaler Cursor å bruke Auto-modus for å spare tokens. Ok, det høres bra ut, hva kan gå galt? Jeg er alltid åpen for å spare penger. Så jeg skrudde det på og implementerte en funksjon. Det ble en katastrofe. Jeg brukte de neste 3 timene på å løse rotet ved hjelp av de nyeste modellene, og det kostet dobbelt så mye som jeg ville ha betalt hvis jeg ikke hadde brukt auto-modus. Poenget mitt er ikke at auto-modus er dårlig; det er at arbeid med komplekse problemer krever de beste modellene.

Men noen ganger er selv de beste modellene ikke nok; du trenger de riktige verktøyene.

12. Verktøy

Tenk på AI som hjernen; den tenker, men den kan ikke gjøre noe. Dette er kraften i et verktøy. Det gir AI evnen til å handle.

Jeg deler kodingsagentverktøy inn i to klasser:

To klasser av verktøy som forbedrer AI-kodingsagenter

Først er verktøy designet for å forbedre programvareutvikling. Tenk på GitHubs MCP eller Anthropics Sequential Thinking MCP; disse verktøyene gjør generelt kodingsagenter mer kapable.

For det andre er verktøy som samhandler med prosjektet. For eksempel en database MCP eller et kommandolinjeverktøy. Disse verktøyene gir kodingsagenter evnen til å skrive kode, kjøre den og teste resultatene, og fullføre en full tilbakemeldingssyklus.

Det geniale med AI er at hvis du trenger et verktøy og det ikke finnes ett, kan AI lage det for deg.

Her er verktøyene jeg bruker med Cursor:

Det første verktøyet kalles Serena. Serena forsøker å avlaste oppgaver som å lese filer og lagre data til minne som normalt ville få AI til å generere kommandoer for å utføre operasjonen. Målet med dette prosjektet er å redusere antallet tokens som brukes og holde vanlige operasjoner lokale.

Det neste verktøyet jeg bruker kalles Sequential Thinking av Anthropic. Hvis det er av Anthropic, er det nesten garantert å være bra. Det dette verktøyet gjør er å dele komplekse problemer ned i håndterbare trinn. Det legger til dynamisk og reflektiv problemløsning gjennom en strukturert tenkeprosess.

Prøv det, jeg har lagt lenken i beskrivelsen.

Det siste verktøyet jeg bruker er prosjektspesifikt; det kalles Neo4j MCP, og AI opprettet det. Det har vært uvurderlig når jeg arbeider med Neo4j. Før ville AI be meg om å kjøre spørringer og deretter lime resultatene inn i chatten. Dette ble veldig tungvint veldig raskt. Med verktøyet kjører AI sine egne spørringer, og ingen menneskelig inngripen er nødvendig.

Det er vakkert, og det er raskere. Hvis du finner friksjon i utviklingsprosessen din, be AI om hjelp; du kan bli overrasket over hva som dukker opp.

Til slutt

La oss være ærlige her, arbeid med kodingsagenter føles mye som å parre seg med en briljant juniorprogrammerer som av og til glemmer alt vi nettopp fortalte dem. Disse 12 strategiene er hvordan jeg håndterer dette forholdet. Og de fungerer kanskje ikke for alle, eller deg, og det er ok. Finn det som fungerer for deg. Så mitt spørsmål til deg er: Hva fungerer for deg? Legg igjen en kommentar nedenfor og fortell meg.