Het einde van de App Engineer: Waarom de komende 10 jaar zijn voor de bouwers van Agents

De geschiedenis heeft de grappige gewoonte om te rijmen, meestal precies wanneer we net comfortabel zijn geworden.

Stel je de late jaren 90 voor. Als je wist hoe je HTML en een beetje Perl of PHP in een werkende website kon worstelen, was je een tovenaar. Je was een Web Engineer en de wereld lag aan je voeten. Je bouwde de etalages van het internet.

Spoel door naar 2009. De iPhone had net de wereld opengebroken. Plotseling gaf niemand meer zoveel om je statische website. De energie verschoof naar Objective-C en Java. Als je een Mobile App Engineer was, schreef je de toekomst. Je bouwde de tools die mensen in hun broekzak droegen.

Kijk nu naar 2024. De lucht voelt weer ijl en statisch aan. De app stores zijn verzadigd; het web is overvol. Maar onder de oppervlakte vindt er een tektonische verschuiving plaats. We verlaten het tijdperk van de Interface en betreden het tijdperk van de Agent.

In het komende decennium zal de meest waardevolle titel niet "Full Stack Developer" of "iOS Engineer" zijn. Het zal AI Agent Engineer zijn.

De Nieuwe Tektonische Verschuiving

Dit is niet zomaar weer een framework war of een nieuwe programmeertaal om te leren. Dit is een fundamentele verandering in wie het werk doet.

De afgelopen twintig jaar draaide software engineering om het bouwen van duidelijke, deterministische paden waar mensen doorheen konden klikken. Jij bouwde een knop; de mens klikte erop; de code voerde een functie uit. De mens was het brein; de software was de spier.

Die dynamiek draait nu om.

In het 'Agentic Era' levert de software het brein. Jouw taak is niet langer om de knop te bouwen waar de mens op klikt. Jouw taak is om de digitale werknemer te bouwen die beslist wanneer er op de knop geklikt moet worden, of beter nog, die uitvogelt dat die knop niet eens nodig is.

Ik bouw al meer dan tien jaar producten en ik voel de grond bewegen. Als je vandaag een agent kunt schrijven—een die jou dient, je workflow automatiseert of je klanten helpt—heb je dezelfde hefboomwerking als die jongen in 1999 die net had geleerd hoe je een bedrijf online zet.

Maar hier is de harde waarheid: Als je weigert dit te leren, als je vasthoudt aan puur deterministisch coderen, loop je het risico het digitale equivalent te worden van een letterzetter in het tijdperk van desktop publishing.

De Magie Ontrafeld: Tools en Context

Wanneer mensen "AI Agent" horen, stellen ze zich Skynet voor of een onmogelijk complexe neurale netwerkarchitectuur. Laten we door de ruis heen snijden.

Een agent bouwen is geen magie. Het is engineering. En het komt neer op twee dingen: Tools en Context.

Ik merk dat de meeste developers dit te ingewikkeld maken. Ze denken dat ze modellen moeten trainen. Dat hoeft niet. De modellen—Claude, GPT-4, Llama—zijn slim genoeg. Jouw taak is om ze handen en een geheugen te geven.

1. Tools (Het Model Handen Geven)

Een Large Language Model (LLM) is gewoon een brein in een pot. Het kan denken, maar het kan de wereld niet aanraken. Een "Agent" is simpelweg een LLM die toegang heeft gekregen tot API-endpoints of CLI-commando's.

Je vertelt het model: "Hier is een tool genaamd list_files. Hier is een tool genaamd read_file. Hier is een tool genaamd send_email."

2. Context (Het Model Richting Geven)

Vervolgens definieer je de rol. "Je bent een senior QA engineer. Je doel is om de typefouten in deze repository op te lossen."

Dat is het. Dat is de kern-loop.

Als je Cursor of Claude Code hebt gebruikt, heb je dit in actie gezien. Je bent niet aan het micromanagen. Je zegt: "Fix the type errors in utils.ts."

De agent denkt: Oké, ik moet eerst het bestand zien. Hij besluit de ls tool te gebruiken. Dan besluit hij grep of read te gebruiken. Hij ziet de fout. Hij besluit de fix te schrijven. Hij draait de compiler om zijn werk te controleren.

Dit is de doorbraak. Het is niet meer gewoon "chatten". Het is een beslissingslus. Het model kiest welke tools het oppakt om het probleem op te lossen dat jij het gaf.

