En serieus geld worden bespaard!💰

⚽️ Een tijdje geleden heb ik voor een bedrijf in Eindhoven een app met een achterliggende backend gemaakt om tientallen verschillende soorten metingen aan professionele voetbalvelden te verzamelen en visualiseren.

Het project begon als vervanger van een bestaand dashboard dat door een derde partij in licentie was gemaakt en (tegen hoge kosten) werd beheerd, maar al snel ontdekten we samen met een betrokken UX ontwerper dat er betere visualisaties te maken waren dan eindeloze grafieken met vele onleesbare lijnen. 🚀

In slechts enkele man-maanden heb ik in mijn eentje zowel de backend als de app gerealiseerd, waarvan het eigendom weer volledig bij mijn opdrachtgever lag. Zo maakten we een serieuze stap voorwaarts, terwijl de kosten hiervoor binnen afzienbare tijd werden terugverdiend.⏳

✨En als ik bedenk welk verschil de recente opkomst van AI tools maakt, dan had het vandaag de dag met dezelfde investering nog een grotere stap kunnen zijn.

Mijn stapjes naar de toekomst van software ontwikkeling

🏆 Al jaren sta ik voor kwaliteit en onderhoudbaarheid van code. Dat heeft mijn manier van werken als programmeur en architect gevormd. Hierin brengt het samenwerken met AI de laatste tijd een nieuwe (maar erg leerzame) wending.

Ik ervaar LLMs als Claude Sonnet als een extreem productieve junior collega met verschrikkelijk veel kennis: In minuten komt er code uit waar ik zelf tot dagen aan zou werken, en gaat het regelmatig ondanks mijn (poging tot) sturing fout op structuur, consistentie en overzicht.

💡Dit wijzigde mijn manier van werken van evolutionaire “code-first” op basis van TDD en groeiend inzicht, naar “architecture-first” om de LLM voldoende vangrails mee te geven.

Na de eerste “productieve” stap door de LLM volgt mijn exploratie van de gekozen oplossing, en een intensieve interactie om in steeds meer detail de code weer in goede banen te leiden.

Net als bij het samenwerken met mensen komt hier een behoorlijke dosis nieuwsgierigheid en geduld bij kijken. Ik kan mij goed voorstellen dat “Vibe Coders” hier de grootste uitdaging in gaan hebben, en juist daar de ongelukken door zullen gebeuren. 💣

Is AI de doodsteek voor offshoring?☠️

Mijn eerste ervaringen met het outsourcen van software ontwikkeling naar India is meer dan 25 jaar geleden. Eerst in Mumbai, en daarna heb ik Bangalore van grote stad to metropool uit zien groeien. De management droom was telkens dat de kosten van arbeid lager zouden zijn, en later volgde het argument dat er daar nog capaciteit voorhanden was.🚀

Een vanaf het begin terugkerend probleem waren de cultuurverschillen die aanleiding gaven tot misverstanden over specificaties en wensen: Je krijgt wat je vraagt, en als je niet voldoende aandacht aan de vraag besteedt dan krijg je nog steeds wat je vraagt. Een gevolg was dat bedrijven de hulp langzamerhand cultureel ook dichter bij huis gingen zoeken, zoals in Oost-Europa. Maar de totale vraag bleef groeien, zo ook de outsourcing. 📈

💣 Met de huidige groei van AI code generatie tools, worden individuele (ervaren) ontwikkelaars vele malen productiever, en lijkt de capaciteit bottleneck door goedkope AI opgelost te gaan worden. Dit zou wel eens het einde kunnen betekenen van de historische behoefte aan die extra capaciteit tegen lage kosten.

Onlangs las ik dat de huizenmarkt in Bangalore vorig jaar al een klap heeft gehad door krimp van IT bedrijven. Ik maak mij hierdoor zorgen over de toekomst voor mijn vrienden in India.

🍀 Is dit het verschil dat AI werkelijk maakt?

De keren dat ik in hyper-performant teams heb mogen werken blijven me bij als een bijzondere ervaring. Het voelde telkens als heel intens en productief, en het bracht me daarnaast ook veel plezier en voldoening. 🚀

Het is mij opgevallen dat die teams allemaal een zelfde dagritme hadden:

1. De ochtend start met frisse nieuwe ideeën en (hierdoor) intense discussie.
2. Er valt vrij snel een beslissing over “wat we uit gaan proberen”.
3. Dit uitproberen is een focus activiteit waarbij alle afleiding wordt genegeerd.
4. Al ruim voor de middag staat de basis van de oplossing.
5. De rest van de dag wordt besteedt aan refactoring en oplossen van alle ontdekte losse eindjes.
6. Aan het einde van de dag is de code helemaal klaar voor de volgende iteratie.

Nu ik experimenteer met AI code generatie, begin ik dit zelfde patroon te ontdekken: Ik gebruik AI om interactief een sprong te maken, waarna een heleboel samenwerking volgt om “de schade weer op te ruimen”.🤖

💡Eigenlijk ligt dit helemaal niet zo ver van wat ik hierboven beschreef, behalve dat er minder mensen bij betrokken zijn, en de eerste sprong minder doorlooptijd vergt. De cycli zijn dan ook regelmatig korter dan een dag.

👑 Moet code van LLMs wel onderhoudbaar zijn?

Recent merkte iemand op dat de enige reden voor Clean Code, Design Patterns, SOLID, en dergelijke aanbevelingen is om te zorgen dat het mogelijk blijft om afgebakende stukken software te kunnen vervangen door een verbeterde versie. 🚀

Dat inzicht sprak mij aan, want dat is precies wat ik al jaren ervaar: Door software netjes te structureren blijft het mogelijk om de stroom nieuwe inzichten in de bestaande code in te passen. 🌈

En als het eenmaal chaos is, dan stagneert de evolutie tot het oplossen van steeds weer nieuwe bugs in plaats van het verder groeien van het systeem. 💩

Met de opkomst van generatie van code door AI (“Vibe coding” etc) krijg ik de indruk dat er een stemming ontstaat dat structuur minder belangrijk wordt. Een LLM is immers veel beter in het interpreteren van chaos dan mensen.

💡 Mijn mening is dat structuur te maken heeft met het systeem, en niet met de programmeur. Ook als de programmeur (veel) slimmer is, blijft de informatie opgeslagen in structuur een belangrijk ingredient voor evolutie. Niet alleen voor mensen, maar zeker ook als context voor een LLM.

🔮 Misschien is het sturen van de structuur van code wel het belangrijkste wat wij als als mens aan software bij kunnen dragen.