Waarom 2026 het einde is van coderen, maar niet van engineering

Claude Opus 4.5 is net uitgekomen. En het onderzoeksteam van Anthropic stelt dat software-engineering tegen medio 2026 geautomatiseerd zou kunnen zijn. Ons team heeft de laatste tijd diep in Claude gezeten en we zijn oprecht onder de indruk. Maar we denken dat de sector twee heel verschillende dingen door elkaar haalt.

Coderen is geen engineering

Coderen is logica omzetten in syntaxis. Instructies schrijven die een machine kan uitvoeren. Daar zijn LLM's vandaag opvallend goed in geworden. Ze genereren functies, lossen bugs op, refactoren code en doorstaan zelfs technische sollicitatiegesprekken beter dan de meeste mensen.

Maar software-engineering? Dat is alles rondom de code. Architectuurkeuzes die u drie jaar later niet achtervolgen. Begrijpen wat gebruikers echt nodig hebben tegenover wat ze zeggen te willen. Afstemmen tussen teams met verschillende prioriteiten. Afwegingen maken als er geen duidelijk juist antwoord is.

Soft skills worden de nieuwe hard skills. Coderen is syntaxis. Engineering is algoritmisch en kritisch denken.

Wat modellen nog steeds niet kunnen

Software-engineering gebeurt in rommelige omgevingen. Legacysystemen met ongedocumenteerde afhankelijkheden. Bedrijfseisen die halverwege de sprint veranderen. Stakeholders die niet weten wat ze willen totdat ze zien wat ze niet willen. Een LLM kan perfecte code schrijven voor een goed omschreven probleem. Maar hoe gaat het om met een situatie waarin de juiste oplossing afhangt van de vaardigheden van uw team, de planning van de uitrol, de technische schuld en de risicobereidheid van het bedrijf?

Dat vraagt om oordeel en smaak. In onze opdrachten zijn de meeste mislukte AI-projecten niet technisch mislukt. Ze lopen stuk op de organisatie: verkeerd gerichte prikkels, slechte communicatie, niemand die het probleem scherp heeft tegen de tijd dat de eerste sprint sluit. De code doorstaat elke test. Niets in de repository verklaart wat er misging, omdat niets in de repository het probleem was.

Het contextprobleem

Denk even als een software-engineer. U leest door een codebase die iemand anders vijf jaar geleden schreef en probeert te achterhalen waarom bepaalde keuzes zijn gemaakt. U zoekt uit waarom staging zich anders gedraagt dan productie. U beslist of u die functie nu toevoegt of wacht op de refactor van volgend kwartaal.

U zou ons kunnen onderbreken en zeggen: waarom voeren we dit niet gewoon allemaal aan een LLM? Dat kan. Maar een miljoen tokens vasthouden is niet hetzelfde als context begrijpen. Het weet nog steeds niet waarom die architectuurkeuze is gemaakt, wat de codebase heeft gevormd, of welke sluiproutes deadlinepaniek waren en welke bewuste afwegingen.

Het oordeelsgat

Dit zien we in de praktijk steeds weer. De bedrijven die AI inzetten voor het genereren van code worstelen niet met codekwaliteit. De code die modellen vandaag produceren is vaak schoon, goed gedocumenteerd en volgt de gangbare best practices. De echte worsteling is al het andere.

• Moeten we deze functie überhaupt bouwen?
• Is dit de juiste architectuur voor onze schaal?
• Wat gebeurt er als dit koppelt aan de drie legacysystemen waar niemand aan wil komen?
• Hoe gaan we om met de beveiligingsgevolgen waar niemand aan heeft gedacht?

Deze vragen vragen om empathie. Begrip van de business, de gebruikers, de planning, het risicoprofiel en een dozijn andere factoren die in geen enkele prompt voorkomen. Ze zijn ook de reden dat we engineers in de teams van klanten plaatsen in plaats van een specificatie over te dragen. De context die ertoe doet, staat zelden ergens opgeschreven.

De realistische kijk

De bedrijven die we vooruitgang zien boeken met de invoering van AI, proberen hun engineers niet te vervangen. Ze gebruiken AI als vermenigvuldiger voor het mechanische werk, zodat hun engineers zich kunnen richten op de oordeelsbeslissingen die er echt toe doen: architectuurkeuzes, het afwegen van compromissen en de gesprekken van het type "moeten we dit überhaupt bouwen?".

De kern

Is software-engineering over zes maanden klaar? Bij lange na niet. Het werk gebeurt in rommelige, menselijke omgevingen waar eisen onduidelijk zijn, stakeholders het oneens zijn en het juiste antwoord afhangt van context die niemand heeft opgeschreven.

Een model kan de code nu al schrijven. Het kan niet in een kamer zitten waar twee directeuren iets anders willen, uitzoeken wie van de twee hier eigenlijk voor betaalt, en hardop zeggen dat de functie waar ze het allebei over eens zijn niet gebouwd moet worden. Dat is het werk. Dat was altijd al het werk.