Slutet för app-utvecklaren: Varför nästa decennium tillhör de som bygger AI-agenter

Historien har en lustig förmåga att rimma, oftast precis när vi har gjort oss hemmastadda.

Föreställ dig slutet av 90-talet. Om du visste hur man brottade ner HTML och lite Perl eller PHP till en fungerande hemsida, då var du en trollkarl. Du var en Web Engineer, och världen låg för dina fötter. Du byggde internetets skyltfönster.

Spola fram till 2009. iPhonen hade precis öppnat upp världen på vid gavel. Plötsligt brydde sig ingen lika mycket om din statiska hemsida. Energin skiftade till Objective-C och Java. Om du var en Mobile App Engineer skrev du framtiden. Du byggde verktygen som folk bar med sig i fickan.

Titta nu på 2024. Luften känns tunn och stillastående igen. App-butikerna är mättade; webben är överbefolkad. Men under ytan sker ett tektoniskt skifte. Vi lämnar Gränssnittens era och går in i Agenternas era.

Under det kommande decenniet kommer den mest värdefulla titeln inte vara "Full Stack Developer" eller "iOS Engineer". Det kommer att vara AI Agent Engineer.

Det nya tektoniska skiftet

Detta är inte bara ännu ett ramverkskrig eller ett nytt programmeringsspråk att lära sig. Detta är en fundamental förändring av vem som gör jobbet.

Under de senaste tjugo åren handlade mjukvaruutveckling om att bygga tydliga, deterministiska vägar för människor att klicka sig igenom. Du byggde en knapp; människan klickade på den; koden körde en funktion. Människan var hjärnan; mjukvaran var musklerna.

Den dynamiken håller på att vändas upp och ner.

I den agentiska eran står mjukvaran för hjärnan. Ditt jobb är inte längre att bygga knappen som människan ska klicka på. Ditt jobb är att bygga den digitala medarbetaren som bestämmer när knappen ska klickas på, eller ännu hellre, räknar ut att knappen inte ens behövs.

Jag har byggt produkter i över tio år, och jag kan känna hur marken rör sig. Om du kan skriva en agent idag – en som tjänar dig, automatiserar ditt arbetsflöde eller hjälper dina kunder – har du samma hävstång som den där grabben 1999 som precis lärt sig hur man lägger ut ett företag på nätet.

Men här är den hårda sanningen: Om du vägrar att lära dig detta, om du klamrar dig fast vid rent deterministisk kodning, riskerar du att bli den digitala motsvarigheten till en sättare i desktop publishing-åldern.

Avmystifiera magin: Verktyg och Kontext

När folk hör "AI Agent" föreställer de sig Skynet eller någon omöjligt komplex neural nätverksarkitektur. Låt oss skära igenom bruset.

Att bygga en agent är inte magi. Det är ingenjörskonst. Och det kokar ner till två saker: Verktyg och Kontext.

Jag har märkt att de flesta utvecklare överkomplicerar detta. De tror att de behöver träna modeller. Det behöver du inte. Modellerna – Claude, GPT-4, Llama – är smarta nog. Ditt jobb är att ge dem händer och ett minne.

1. Verktyg (Ge modellen händer)

En stor språkmodell (LLM) är bara en hjärna i en burk. Den kan tänka, men den kan inte röra vid världen. En "Agent" är helt enkelt en LLM som har fått tillgång till API-endpoints eller CLI-kommandon.

Du säger till modellen: "Här är ett verktyg som heter list_files. Här är ett verktyg som heter read_file. Här är ett verktyg som heter send_email."

2. Kontext (Ge modellen riktning)

Sedan definierar du rollen. "Du är en senior QA-ingenjör. Ditt mål är att fixa typfelen i det här repot."

Det är allt. Det är kärnloopen.

Om du har använt Cursor eller Claude Code har du sett detta "in action". Du detaljstyr inte redigeringarna. Du säger: "Fixa typfelen i utils.ts."

Agenten tänker: Okej, jag måste se filen först. Den bestämmer sig för att använda verktyget ls. Sedan bestämmer den sig för att använda grep eller read. Den hittar felet. Den bestämmer sig för att skriva fixen. Den kör kompilatorn för att kontrollera sitt arbete.

Detta är genombrottet. Det är inte bara "chatt" längre. Det är en beslutsloop. Modellen väljer vilka verktyg den ska plocka upp för att lösa problemet du gav den.

