Slutten for app-utvikleren: Hvorfor de neste 10 årene tilhører de som bygger agenter

Historien har en tendens til å gjenta seg – ofte akkurat når vi har funnet oss til rette.

Se for deg slutten av 90-tallet. Hvis du visste hvordan du skulle temme HTML og litt Perl eller PHP til å bli en fungerende nettside, var du en trollmann. Du var en Web Engineer, og verden lå for dine føtter. Du bygget internettets butikkvinduer.

Spol frem til 2009. iPhone hadde nettopp åpnet opp verden på ny. Plutselig brydde ingen seg like mye om den statiske nettsiden din. Energien flyttet seg til Objective-C og Java. Hvis du var en Mobile App Engineer, skrev du fremtiden. Du bygget verktøyene folk bar med seg i lomma.

Se nå på 2024. Luften føles tynn og statisk igjen. App-butikkene er mettet; nettet er overfylt. Men under overflaten skjer det et tektonisk skifte. Vi forlater Grensesnitt-æraen og går inn i Agent-æraen.

I det neste tiåret vil ikke den mest verdifulle tittelen være "Full Stack Developer" eller "iOS Engineer". Det vil være AI Agent Engineer.

Det nye tektoniske skiftet

Dette er ikke bare enda en rammeverkskrig eller et nytt programmeringsspråk du må lære deg. Dette er en fundamental endring i hvem som gjør jobben.

De siste tjue årene handlet software engineering om å bygge klare, deterministiske stier som mennesker kunne klikke seg gjennom. Du bygget en knapp; mennesket klikket på den; koden kjørte en funksjon. Mennesket var hjernen; programvaren var musklene.

Den dynamikken er i ferd med å snu.

I den agentiske tidsalderen stiller programvaren med hjernen. Jobben din er ikke lenger å bygge knappen mennesket skal klikke på. Jobben din er å bygge den digitale ansatte som bestemmer når knappen skal klikkes, eller enda bedre – finner ut at knappen ikke engang er nødvendig.

Jeg har bygget produkter i over ti år, og jeg kan kjenne at grunnen beveger seg. Hvis du kan skrive en agent i dag – en som tjener deg, automatiserer arbeidsflyten din, eller betjener kundene dine – har du den samme innflytelsen som den gutten i 1999 som nettopp hadde lært seg hvordan man legger ut en bedrift på nettet.

Men her er den brutale sannheten: Hvis du nekter å lære dette, hvis du klamrer deg til rent deterministisk koding, risikerer du å bli den digitale ekvivalenten til en setter i desktop publishing-alderen.

Avmystifisering av magien: Verktøy og Kontekst

Når folk hører "AI Agent", ser de for seg Skynet eller en umulig kompleks nevral nettverksarkitektur. La oss skjære gjennom støyen.

Å bygge en agent er ikke magi. Det er ingeniørkunst. Og det koker ned til to ting: Verktøy og Kontekst.

Jeg opplever at de fleste utviklere overkompliserer dette. De tror de må trene modeller. Det trenger du ikke. Modellene – Claude, GPT-4, Llama – er smarte nok. Jobben din er å gi dem hender og en hukommelse.

1. Verktøy (Gi modellen hender)

En stor språkmodell (LLM) er bare en hjerne på glass. Den kan tenke, men den kan ikke røre verden. En "Agent" er ganske enkelt en LLM som har fått tilgang til API-endepunkter eller CLI-kommandoer.

Du sier til modellen: "Her er et verktøy som heter list_files. Her er et verktøy som heter read_file. Her er et verktøy som heter send_email."

2. Kontekst (Gi modellen retning)

Deretter definerer du rollen. "Du er en senior QA-ingeniør. Målet ditt er å fikse typefeilene i dette repoet."

Det er alt. Det er kjernen i loopen.

Hvis du har brukt Cursor eller Claude Code, har du sett dette i aksjon. Du detaljstyrer ikke endringene. Du sier: "Fiks typefeilene i utils.ts."

Agenten tenker: Ok, jeg må se filen først. Den bestemmer seg for å bruke ls-verktøyet. Så bestemmer den seg for å bruke grep eller read. Den oppdager feilen. Den bestemmer seg for å skrive fiksen. Den kjører kompilatoren for å sjekke arbeidet sitt.

Dette er gjennombruddet. Det er ikke bare "chatting" lenger. Det er en beslutningssløyfe. Modellen velger hvilke verktøy den skal plukke opp for å løse problemet du ga den.

