In dit artikel betoogt de auteur dat de bewering 'coderen is opgelost' een te simplistische kijk biedt op software engineering. Hoewel AI-modellen uitblinken in de implementatiefase (het vertalen van specificaties naar code), negeren ze de complexiteit van professionele softwareontwikkeling binnen organisaties.
De kernpunten zijn:
- Demo-apps versus Enterprise-software: Waar AI eenvoudig een simpele app kan bouwen op een 'leeg canvas', moet software in een bedrijf voldoen aan strikte architecturale, beveiligings- en zakelijke eisen die voortvloeien uit jarenlange context.
- Verschuiving van de bottleneck: Nu implementatie door AI goedkoper en sneller wordt, verschuift de focus naar hogere abstractielagen: het definiëren van het zakelijke doel, productontwerp en oplossingsontwerp.
- Code als medium: De auteur stelt dat code slechts het middel is, niet het einddoel. Software engineers worden betaald om problemen op te lossen, niet enkel om regels code te schrijven.
Concluderend onthult de komst van AI juist wat software engineering werkelijk inhoudt: het nemen van goede beslissingen binnen een complex landschap van beperkingen en context.
"Coderen is opgelost" mist de kern
Elke paar weken verklaart iemand dat coderen is opgelost. Als ze daarmee bedoelen het omzetten van een goed gespecificeerd probleem in uitvoerbare code, dan hebben ze steeds vaker gelijk. Maar was het schrijven van uitvoerbare code ooit het volledige probleem?
Taalmodellen hebben software engineering opgelost in dezelfde mate dat tekstverwerkers de journalistiek hebben opgelost: ze hebben het produceren van de output gemakkelijker gemaakt. Vraag een model om een REST-API te bouwen of een React-component te implementeren, en werk waar vroeger uren voor nodig waren, kost nu minuten. Opmerkelijk. Maar organisaties hebben antwoord nodig op een moeilijkere vraag: kan AI de problemen oplossen die zij daadwerkelijk hebben?
Demo-apps zijn startups in het klein
De gemakkelijkste manier om jezelf ervan te overtuigen dat coderen is opgelost, is door een demo-app te bouwen, zoals een to-do-lijst, een weer-app of een persoonlijk dashboard. De vereisten zijn duidelijk, er zijn nauwelijks beperkingen en je bent vrij om de architectuur gaandeweg te bedenken. Je bouwt op een leeg canvas.
Vergelijk dat nu eens met een volwassen organisatie. De taak kan klinken als "voeg een knop toe", maar voordat je een regel code schrijft, moet je antwoord geven op de volgende vragen:
- Welke service is eigenaar van deze functionaliteit?
- Is er al een API die we zouden moeten gebruiken?
- Waarom is dit niet eerder geïmplementeerd?
- Welke beveiligingseisen zijn van toepassing?
- Welke architecturale patronen zijn acceptabel?
- Welk team is verantwoordelijk voor dit gebied?
- Hoe zal dit downstream-systemen beïnvloeden?
- Voor welke zakelijke beperkingen optimaliseren we?
Hoeveel van deze vragen gaan over het schrijven van code? Zeer weinig. De meeste vereisen dat je de organisatie begrijpt.
Dat is waarom hetzelfde model dat magisch aanvoelt tijdens een weekendproject, binnen een onderneming slechts behulpzaam kan aanvoelen. Hoewel het programmeerprobleem vergelijkbaar is, maakt de omgeving het moeilijker.
We hebben de bottleneck verward met de discipline
Decennialang was het schrijven van code een van de duurste onderdelen van softwareontwikkeling, waardoor we software engineering gingen gelijkstellen aan implementatie. AI maakt implementatie drastisch goedkoper en verplaatst de bottleneck naar een andere plek.
Automatisering verandert wat schaars wordt. Naarmate implementatie overvloedig wordt, verschuift onze aandacht naar de volgende abstractielaag. Software engineering heeft altijd uit verschillende lagen bestaan:
- Zakelijk doel: Welk probleem proberen we op te lossen?
- Productontwerp: Hoe moeten gebruikers de oplossing ervaren?
- Oplossingsontwerp: Hoe moet het systeem die ervaring realiseren?
- Implementatie: Hoe drukken we dat uit in code?
Huidige modellen worden uitzonderlijk goed in de onderste laag. De rest van de stack is er nog steeds. We merken nu eindelijk hoeveel werk er boven de implementatie ligt.
Organisaties draaien op context
Eén ding scheidt hobbyprojecten van enterprise-software: context. Specifiek: organisatorische context.
Een organisatie kent al haar architectuur en domeintaal. Ze heeft historische beslissingen, engineering-conventies, eigendomsgrenzen, beveiligingseisen en zakelijke prioriteiten. Jarenlang software bouwen hebben ook talloze aannames gecreëerd die niemand heeft opgeschreven.
Deze context beïnvloedt elke stap. Strategie en regelgeving vormen de zakelijke beslissingen. Klantverwachtingen en gevestigde UX-patronen vormen de productbeslissingen. Bestaande platforms en services beperken het oplossingsontwerp. Codestandaarden, frameworks en deployment-pipelines sturen de implementatie.
Een startup creëert deze context terwijl deze groeit. Een onderneming erft decennia aan context. Een taalmodel vragen om een greenfield-applicatie te bouwen is fundamenteel anders dan het model vragen om een tien jaar oud productiesysteem uit te breiden. Het moeilijke gedeelte is het nemen van goede beslissingen binnen een bestaand landschap.
AI klimt op de abstractieladder
Elke generatie ontwikkeltools automatiseert de meest concrete laag van software engineering. Compilers automatiseerden machinetaal. Hogere programmeertalen automatiseerden low-level programmeren. Frameworks automatiseerden infrastructuur. Nu automatiseren taalmodellen de implementatie. Elke doorbraak voelt revolutionair totdat de volgende laag de bottleneck wordt. Dat is precies wat er vandaag gebeurt.
Hoe beter AI wordt in het produceren van code, hoe meer onze gesprekken verschuiven naar het begrijpen van het zakelijke probleem en het ontwerpen van de juiste ervaring. We besteden meer tijd aan het passen van oplossingen in bestaande systemen en het nemen van gezonde beslissingen binnen organisatorische beperkingen.
Code was altijd het medium
AI kan code schrijven. De fout is om aan te nemen dat het schrijven van code ooit de hele baan was. Organisaties betalen engineers om zakelijke problemen op te lossen. Code is het medium, niet het resultaat. Dus, is coderen opgelost? Als je bedoelt het vertalen van een duidelijke specificatie naar werkende software, dan komen we dichtbij.
Software engineering beslaat de hele stack. Elke generatie tools maakt één laag goedkoper en onthult de volgende. AI onthult wat software engineering al die tijd eigenlijk was.
"Coderen is opgelost" mist de kern
Elke paar weken verklaart iemand dat coderen is opgelost. Als ze daarmee bedoelen het omzetten van een goed gespecificeerd probleem in uitvoerbare code, dan hebben ze steeds vaker gelijk. Maar was het schrijven van uitvoerbare code ooit het volledige probleem?
Taalmodellen hebben software engineering opgelost in dezelfde mate dat tekstverwerkers de journalistiek hebben opgelost: ze hebben het produceren van de output gemakkelijker gemaakt. Vraag een model om een REST-API te bouwen of een React-component te implementeren, en werk waar vroeger uren voor nodig waren, kost nu minuten. Opmerkelijk. Maar organisaties hebben antwoord nodig op een moeilijkere vraag: kan AI de problemen oplossen die zij daadwerkelijk hebben?
Demo-apps zijn startups in het klein
De gemakkelijkste manier om jezelf ervan te overtuigen dat coderen is opgelost, is door een demo-app te bouwen, zoals een to-do-lijst, een weer-app of een persoonlijk dashboard. De vereisten zijn duidelijk, er zijn nauwelijks beperkingen en je bent vrij om de architectuur gaandeweg te bedenken. Je bouwt op een leeg canvas.
Vergelijk dat nu eens met een volwassen organisatie. De taak kan klinken als "voeg een knop toe", maar voordat je een regel code schrijft, moet je antwoord geven op de volgende vragen:
- Welke service is eigenaar van deze functionaliteit?
- Is er al een API die we zouden moeten gebruiken?
- Waarom is dit niet eerder geïmplementeerd?
- Welke beveiligingseisen zijn van toepassing?
- Welke architecturale patronen zijn acceptabel?
- Welk team is verantwoordelijk voor dit gebied?
- Hoe zal dit downstream-systemen beïnvloeden?
- Voor welke zakelijke beperkingen optimaliseren we?
Hoeveel van deze vragen gaan over het schrijven van code? Zeer weinig. De meeste vereisen dat je de organisatie begrijpt.
Dat is waarom hetzelfde model dat magisch aanvoelt tijdens een weekendproject, binnen een onderneming slechts behulpzaam kan aanvoelen. Hoewel het programmeerprobleem vergelijkbaar is, maakt de omgeving het moeilijker.
We hebben de bottleneck verward met de discipline
Decennialang was het schrijven van code een van de duurste onderdelen van softwareontwikkeling, waardoor we software engineering gingen gelijkstellen aan implementatie. AI maakt implementatie drastisch goedkoper en verplaatst de bottleneck naar een andere plek.
Automatisering verandert wat schaars wordt. Naarmate implementatie overvloedig wordt, verschuift onze aandacht naar de volgende abstractielaag. Software engineering heeft altijd uit verschillende lagen bestaan:
- Zakelijk doel: Welk probleem proberen we op te lossen?
- Productontwerp: Hoe moeten gebruikers de oplossing ervaren?
- Oplossingsontwerp: Hoe moet het systeem die ervaring realiseren?
- Implementatie: Hoe drukken we dat uit in code?
Huidige modellen worden uitzonderlijk goed in de onderste laag. De rest van de stack is er nog steeds. We merken nu eindelijk hoeveel werk er boven de implementatie ligt.
Organisaties draaien op context
Eén ding scheidt hobbyprojecten van enterprise-software: context. Specifiek: organisatorische context.
Een organisatie kent al haar architectuur en domeintaal. Ze heeft historische beslissingen, engineering-conventies, eigendomsgrenzen, beveiligingseisen en zakelijke prioriteiten. Jarenlang software bouwen hebben ook talloze aannames gecreëerd die niemand heeft opgeschreven.
Deze context beïnvloedt elke stap. Strategie en regelgeving vormen de zakelijke beslissingen. Klantverwachtingen en gevestigde UX-patronen vormen de productbeslissingen. Bestaande platforms en services beperken het oplossingsontwerp. Codestandaarden, frameworks en deployment-pipelines sturen de implementatie.
Een startup creëert deze context terwijl deze groeit. Een onderneming erft decennia aan context. Een taalmodel vragen om een greenfield-applicatie te bouwen is fundamenteel anders dan het model vragen om een tien jaar oud productiesysteem uit te breiden. Het moeilijke gedeelte is het nemen van goede beslissingen binnen een bestaand landschap.
AI klimt op de abstractieladder
Elke generatie ontwikkeltools automatiseert de meest concrete laag van software engineering. Compilers automatiseerden machinetaal. Hogere programmeertalen automatiseerden low-level programmeren. Frameworks automatiseerden infrastructuur. Nu automatiseren taalmodellen de implementatie. Elke doorbraak voelt revolutionair totdat de volgende laag de bottleneck wordt. Dat is precies wat er vandaag gebeurt.
Hoe beter AI wordt in het produceren van code, hoe meer onze gesprekken verschuiven naar het begrijpen van het zakelijke probleem en het ontwerpen van de juiste ervaring. We besteden meer tijd aan het passen van oplossingen in bestaande systemen en het nemen van gezonde beslissingen binnen organisatorische beperkingen.
Code was altijd het medium
AI kan code schrijven. De fout is om aan te nemen dat het schrijven van code ooit de hele baan was. Organisaties betalen engineers om zakelijke problemen op te lossen. Code is het medium, niet het resultaat. Dus, is coderen opgelost? Als je bedoelt het vertalen van een duidelijke specificatie naar werkende software, dan komen we dichtbij.
Software engineering beslaat de hele stack. Elke generatie tools maakt één laag goedkoper en onthult de volgende. AI onthult wat software engineering al die tijd eigenlijk was.
Groetjes,