Från Chatbots till Beslutsmotorer

De senaste två åren har vi suttit fast i "Chat"-fasen. Vi behandlar AI som en smart bibliotekarie – vi ställer en fråga, den ger ett svar.

Den fasen håller på att ta slut.

Den agentiska fasen handlar om utförande. Det handlar om att se på ett CLI inte som en plats för dig att skriva, utan som en lekplats för modellen.

Tänk på implikationerna för startups. Förr i tiden, om jag ville bygga en tjänst för att hantera återbetalningar till kunder, behövde jag bygga ett UI, en backend, en databas och anställa ett supportteam för att klicka på knapparna.

Idag kan jag skriva en agent. Jag ger den tillgång till Stripe-API:et (Verktyg) och vår e-posthistorik (Kontext). Jag ger den en policy: "Gör en återbetalning om användaren är missnöjd inom 7 dagar." Agenten läser det inkommande mailet, avgör om det uppfyller kriterierna, triggar Stripe-återbetalningsverktyget och utformar ett svar.

Inget UI behövs. Ingen kö för supportärenden. Bara ett mål och en uppsättning verktyg.

Det "stökiga mellanläget" i att bygga agenter

Jag vill inte måla upp en utopi här. Jag har tillbringat de senaste sex månaderna djupt nere i skyttegravarna med agentbyggande, och låt mig säga er: det är stökigt.

Traditionell kodning är logisk. If X then Y. Det fungerar eller så går det sönder.

Agent-engineering är probabilistisk (sannolikhetsbaserad). Du bygger agenten, du ger den verktygen, och ibland bestämmer den sig för att använda en hammare för att öppna ett fönster. Ibland hallucinerar den fram en parameter som inte existerar.

Det är här den nya kompetensen ligger.

Att vara en Agent Engineer handlar inte bara om Python-skript. Det handlar om:

• Prompt Engineering som Arkitektur: Att designa systemprompter för att begränsa modellens beteende.
• Eval Driven Development: Du kan inte skriva enhetstester för kreativitet, så du bygger utvärderingspipelines för att mäta hur ofta agenten lyckas med en uppgift.
• Verktygsdesign: Att skapa API-gränssnitt som är tillräckligt "rena" för att en modell ska förstå dem utan att bli förvirrad.

Jag har sett agenter fastna i oändliga loopar när de försöker fixa en bugg de själva skapat. Jag har sett dem självsäkert radera fel fil. Detta är verkligheten. Men att lösa dessa friktionspunkter är exakt där värdet skapas.

Praktiska råd: Hur du börjar idag

Om jag skulle börja från noll idag, eller funderade på att byta karriärspår, är detta exakt vad jag skulle göra:

1. Sluta bygga GUI:n: Åtminstone för dina sidoprojekt. Försök att lösa ett problem utan en frontend. Kan du lösa det med ett CLI och en LLM?
2. Lär dig gränssnittsprotokollet: Förstå hur OpenAIs "function calling" eller Anthropics "tool use" fungerar. Detta är agentålderns TCP/IP.
3. Bygg en "görare" inte en "pratare": Bygg inte en bot som svarar på frågor om din kalender. Bygg en bot som hanterar din kalender. Ge den förmågan att radera händelser. Känn rädslan av att ge en AI skrivrättigheter. Det är då du verkligen börjar lära dig.
4. Bemästra kontext-hantering: Lär dig hur du matar in rätt information i kontextfönstret utan att överfylla det. RAG (Retrieval-Augmented Generation) är bara början.

Möjligheten framför oss

Vi tittar på en framtid där en enda utvecklare, beväpnad med en flotta av specialiserade agenter, kan göra samma jobb som en startup med 20 anställda.

Inträdesbarriärerna för skapande sjunker mot noll. Men inträdesbarriärerna för orkestrering – för att förstå hur man kopplar ihop dessa hjärnor – håller på att bli den nya vallgraven.

För tio år sedan anställdes du för att skriva koden. Idag anlitas du för att vara arkitekten bakom systemet som skriver koden.

Tåget lämnar perrongen. Du kan antingen stå kvar och klamra dig fast vid dina gamla ramverk, eller så kan du hoppa på och hjälpa till att bygga rälsen.

Nu bygger vi.