App-udviklerens endeligt: Hvorfor de næste 10 år tilhører dem, der bygger agenter

Historien har det med at rime, som regel lige når vi har sat os godt til rette.

Forestil dig slutningen af 90'erne. Hvis du kunne tvinge HTML og en smule Perl eller PHP til at blive til en fungerende hjemmeside, var du en troldmand. Du var Web Engineer, og verden lå for dine fødder. Du byggede internettets butiksfacader.

Spol frem til 2009. iPhone havde lige åbnet verden op på ny. Pludselig var der ingen, der gik lige så meget op i din statiske hjemmeside. Energien skiftede til Objective-C og Java. Hvis du var Mobile App Engineer, skrev du fremtiden. Du byggede de værktøjer, folk bar rundt på i deres lommer.

Se så på 2024. Luften føles tynd og statisk igen. App stores er mættede; nettet er overfyldt. Men under overfladen sker der et tektonisk skift. Vi forlader Interfacets æra og træder ind i Agentens æra.

I det næste årti vil den mest værdifulde titel ikke være "Full Stack Developer" eller "iOS Engineer". Det vil være AI Agent Engineer.

Det nye tektoniske skift

Dette er ikke bare endnu en framework-krig eller et nyt programmeringssprog, du skal lære. Det er en fundamental ændring i, hvem der udfører arbejdet.

I de sidste tyve år har softwareudvikling handlet om at bygge klare, deterministiske stier, som mennesker kunne klikke sig igennem. Du byggede en knap; mennesket klikkede på den; koden udførte en funktion. Mennesket var hjernen; softwaren var musklerne.

Den dynamik er ved at vende.

I den "agentiske" tidsalder leverer softwaren hjernen. Dit job er ikke længere at bygge knappen, som mennesket skal klikke på. Dit job er at bygge den digitale medarbejder, der beslutter hvornår der skal klikkes på knappen – eller endnu bedre: finder ud af, at knappen slet ikke er nødvendig.

Jeg har bygget produkter i over ti år, og jeg kan mærke jorden ryste. Hvis du kan skrive en agent i dag – en der tjener dig, automatiserer dit workflow eller betjener dine kunder – så har du den samme løftestangseffekt som knægten i 1999, der lige havde lært at lægge en virksomhed online.

Men her er den barske sandhed: Hvis du nægter at lære dette, hvis du holder fast i rent deterministisk kodning, risikerer du at blive den digitale pendant til en blysætter i desktop publishing-alderen.

Afmystificering af magien: Værktøjer og kontekst

Når folk hører "AI Agent", forestiller de sig Skynet eller en umuligt kompleks neural netværksarkitektur. Lad os skære igennem støjen.

At bygge en agent er ikke magi. Det er ingeniørarbejde. Og det koger ned til to ting: Værktøjer og Kontekst.

Jeg har oplevet, at de fleste udviklere overkomplicerer dette. De tror, de skal træne modeller. Det skal du ikke. Modellerne – Claude, GPT-4, Llama – er kloge nok. Dit job er at give dem hænder og en hukommelse.

1. Værktøjer (Giv modellen hænder)

En Large Language Model (LLM) er bare en hjerne i et syltetøjsglas. Den kan tænke, men den kan ikke røre verden. En "Agent" er simpelthen en LLM, der har fået adgang til API-endpoints eller CLI-kommandoer.

Du fortæller modellen: "Her er et værktøj kaldet list_files. Her er et værktøj kaldet read_file. Her er et værktøj kaldet send_email."

2. Kontekst (Giv modellen retning)

Derefter definerer du rollen. "Du er en senior QA engineer. Dit mål er at rette typefejlene i dette repository."

Det er det. Det er kernen i loopet.

Hvis du har brugt Cursor eller Claude Code, har du set dette i aktion. Du mikrostyrer ikke redigeringerne. Du siger: "Fix the type errors in utils.ts."

Agenten tænker: Okay, jeg er nødt til at se filen først. Den beslutter at bruge ls værktøjet. Så beslutter den at bruge grep eller read. Den finder fejlen. Den beslutter at skrive rettelsen. Den kører compileren for at tjekke sit arbejde.

Dette er gennembruddet. Det er ikke bare "chat" længere. Det er et beslutningsloop. Modellen vælger selv, hvilke værktøjer den vil samle op for at løse det problem, du gav den.

