De auteur betoogt dat softwareontwikkeling transformeert van een 'steenhouwer-model' (regel voor regel coderen) naar een 'timmerman-model' (het bouwen van bekistingen/structuren voor AI). In dit nieuwe paradigma verschuift de focus van hoe iets gebouwd wordt naar wat er gebouwd moet worden, waardoor ontwikkelaars meer taken van een Product Manager en Systeemarchitect overnemen.
Belangrijke implicaties van deze verschuiving zijn:
- Systeemontwerp: Er komt meer nadruk te liggen op validatie, verificatie en het ontwerp van interfaces in plaats van de implementatie.
- OODA-loop: De cyclus tussen een ontwerpbeslissing en het zien van het resultaat wordt aanzienlijk verkort.
- Outside-in benadering: Het externe gedrag van de software bepaalt de vorm van de gegenereerde code, in plaats van dat de interne structuur het gedrag bepaalt.
De auteur concludeert dat software engineering in het AI-tijdperk primair gaat over het uitoefenen van geïnformeerde controle over complexe systemen en het aanvaarden van de verantwoordelijkheid voor de resultaten, ongeacht of de implementatie door mensen of machines is gedaan.
Van steenhouwers naar timmerlieden
Mijn grootvader bracht zijn carrière door met het bouwen van bruggen, viaducten en duikers langs de centrale kust van Californië. Hoewel dit betonconstructies waren, was zijn beroep dat van timmerman. De reden dat hij timmerman was, is dat zij grote houten structuren bouwden die vervolgens een bekisting vormden (in feite een mal waar het beton in gegoten kon worden). Dit is iets waar ik steeds naar terugkeer wanneer ik nadenk over hoe de software-industrie verandert door AI, en specifiek door het vermogen om broncode te genereren.
Historisch gezien werden bruggen gebouwd door steenhouwers. Zij manipuleerden het materiaal (steen) direct terwijl de brug werd gebouwd. Naarmate ze meer stenen plaatsten, groeide de brug stapsgewijs totdat deze zijn uiteindelijke vorm bereikte. Beroemd is het feit dat de Romeinen bij hun constructies zelfs geen mortel nodig hadden.
De huidige bouwtechnieken zijn echter heel anders. Tegenwoordig worden de meeste bruggen van beton gemaakt. Toen mijn grootvader deze structuren bouwde, waren hij en zijn ploeg geen steenhouwers, noch bouwden ze de bruggen stukje bij stukje op. In plaats daarvan werden ze beschouwd als timmerlieden en besteedden ze het grootste deel van hun tijd aan het bouwen van de houten bekistingen, zodat het beton gegoten kon worden om de uiteindelijke brug te maken. Dit is een significante verandering ten opzichte van hoe steenhouwers bruggen bouwden.
De analogie toegepast op AI en coderen
Hoe is deze analogie van toepassing op programmeren in het tijdperk van AI? Ik stel dat softwareontwikkeling verschuift van een tijdperk van steenhouwers naar dat van timmerlieden.
Historisch gezien waren softwareontwikkelaars meer als steenhouwers: ze werkten direct met het medium (code in plaats van steen) en bouwden systemen incrementeel op, steen voor steen (regel voor regel code). Vanwege de opkomst van AI-codegeneratie stel ik echter voor dat ontwikkelaars zichzelf meer moeten zien als brugbouwende timmerlieden. In plaats van het systeem stapsgewijs op te bouwen, bouwen ze de bekistingen (het toevoegen van structuur aan het systeem via tests, documentatie en vangrails) die ervoor zorgen dat de code vervolgens correct kan worden gegenereerd. Dit vereist een verschuiving in hoe software wordt ontwikkeld, en ik geloof dat dit significante implicaties heeft.
Implicaties voor ontwikkeling
Iedereen is nu een Product Manager
Historisch gezien bestond er vaak het gevoel dat ontwikkeling het "echte" werk was, en dat projectmanagement op een bepaalde manier minder technisch of valide was. Nu elke ontwikkelaar echter gedwongen wordt zich te concentreren op de grenzen en interfaces van de software die ze bouwen, en niet alleen op de interne werking, wordt in feite van elke ontwikkelaar gevraagd een Product Manager te worden. In plaats van dat de belangrijkste vraag "hoe bouwen we dit" of "kunnen we dit bouwen" is, is de belangrijkste vraag nu "wat moeten we bouwen". Voor veel ontwikkelaars zal het noodzakelijk zijn om op deze manier te denken een grote verschuiving zijn.
Software Engineers doen meer Software Engineering
Een definitie van Software Engineering is:
"Software engineering is de tak van de informatica die praktische, kosteneffectieve oplossingen creëert voor computer- en informatieverwerkingsproblemen, bij voorkeur door wetenschappelijke kennis toe te passen en softwaresystemen te ontwikkelen in dienst van de mensheid."
Merk op dat deze definitie geen directe referentie maakt naar het schrijven van code, maar naar het bouwen van systemen. Het werk om praktische, kosteneffectieve oplossingen te creëren is nu relevanter dan ooit. Naarmate de kosten voor het schrijven van de broncode dalen, wordt de baan van de ontwikkelaar gedomineerd door het ontwerp van het systeem, evenals het ontwikkelen van manieren om ervoor te zorgen dat het ontwerp correct wordt gevalideerd en geverifieerd.
Voorheen maakten ontwikkelaars een ontwerpbeslissing, waarna er een periode van weken of misschien zelfs maanden van ontwikkeling volgde voordat de impact van die beslissing relevant werd. Nu maken ontwikkelaars ontwerpbeslissingen en wordt de code onmiddellijk gegenereerd, waardoor ze bijna direct de impact van die beslissingen zien. Dit verkort de OODA-loop van software engineers aanzienlijk. Het helpt ontwikkelaars ook om de impact van hun ontwerpbeslissingen duidelijk te zien, wat zorgt voor een nauwere oorzaak-gevolgrelatie tussen software-ontwerp en de eigenschappen van het systeem. Dit zal vereisen dat ontwikkelaars hun vaardigheden op het gebied van software-ontwerp veel sneller ontwikkelen, aangezien ontwerp een groter deel van hun dagelijkse werk wordt.
Systeemontwerp van buiten naar binnen
Een andere implicatie van deze verschuiving is dat veel software historisch gezien van binnen naar buiten werd ontworpen. Dit betekent dat de kernstructuur eerst werd bepaald, waarna het externe gedrag vaak sterk werd beïnvloed door de interne structuur van de code — vergelijkbaar met hoe steenhouwers bruggen steen voor steen bouwden. In dit nieuwe paradigma is het externe gedrag echter waar de engineer de meeste tijd aan besteedt (zoals de bekistingen die een timmerman bouwt). De gegenereerde code is daardoor meer een weerspiegeling van de vorm die de code zou moeten hebben volgens het ontwerp van de engineer, dan een weerspiegeling van hoe de code is opgebouwd.
Beperkingen van deze analogie
Zoals bij alle analogieën heeft ook deze enkele beperkingen. Een duidelijk punt waar de analogie mank gaat, is dat wanneer je een brug van beton bouwt, je deze één keer stort en je vastzit aan het ontwerp. Bij software kan men echter de externe beperkingen ontwikkelen en, hoewel er kosten verbonden zijn aan het opnieuw genereren van alle code, kan dit meerdere keren worden gedaan. Hierdoor kunnen lessen uit vorige iteraties worden toegepast op toekomstige versies van de software.
Conclusie
Nu we bewegen van een tijdperk van steenhouwers naar dat van timmerlieden, is het duidelijk dat de rol van de software engineer snel verandert. De rol van de ontwikkelaar is niet langer om de software regel voor regel op te bouwen als een steenhouwer, maar om zich te concentreren op het gebruik van software engineering om een compleet systeem te bouwen. Als software engineer vind ik deze verandering spannend en kijk ik uit naar de adoptie van software engineering-technieken die voorheen te kostbaar of moeilijk waren, maar die nu worden overgenomen door ontwikkelaars die met behulp van AI grootschalige softwaresystemen bouwen.
***
Aanvullende discussie: Een alternatieve definitie van Engineering
In de context van deze verschuiving is er een alternatieve definitie van Engineering vanuit de veiligheidswetenschap die relevant is voor het tijdperk van AI en agenten:
"Engineering: De discipline van het uitoefenen van geïnformeerde controle over consequentiële systemen en het aanvaarden van de verantwoordelijkheid voor de resultaten daarvan. Controle betekent het behouden van voldoende commando over een systeem om het te begrijpen en te sturen, bewijs te evalueren voor consequentiële eigenschappen, te herkennen wanneer aannames falen, en in te grijpen wanneer dat nodig is. Verantwoordelijkheid betekent aansprakelijk blijven voor de consequentiële beslissingen die onder iemands autoriteit zijn genomen en voor het resulterende systeem. Engineering vereist niet dat men elke handeling van implementatie persoonlijk uitvoert, en werk kan worden gedelegeerd aan andere mensen of aan machine-intelligentie. Software engineering past deze discipline toe op softwaresystemen."
— Uit het glossarium van: https://davisjam.github.io/model-based-agentic-software-engineering/book/mage-book/0.4-the-books-language.html
Van steenhouwers naar timmerlieden
Mijn grootvader bracht zijn carrière door met het bouwen van bruggen, viaducten en duikers langs de centrale kust van Californië. Hoewel dit betonconstructies waren, was zijn beroep dat van timmerman. De reden dat hij timmerman was, is dat zij grote houten structuren bouwden die vervolgens een bekisting vormden (in feite een mal waar het beton in gegoten kon worden). Dit is iets waar ik steeds naar terugkeer wanneer ik nadenk over hoe de software-industrie verandert door AI, en specifiek door het vermogen om broncode te genereren.
Historisch gezien werden bruggen gebouwd door steenhouwers. Zij manipuleerden het materiaal (steen) direct terwijl de brug werd gebouwd. Naarmate ze meer stenen plaatsten, groeide de brug stapsgewijs totdat deze zijn uiteindelijke vorm bereikte. Beroemd is het feit dat de Romeinen bij hun constructies zelfs geen mortel nodig hadden.
De huidige bouwtechnieken zijn echter heel anders. Tegenwoordig worden de meeste bruggen van beton gemaakt. Toen mijn grootvader deze structuren bouwde, waren hij en zijn ploeg geen steenhouwers, noch bouwden ze de bruggen stukje bij stukje op. In plaats daarvan werden ze beschouwd als timmerlieden en besteedden ze het grootste deel van hun tijd aan het bouwen van de houten bekistingen, zodat het beton gegoten kon worden om de uiteindelijke brug te maken. Dit is een significante verandering ten opzichte van hoe steenhouwers bruggen bouwden.
De analogie toegepast op AI en coderen
Hoe is deze analogie van toepassing op programmeren in het tijdperk van AI? Ik stel dat softwareontwikkeling verschuift van een tijdperk van steenhouwers naar dat van timmerlieden.
Historisch gezien waren softwareontwikkelaars meer als steenhouwers: ze werkten direct met het medium (code in plaats van steen) en bouwden systemen incrementeel op, steen voor steen (regel voor regel code). Vanwege de opkomst van AI-codegeneratie stel ik echter voor dat ontwikkelaars zichzelf meer moeten zien als brugbouwende timmerlieden. In plaats van het systeem stapsgewijs op te bouwen, bouwen ze de bekistingen (het toevoegen van structuur aan het systeem via tests, documentatie en vangrails) die ervoor zorgen dat de code vervolgens correct kan worden gegenereerd. Dit vereist een verschuiving in hoe software wordt ontwikkeld, en ik geloof dat dit significante implicaties heeft.
Implicaties voor ontwikkeling
Iedereen is nu een Product Manager
Historisch gezien bestond er vaak het gevoel dat ontwikkeling het "echte" werk was, en dat projectmanagement op een bepaalde manier minder technisch of valide was. Nu elke ontwikkelaar echter gedwongen wordt zich te concentreren op de grenzen en interfaces van de software die ze bouwen, en niet alleen op de interne werking, wordt in feite van elke ontwikkelaar gevraagd een Product Manager te worden. In plaats van dat de belangrijkste vraag "hoe bouwen we dit" of "kunnen we dit bouwen" is, is de belangrijkste vraag nu "wat moeten we bouwen". Voor veel ontwikkelaars zal het noodzakelijk zijn om op deze manier te denken een grote verschuiving zijn.
Software Engineers doen meer Software Engineering
Een definitie van Software Engineering is:
"Software engineering is de tak van de informatica die praktische, kosteneffectieve oplossingen creëert voor computer- en informatieverwerkingsproblemen, bij voorkeur door wetenschappelijke kennis toe te passen en softwaresystemen te ontwikkelen in dienst van de mensheid."
Merk op dat deze definitie geen directe referentie maakt naar het schrijven van code, maar naar het bouwen van systemen. Het werk om praktische, kosteneffectieve oplossingen te creëren is nu relevanter dan ooit. Naarmate de kosten voor het schrijven van de broncode dalen, wordt de baan van de ontwikkelaar gedomineerd door het ontwerp van het systeem, evenals het ontwikkelen van manieren om ervoor te zorgen dat het ontwerp correct wordt gevalideerd en geverifieerd.
Voorheen maakten ontwikkelaars een ontwerpbeslissing, waarna er een periode van weken of misschien zelfs maanden van ontwikkeling volgde voordat de impact van die beslissing relevant werd. Nu maken ontwikkelaars ontwerpbeslissingen en wordt de code onmiddellijk gegenereerd, waardoor ze bijna direct de impact van die beslissingen zien. Dit verkort de OODA-loop van software engineers aanzienlijk. Het helpt ontwikkelaars ook om de impact van hun ontwerpbeslissingen duidelijk te zien, wat zorgt voor een nauwere oorzaak-gevolgrelatie tussen software-ontwerp en de eigenschappen van het systeem. Dit zal vereisen dat ontwikkelaars hun vaardigheden op het gebied van software-ontwerp veel sneller ontwikkelen, aangezien ontwerp een groter deel van hun dagelijkse werk wordt.
Systeemontwerp van buiten naar binnen
Een andere implicatie van deze verschuiving is dat veel software historisch gezien van binnen naar buiten werd ontworpen. Dit betekent dat de kernstructuur eerst werd bepaald, waarna het externe gedrag vaak sterk werd beïnvloed door de interne structuur van de code — vergelijkbaar met hoe steenhouwers bruggen steen voor steen bouwden. In dit nieuwe paradigma is het externe gedrag echter waar de engineer de meeste tijd aan besteedt (zoals de bekistingen die een timmerman bouwt). De gegenereerde code is daardoor meer een weerspiegeling van de vorm die de code zou moeten hebben volgens het ontwerp van de engineer, dan een weerspiegeling van hoe de code is opgebouwd.
Beperkingen van deze analogie
Zoals bij alle analogieën heeft ook deze enkele beperkingen. Een duidelijk punt waar de analogie mank gaat, is dat wanneer je een brug van beton bouwt, je deze één keer stort en je vastzit aan het ontwerp. Bij software kan men echter de externe beperkingen ontwikkelen en, hoewel er kosten verbonden zijn aan het opnieuw genereren van alle code, kan dit meerdere keren worden gedaan. Hierdoor kunnen lessen uit vorige iteraties worden toegepast op toekomstige versies van de software.
Conclusie
Nu we bewegen van een tijdperk van steenhouwers naar dat van timmerlieden, is het duidelijk dat de rol van de software engineer snel verandert. De rol van de ontwikkelaar is niet langer om de software regel voor regel op te bouwen als een steenhouwer, maar om zich te concentreren op het gebruik van software engineering om een compleet systeem te bouwen. Als software engineer vind ik deze verandering spannend en kijk ik uit naar de adoptie van software engineering-technieken die voorheen te kostbaar of moeilijk waren, maar die nu worden overgenomen door ontwikkelaars die met behulp van AI grootschalige softwaresystemen bouwen.
***
Aanvullende discussie: Een alternatieve definitie van Engineering
In de context van deze verschuiving is er een alternatieve definitie van Engineering vanuit de veiligheidswetenschap die relevant is voor het tijdperk van AI en agenten:
"Engineering: De discipline van het uitoefenen van geïnformeerde controle over consequentiële systemen en het aanvaarden van de verantwoordelijkheid voor de resultaten daarvan. Controle betekent het behouden van voldoende commando over een systeem om het te begrijpen en te sturen, bewijs te evalueren voor consequentiële eigenschappen, te herkennen wanneer aannames falen, en in te grijpen wanneer dat nodig is. Verantwoordelijkheid betekent aansprakelijk blijven voor de consequentiële beslissingen die onder iemands autoriteit zijn genomen en voor het resulterende systeem. Engineering vereist niet dat men elke handeling van implementatie persoonlijk uitvoert, en werk kan worden gedelegeerd aan andere mensen of aan machine-intelligentie. Software engineering past deze discipline toe op softwaresystemen."
— Uit het glossarium van: https://davisjam.github.io/model-based-agentic-software-engineering/book/mage-book/0.4-the-books-language.html
Groetjes,