Fra Chatbots til Beslutningsmotorer

De siste to årene har vi sittet fast i "Chat"-fasen. Vi behandler AI som en smart bibliotekar – vi stiller et spørsmål, den gir et svar.

Den fasen er over.

Agent-fasen handler om utførelse. Det handler om å se på et CLI ikke som et sted hvor du skriver, men som en lekeplass for modellen.

Tenk på implikasjonene for startups. Tidligere, hvis jeg ville bygge en tjeneste for å håndtere kunderefusjoner, måtte jeg bygge et brukergrensesnitt (UI), en backend, en database, og ansette et supportteam til å klikke på knappene.

I dag kan jeg skrive en agent. Jeg gir den tilgang til Stripe API-et (Verktøy) og e-posthistorikken vår (Kontekst). Jeg gir den en policy: "Gi refusjon hvis brukeren er misfornøyd innen 7 dager." Agenten leser den innkommende e-posten, avgjør om den oppfyller kriteriene, utløser Stripe-refusjonsverktøyet, og skriver et svar.

Ingen UI nødvendig. Ingen kø med support-saker. Bare et mål og et sett med verktøy.

Den "rotete mellomfasen" med å bygge agenter

Jeg vil ikke male et glansbilde her. Jeg har tilbrakt de siste seks månedene dypt nede i skyttergravene med agentbygging, og la meg si det som det er: det er rotete.

Tradisjonell koding er logisk. Hvis X så Y. Det fungerer, eller så brekker det.

Agent engineering er probabilistisk (sannsynlighetsbasert). Du bygger agenten, du gir den verktøyene, og noen ganger bestemmer den seg for å bruke en hammer til å åpne et vindu. Noen ganger hallusinerer den en parameter som ikke finnes.

Det er her det nye kompetansesettet ligger.

Å være en Agent Engineer handler ikke bare om Python-script. Det handler om:

• Prompt Engineering som arkitektur: Designe system-prompter for å begrense modellens oppførsel.
• Eval-drevet utvikling: Du kan ikke skrive enhetstester for kreativitet, så du bygger evaluerings-pipelines for å måle hvor ofte agenten lykkes med en oppgave.
• Verktøydesign: Lage API-grensesnitt som er "rene" nok til at en modell forstår dem uten å bli forvirret.

Jeg har sett agenter sette seg fast i uendelige løkker mens de prøver å fikse en bug de selv skapte. Jeg har sett dem selvsikkert slette feil fil. Dette er realiteten. Men å løse disse friksjonspunktene er nøyaktig der verdien skapes.

Praktiske råd: Hvordan starte i dag

Hvis jeg startet fra scratch i dag, eller ønsket å endre retning på karrieren min, er dette nøyaktig hva jeg ville gjort:

1. Slutt å bygge GUI-er: I det minste for sideprosjektene dine. Prøv å løse et problem uten en frontend. Kan du løse det med et CLI og en LLM?
2. Lær deg grensesnitt-protokollen: Forstå hvordan OpenAIs "function calling" eller Anthropics "tool use" fungerer. Dette er agent-alderens TCP/IP.
3. Bygg en "Gjører", ikke en "Snakker": Ikke bygg en bot som svarer på spørsmål om kalenderen din. Bygg en bot som administrerer kalenderen din. Gi den muligheten til å slette hendelser. Kjenn på frykten ved å gi en AI skrivetilgang. Det er da du virkelig begynner å lære.
4. Mestre konteksthåndtering: Lær hvordan du stapper riktig informasjon inn i kontekstvinduet uten å overfylle det. RAG (Retrieval-Augmented Generation) er bare begynnelsen.

Mulighetene som ligger foran oss

Vi ser på en fremtid hvor en enkelt utvikler, utstyrt med en flåte av spesialiserte agenter, kan gjøre jobben til en startup med 20 ansatte.

Inngangsbarrierene for skapelse faller mot null. Men inngangsbarrierene for orkestrering – for å forstå hvordan man kobler disse hjernene sammen – er i ferd med å bli den nye vollgraven.

For ti år siden ble du ansatt for å skrive koden. I dag blir du ansatt for å arkitektere systemet som skriver koden.

Toget går nå. Du kan enten bli stående på perrongen og klamre deg til de gamle rammeverkene dine, eller du kan hoppe på og hjelpe til med å bygge skinnene.

La oss bygge.