Fra chatbots til beslutningsmotorer

I de sidste to år har vi siddet fast i "Chat"-fasen. Vi behandler AI som en klog bibliotekar – vi stiller et spørgsmål, den giver et svar.

Den fase er ved at slutte.

Agent-fasen handler om eksekvering. Det handler om at se på en CLI, ikke som et sted hvor du skriver, men som en legeplads for modellen.

Tænk over konsekvenserne for startups. Før i tiden, hvis jeg ville bygge en service til at håndtere kunderefusioner, skulle jeg bygge en UI, en backend, en database og hyre et supportteam til at klikke på knapperne.

I dag kan jeg skrive en agent. Jeg giver den adgang til Stripe API'et (Værktøj) og vores e-mailhistorik (Kontekst). Jeg giver den en politik: "Refunder hvis brugeren er utilfreds inden for 7 dage." Agenten læser den indgående e-mail, beslutter om den opfylder kriterierne, udløser Stripe-refusionsværktøjet og skriver et svar.

Ingen UI nødvendig. Ingen kø af supportbilletter. Bare et mål og et sæt værktøjer.

Den "rodede midte" ved at bygge agenter

Jeg vil ikke male et glansbillede her. Jeg har brugt de sidste seks måneder dybt nede i skyttegravene med agent-byggeri, og lad mig sige det som det er: det er rodet.

Traditionel kodning er logisk. If X then Y. Det virker, eller også går det i stykker.

Agent engineering er probabilistisk (sandsynlighedsbaseret). Du bygger agenten, du giver den værktøjerne, og nogle gange beslutter den sig for at bruge en hammer til at åbne et vindue. Nogle gange hallucinerer den en parameter, der ikke eksisterer.

Det er her, det nye kompetencesæt ligger.

At være Agent Engineer handler ikke bare om Python-scripts. Det handler om:

• Prompt Engineering som Arkitektur: Design af system-prompts for at begrænse modellens adfærd.
• Eval Driven Development: Du kan ikke skrive unit tests for kreativitet, så du bygger evaluerings-pipelines for at måle, hvor ofte agenten lykkes med en opgave.
• Værktøjsdesign: At skabe API-interfaces, der er "rene" nok til, at en model kan forstå dem uden at blive forvirret.

Jeg har set agenter sidde fast i uendelige loops, mens de prøver at rette en bug, de selv har skabt. Jeg har set dem selvsikkert slette den forkerte fil. Det er virkeligheden. Men at løse disse friktionspunkter er præcis der, hvor værdien skabes.

Praktiske råd: Sådan kommer du i gang i dag

Hvis jeg skulle starte forfra i dag, eller ønskede at pivotere min karriere, er her præcis, hvad jeg ville gøre:

1. Stop med at bygge GUI'er: I det mindste for dine sideprojekter. Prøv at løse et problem uden en frontend. Kan du løse det med en CLI og en LLM?
2. Lær Interface-protokollen: Forstå hvordan OpenAIs "function calling" eller Anthropics "tool use" fungerer. Dette er agent-tidsalderens TCP/IP.
3. Byg en der "handler", ikke en der "snakker": Lad være med at bygge en bot, der svarer på spørgsmål om din kalender. Byg en bot, der styrer din kalender. Giv den evnen til at slette begivenheder. Mærk frygten ved at give en AI skriveadgang. Det er der, du virkelig begynder at lære.
4. Mestre Kontekst-håndtering: Lær hvordan du propper den rigtige information ind i kontekst-vinduet uden at overfylde det. RAG (Retrieval-Augmented Generation) er kun begyndelsen.

Muligheden forude

Vi kigger ind i en fremtid, hvor en enkelt udvikler, bevæbnet med en flåde af specialiserede agenter, kan udføre arbejdet for en startup med 20 ansatte.

Barrieren for at skabe falder mod nul. Men barrieren for orkestrering – for at forstå hvordan man forbinder disse hjerner – er ved at blive den nye voldgrav.

For ti år siden blev du hyret til at skrive koden. I dag bliver du hyret til at arkitektere systemet, der skriver koden.

Toget kører nu. Du kan enten blive stående på perronen og klamre dig til dine gamle frameworks, eller du kan hoppe på og hjælpe med at bygge skinnerne.

Lad os bygge.