Van Chatbots naar Beslissingsmotoren

De afgelopen twee jaar zaten we vast in de "Chat"-fase. We behandelen AI als een slimme bibliothecaris—we stellen een vraag, hij geeft een antwoord.

Die fase loopt ten einde.

De Agent-fase draait om executie. Het gaat erom dat je naar een CLI kijkt, niet als een plek voor jou om te typen, maar als een speeltuin voor het model.

Denk na over de implicaties voor startups. In het verleden, als ik een service wilde bouwen om terugbetalingen aan klanten te regelen, moest ik een UI bouwen, een backend, een database, en een supportteam inhuren om op de knoppen te klikken.

Vandaag kan ik een agent schrijven. Ik geef hem toegang tot de Stripe API (Tool) en onze e-mailgeschiedenis (Context). Ik geef hem een beleid: "Betaal terug als de gebruiker binnen 7 dagen ontevreden is." De agent leest de binnenkomende e-mail, beslist of deze aan de criteria voldoet, activeert de Stripe refund tool en stelt een antwoord op.

Geen UI nodig. Geen wachtrij voor supporttickets. Gewoon een doel en een set tools.

De "Messy Middle" van het Bouwen van Agents

Ik wil hier geen utopie schetsen. Ik heb de afgelopen zes maanden diep in de loopgraven van agent-building doorgebracht, en laat me je vertellen: het is rommelig.

Traditioneel coderen is logisch. If X then Y. Het werkt of het breekt.

Agent engineering is probabilistisch. Je bouwt de agent, je geeft hem de tools, en soms besluit hij een hamer te gebruiken om een raam te openen. Soms hallucineert hij een parameter die niet bestaat.

Dit is waar de nieuwe skill set ligt.

Een Agent Engineer zijn gaat niet alleen over Python scripts. Het gaat over:

• Prompt Engineering als Architectuur: Het ontwerpen van systeemprompts om het gedrag van het model in te perken.
• Eval Driven Development: Je kunt geen unit tests schrijven voor creativiteit, dus bouw je evaluatie-pipelines om te meten hoe vaak de agent slaagt in een taak.
• Tool Design: API-interfaces creëren die "schoon" genoeg zijn voor een model om te begrijpen zonder in de war te raken.

Ik heb agents vast zien lopen in oneindige loops terwijl ze probeerden een bug op te lossen die ze zelf hadden gecreëerd. Ik heb ze vol zelfvertrouwen het verkeerde bestand zien verwijderen. Dit is de realiteit. Maar het oplossen van deze wrijving is precies waar de waarde wordt gecreëerd.

Praktische Takeaways: Hoe Vandaag te Beginnen

Als ik vandaag vanaf nul zou beginnen, of mijn carrière zou willen omgooien, is dit precies wat ik zou doen:

1. Stop met het bouwen van GUI's: Althans voor je side projects. Probeer een probleem op te lossen zonder frontend. Kun je het oplossen met een CLI en een LLM?
2. Leer het Interface Protocol: Begrijp hoe OpenAI's function calling of Anthropic's tool use werkt. Dit is de TCP/IP van het agent-tijdperk.
3. Bouw een "Doener", geen "Prater": Bouw geen bot die vragen beantwoordt over je agenda. Bouw een bot die je agenda beheert. Geef hem de mogelijkheid om afspraken te verwijderen. Voel de angst van het geven van schrijftoegang aan een AI. Dat is wanneer je echt begint te leren.
4. Beheers Context Management: Leer hoe je de juiste informatie in het context window propt zonder dat het overstroomt. RAG (Retrieval-Augmented Generation) is nog maar het begin.

De Kans die Voor ons Ligt

We kijken naar een toekomst waarin één enkele developer, gewapend met een vloot van gespecialiseerde agents, het werk kan doen van een startup met 20 man personeel.

De drempels voor creatie zakken naar nul. Maar de drempels voor orkestratie—voor het begrijpen hoe je deze breinen aan elkaar knoopt—worden de nieuwe slotgracht.

Tien jaar geleden werd je aangenomen om de code te schrijven. Vandaag word je aangenomen om het systeem te ontwerpen dat de code schrijft.

De trein vertrekt uit het station. Je kunt op het perron blijven staan, je oude frameworks stevig vasthoudend, of je kunt opspringen en helpen de rails te leggen.

Laten we bouwen.