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.

🏆 Of is verantwoordelijkheidsgevoel genoeg?

Laatst kwam ik een pleidooi tegen voor de noodzaak van een “Definition of Ready” voor startende Agile teams, gevolgd en een geleidelijke transitie naar een uitgebreide “Definition of Done” bij het groeien van de maturity. 🦄

De strekking was dat niet-Agile teams vooraf duidelijk moeten weten wat er verwacht wordt, en als er eenmaal Agile gewerkt wordt het vooral belangrijk is dat het werk compleet wordt afgerond voor we doorgaan naar de volgende taak op het bord.

Ik vind dit een fascinerende theorie, vooral omdat ik zoveel teams prachtige definities van beide smaken heb zien formuleren, om er vervolgens helemaal niets mee te doen. 🤡

Voor mij vallen beide checklists onder een gebrek aan verantwoordelijkheid van de teamleden zelf, en geven daarmee een extra zetje om te falen. Verantwoordelijkheid nemen en kleine stapjes zijn voor mij de werkelijke kern van Agile werken. In mijn ervaring ontstaan er daarna vanzelf borgingen die falen voorkomen. 🌈

💡 Mij lijkt het daarom belangrijker nóg kleinere taken op te pakken en onderling beter te communiceren. – De rest volgt vanzelf.