🤖 AI

The Substrate Collapse: AI Code Generation Invalidates Authorship-Based Knowledge Metrics

Dit artikel betoogt dat AI-codegeneratie traditionele op auteurschap gebaseerde kennismetrieken, zoals de truck factor, ongeldig maakt door de link tussen code-eigendom en menselijk begrip te verbreken, wat een verschuiving noodzakelijk maakt naar nieuwe meetinstrumenten die gebaseerd zijn op direct bewijs van begrip in plaats van op versiebeheerattributie.

Oorspronkelijke auteurs: Brett Wheeler

Gepubliceerd 2026-06-23

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Brett Wheeler

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Idee: De Kaart is Niet Langer het Terrein

Stel je voor dat je probeert uit te zoeken wie de lay-out van een enorme, eeuwenoude stad kent. Decennialang was de enige manier om te raden wie de straten kende door te kijken naar wie de gebouwen had gebouwd. Als je een huis zag dat door een specifiek persoon was gebouwd, nam je aan: "Oké, zij weten hoe dat huis is bedraad, waar de leidingen lopen en wat er gebeurt als je aan een hendel trekt."

Dit artikel betoogt dat AI die regel heeft gebroken.

Nu kan een robot een huis bouwen, en kan een mens simpelweg de papierwerk ondertekenen om het goed te keuren. De naam van de mens staat nog steeds op de akte (het "auteurschap"), maar die persoon weet misschien geen flauw wat er met het huis gebeurt. Het artikel noemt dit de "Substrate Collapse" (het instorten van de ondergrond). Het fundament (de link tussen bouwen en weten) is ingestort, waardoor al onze oude meetinstrumenten nutteloos zijn geworden.

1. De Oude Manier: De "Fossiele" Theorie

In het verleden gebruikten software engineers metrieken zoals de "Truck Factor". Dit vraagt: "Als onze lead developer morgen door een vrachtwagen wordt geraakt, gaat het project dan dood?"

Om dit te berekenen, keken ze naar de "fossielen" in de code:

Wie schreef de regels code?
Wie bewerkte de bestanden?
Wie voerde de wijzigingen door (commits)?

De Logica: Als je de code schreef, moest je deze begrijpen om hem te kunnen schrijven. Dus was de "voetafdruk" van je naam op de code een betrouwbaar teken dat je het systeem begreep. Het was als het vinden van een fossiel; de rots (de code) bewees dat het dier (het begrip) er was.

2. De Instorting: De Robotbouwer

Nu schrijven AI-tools (agents) de code. Een menselijke ontwikkelaar kan de AI vragen: "Bouw me een inlogsysteem," en de AI doet het in enkele seconden. De mens bekijkt het, klikt misschien op "Akkoord", en voegt het toe.

Het Probleen:

De naam van de mens staat nu op de code (de voetafdruk).
Maar de mens schreef het niet, dus hoefde diegene het niet noodzakelijkerwijs te begrijpen om het werk af te krijgen.
De AI schreef het, maar de AI "begrijpt" het niet op een manier die een mens later kan uitleggen.

De Analogie:
Stel je een thermometer voor. Jarenlang wist je, als de thermometer 37,8°C aangaf, dat de persoon koorts had. Dat was de regel.
Stel je nu voor dat iemand een machine uitvindt die de thermometer naar 37,8°C kan verwarmen zonder dat de persoon daadwerkelijk ziek is.

De thermometer geeft nog steeds perfect 37,8°C aan.
Maar de thermometer vertelt je niet langer of de persoon ziek is.
Het instrument is niet kapot; de verbinding tussen de meting en de werkelijkheid is verbroken.

Het artikel zegt dat onze "Truck Factor" die kapotte thermometer is. Hij geeft ons nog steeds een getal, maar dat getal vertelt ons niet meer wie het softwarepakket daadwerkelijk begrijpt.

3. Waarom we de Oude Tools Niet Gewoon Kunnen "Repareren"

Je zou kunnen denken: "Kunnen we de wiskunde niet gewoon aanpassen? Misschien moeten we code anders wegen als een AI het geschreven heeft?"

Het artikel zegt nee. Je kunt dit niet oplossen door de gewichten aan te passen.

