Derfor skuffer din kodeassistent dig

Lad os være ærlige i et øjeblik. Du har sikkert prøvet en kodeassistent, set den skrive en funktion eller to, og tænkt: "Nå, det var da smart." Men så prøvede du at bruge den til noget rigtigt—noget der betyder noget—andu stødte ind i en mur.

Måske begyndte den at opfinde API'er der ikke eksisterer. Måske ordnede den en fejl et sted og ødelagde tre andre. Måske sad den bare der og ventede på, at du skulle forklare hvad du egentlig ville. Ringer det en klokke?

Her er den ubehagelige sandhed: Assistenten er ikke i stykker. Du bruber den bare forkert.

Mere specifikt: Du trækker sandsynligvis i én spak, når der er tre tilgængelige.

De tre spaker ingen snakker om

Hver kodeassistent—hvad enten du bruger Claude Code, Cursor, Copilot eller noget helt andet—fungerer efter den samme grundlæggende logik. Den modtager information, gør noget med den, og får så feedback. Det er alt. Hele maskineriet.

Men her går de fleste galt: De optimerer en eller to af disse spaker og ignorerer fuldstændig den tredje. Og i produktionsudvikling bliver den manglende spak din flaskehals.

Lad mig forklare hvad jeg mener.

SE: Hvad ved din assistent egentlig?

Udbakket kan din assistent se din kode og din shell. Ikke mere. Den kender ikke dit teams kodestandarder. Den kender ikke den mærkelige workaround din seniorudvikler lavede for tre år siden til en legacy-integration. Den ved ikke hvad "færdig" betyder for dit specifikke projekt.

Når jeg snakker med teams der kæmper med AI-assisteret udvikling, er problemet næsten altid kontekst. Assistenten flyver blindt. Den skriver kode der teknisk set virker, men som ikke passer til dit kodningsmønstre, ignorerer dine navngivningskonventioner, eller opfinder hjulet på ny der hvor dit team allerede har løst problemet.

Løsningen? Pak din kontekst som om du giver arbejdet videre til en ny juniorudvikler. Hvilke filer skal den læse først? Hvilke konventioner betyder noget? Hvordan ser din arkitektur ud? De fleste værktøjer har måder at injicere dette på—systemprompts, dokumentationsreferencer, skill-filer. Brug dem.

HANDL: Hvad kan din assistent egentlig gøre?

Her bliver det interessant. En basal assistent kan redigere filer og køre tests. En konfigureret assistent kan forespørge API'er, tjekke CI-status, læse Slack-tråde eller interagere med din cloud-infrastruktur.

Jo flere handlinger din assistent har adgang til, jo mindre skal du manuelt bygge bro mellem værktøjer. Vil du have at din assistent verificerer at en deployment faktisk virkede før den lukker en ticket? Den skal kunne tjekke din cloud-konsol. Vil du have at den koordinerer med holdkammerater? Den skal have adgang til dine kommunikationskanaler.

Det handler ikke om at bygge en sci-fi AI-overherre. Det handler om at fjerne det manuelle arbejde med at skifte mellem værktøjer. Hver alt-tab er et overleveringspunkt hvor kontekst går tabt. Jo mere din assistent kan gøre autonomt inden for din arbejdsgang, jo strammere bliver den loop.

RET: Hvordan ved din assistent at den lavede en fejl?

Dette er spaken de fleste teams fuldstændig forsømmer, og det er grunden til at deres assistenter føles upålidelige.

Din assistent har brug for feedback. Ikke bare "denne kode virker ikke" men nuancerede signaler om kvalitet, stil og intention. Linters fanger syntaksproblemer. Tests fanger funktionelle fejl. Code review fanger arkitektoniske problemer. Men din assistent kan ikke handle på feedback den aldrig modtager.

Tænk på det sådan: Hver automatisk rettelse din assistent støder på er et læringsøjeblik. Hver ignoreret fejl er en misset mulighed. Jo strammere dine feedback loops, jo hurtigere forbedrer din assistent sig.

Dette er hvor mange teams fejler. De kører tests manuelt, tjekker lints sporadisk og reviewer kode når de husker det. Men for at din assistent skal være pålidelig, skal disse checks være automatiske og hurtige. CI pipelines der tager 45 minutter er døden for agentproduktivitet. Øjeblikkelig feedback? Der sker magien.

Svage led-princippet

Her er den mentale model der ændrede hvordan jeg tænker om dette:

Forestil dig tre stænger. Én for Se, én for Handl, én for Ret. Din assistents samlede kapacitet er begrænset af den korteste stang.

Jeg har set teams bruge ressourcer på at få deres assistenter til at skrive bedre kode (Handl), men de gav aldrig assistenten ordentlig kontekst (Se), så den blev ved med at lave de samme fejl. Jeg har set teams bygge elaborate feedback-systemer (Ret), men assistenten kunne ikke tilgå den information den havde brug for til at anvende den feedback (Se). I hvert tilfælde var flaskehalsen spaken ingen havde tænkt på at trække i.

Dette er ikke bare intuition. Det er en strukturel begrænsning i ethvert system der perciperer et miljø, handler på det og justerer. Tænk på reinforcement learning-systemer—de har brug for observation (SE), action space (HANDL) og reward signals (RET). Fjern ét element, og systemet degraderer. Din kodeassistent er præcis det samme.

Hvad dette betyder for dit team

Hvis du evaluerer kodeassistenter til produktionsarbejde, så test dem ikke kun på legetøjsproblemer. Kør dem igennem scenarier der stresser alle tre spaker:

• Kan assistenten tilgå den kontekst den har brug for til at forstå dit kodebase?
• Kan assistenten udføre handlinger der passer ind i din faktiske arbejdsgang?
• Modtager assistenten feedback hurtigt nok til at kurskorrigere?

Hvis svaret på et af disse er "ikke rigtig," er det der dit investering skal gå.

For engineering leads og arkitekter: Dette handler ikke om at finde det rigtige værktøj. Det handler om at bygge det rigtige system. Værktøjet er bare motoren. Spakerne er gearkassen, brændstofsystemet, kølesystemet. En Ferrari med et manglende hjul er ikke en superbil—det er en ødelagt bil.

Det store billede

Vi er stadig tidligt i AI-assisteret udvikling. Teams lærer at at smide en kodeassistent efter et problem ikke er nok. De teams der får mest værdi ud af det er ikke dem med de klogeste modeller—de er dem der bygger de strammeste loops mellem at se, handle og rette.

Så før du bebrejder værktøjet for skuffende resultater, så tag et ærligt kig på dine spaker. Hvilken er kortest? Der er din mulighed.