De Analogie: Stel je voor dat je probeert te raden hoeveel water er in een emmer zit door de emmer te wegen. Als iemand stiekem het water heeft vervangen door zand, verandert het gewicht, maar de betekenis van het gewicht is verdwenen. Je kunt de weegschaal niet simpelweg "herkalibreren" om te zien hoeveel water er nog over is, omdat de emmer nu vol met zand zit.
De link tussen "wie de code aanraakte" en "wie de code begrijpt" is voorgoed verdwenen. Geen enkele hoeveelheid wiskunde op de oude data kan dat terugbrengen.

4. De Waarschuwingssignalen (De "Spanning")

Het artikel wijst erop dat de softwarewereld al tekenen ziet dat er iets mis is, zelfs als ze nog niet precies weten wat.

De "False Confidence" Kloof: Ontwikkelaars voelen zich sneller en productiever met AI, maar studies tonen aan dat ze eigenlijk langzamer zijn omdat ze al hun tijd besteden aan uitzoeken of het werk van de AI wel klopt.
De "Churn" Verwarring: We zien meer code geschreven en verwijderd worden, maar we kunnen niet zien of dat komt omdat mensen bugs oplossen (goed) of omdat de AI fouten maakt die constante herstelwerkzaamheden verevergen (slecht). De tools kunnen het verschil niet meer zien.
Oppervlakte vs. Diepte: AI is geweldig in het oplossen van kleine, oppervlakkige typefouten (zoals een spellingscontrole), maar het creëert vaak diepe, logische fouten die een mens nodig hebben om het systeem echt te begrijpen om ze te kunnen oplossen.

5. Wat We In Plaats Daarvan Nodig Hebben: Meten van "Theorie", Niet "Voetafdrukken"

Het artikel betoogt dat we moeten stoppen met kijken naar wie de code schreef en moeten beginnen met het meten van wie het systeem daadwerkelijk begrijpt.

Oude Metriek: "Wie heeft dit bestand aangeraakt?" (Auteurschap)
Nieuwe Benodigde Metriek: "Kan deze persoon uitleggen waarom het systeem doet wat het doet?" (Begrip)

De Uitdaging:
Het meten van "begrip" is veel moeilijker dan het tellen van "regels code". Het is het verschil tussen tellen hoeveel boeken een student in de kast heeft staan (makkelijk) versus testen of de student daadwerkelijk een wiskundeprobleem kan oplossen zonder in het boek te kijken (moeilijk).

Het artikel geeft toe: We hebben dit nieuwe instrument nog niet. Het is een open probleem. Maar de belangrijkste stap is beseffen dat de oude tools dood zijn, zodat we stoppen met proberen ze te repareren en beginnen met het bouwen van de nieuwe.

6. De Voorspelling (De Test)

Het artikel doet een gedurfde voorspelling om te bewijzen dat het gelijk heeft:

Het Scenario: Stel je een softwareteam voor dat er op papier perfect uitziet. Ze hebben een hoge "Truck Factor" (veel mensen hebben de code aangeraakt, dus het lijkt veilig).
De Realiteit: Omdat de code door AI is gegenereerd, begrijpt niemand de diepe logica.
Het Resultaat: Wanneer er een vreemd, nieuw probleem optreedt, zal het team er niet snel in slagen dit op te lossen. Ze zullen vastlopen, panikeren en er lang over doen om het op te lossen.
Het Bewijs: De oude "Truck Factor"-metriek zal zeggen: "Je bent veilig!" terwijl de realiteit zal zijn: "Je zit in de problemen." Deze kloof bewijst dat de oude metriek kapot is.

Samenvatting

Het Verleden: Als je de code schreef, begreep je het. We maten kennis door te tellen wie wat schreef.
Het Heden: AI schrijft de code, mensen keuren het alleen goed. De "handtekening" op de code betekent niet langer "Ik begrijp dit".
De Gevolgen: Onze oude veiligheidscontroles (zoals de Truck Factor) liegen nu tegen ons. Ze meten wie het werk heeft ondertekend, niet wie het werk kent.
De Oplossing: We moeten een nieuwe manier uitvinden om daadwerkelijk begrip te meten, niet alleen auteurschap. Tot die tijd vliegen we blind; we denken dat we veilig zijn omdat onze oude instrumenten dat zeggen, terwijl de "koorts" (het risico) in werkelijkheid stijgt.