Voorbij herinnering en de illusie van competentie

Ik denk dat beide argumenten zich op het verkeerde richten, omdat ze focussen op wie de code schrijft.

We hebben nooit alle code zelf geschreven

Ik heb de vaardigheid om syntaxis te onthouden en code uit het hoofd te typen nooit als bijzonder belangrijk beschouwd voor mijn werk. Ik gebruik documentatie. Ik zoek op internet. Ik kopieer voorbeelden van Stack Overflow. Ik lees blogposts. Ik kijk naar code die is geschreven door collega's.

In een modern softwaresysteem is dit bijna onvermijdelijk. Een typische applicatie kan gebruikmaken van TypeScript, Python of Go, YAML, Dockerfiles, SQL, configuratiebestanden, CI-pipelines en een dozijn andere technologieën. Niemand kent elk detail van al deze zaken uit zijn hoofd.

Als het kopiëren van een nuttig stuk code van Stack Overflow altijd acceptabel is geweest, waarom zou het vragen van die code aan een machine dan fundamenteel anders zijn?

Eigenaarschap ging nooit over auteurschap

Er is nog een reden waarom ik het argument "AI schrijft de code" niet bijzonder overtuigend vind: we hebben altijd gewerkt aan systemen die we niet zelf hebben geschreven.

Je erft een service van een ander team. Iemand die het bedrijf heeft verlaten, heeft de helft ervan geschreven. Drie mensen hebben bijgedragen aan het deel waar jij verantwoordelijk voor bent, en je herinnert je niet eens meer wie welke functie heeft geschreven. Toch begin je, na lang genoeg met het systeem te hebben gewerkt, het als het jouwe te beschouwen. Waarom?

Niet omdat je elke regel hebt geschreven, maar omdat je het begrijpt.

Je weet wat het doet. Je weet waarom het zich gedraagt zoals het doet. Je weet waar de grenzen liggen, wat de afhankelijkheden zijn en wat er gebeurt als er iets misgaat. Dat is wat eigenaarschap daadwerkelijk inhoudt.

Het gevaarlijke om uit te besteden

Dit is waar AI-ondersteund programmeren interessant wordt. Het probleem is niet dat de machine de code schrijft; het probleem is dat het heel makkelijk is om de machine ook het denken te laten overnemen.

Er is een enorm verschil tussen zeggen: "Ik begrijp wat er moet gebeuren, schrijf dit voor me," en zeggen: "Zorg dat dit werkt," om vervolgens alles te accepteren wat er terugkomt.

In het eerste geval heb je het typen gedelegeerd, terwijl je in het tweede geval het begrip hebt gedelegeerd. En die twee zijn absoluut niet gelijkwaardig.

Debugging is waar het duidelijk wordt

Het schrijven van code is verrassend makkelijk uit te besteden. Debugging is veel moeilijker uit te besteden zonder iets belangrijks op te offeren.

Wanneer je zelf een systeem debugt, word je gedwongen om er een model van te construeren. Je hebt een verwacht resultaat. Er gebeurde echter iets anders. Dus werk je terug: wat had er moeten gebeuren? Wat had er moeten gebeuren om het waargenomen resultaat te produceren? Waar in de keten week de realiteit af van je verwachtingen?

Na voldoende van dit soort oefeningen ontwikkel je iets ongelooflijk waardevols: een intuïtie voor hoe systemen zich gedragen.

Ik heb gewerkt met ontwikkelaars die deze vaardigheid niet hadden. Wanneer er iets kapot ging, veranderden ze willekeurige dingen. Ze schoten simpelweg in het donker totdat er uiteindelijk iets werkte, maar ze hadden geen idee waarom. Dat is geen debugging.

AI maakt het opmerkelijk eenvoudig om precies in dit patroon te vallen: geef de machine de foutmelding, laat de machine een oplossing voorstellen, probeer de oplossing, rapporteer de volgende fout en herhaal dit tot de tests slagen. Je kunt werkende software produceren zonder ooit een nuttig mentaal model te ontwikkelen van de software die je maakt.

De illusie van competentie

Dit is wat me meer zorgen baart dan dat AI programmeurs vervangt. AI kan de illusie wekken dat je een systeem begrijpt, omdat het het systeem voor jou laat werken. Je stelt een vraag en krijgt een antwoord. Je stuit op een fout en krijgt een patch. De patch werkt niet, dus je geeft de nieuwe fout door en krijgt een andere patch. Uiteindelijk vindt de machine iets dat werkt.

Van buitenaf ziet dit eruit als competentie. Maar als je niet begrijpt waarom de oplossing werkt, word je niet daadwerkelijk bekwaamer. Je wordt afhankelijk van de machine om de illusie in stand te houden.

De consequenties worden bijzonder ernstig wanneer er iets gebeurt dat de machine niet kan oplossen, of wanneer je simpelweg je tokens verbruikt hebt. Op dat moment heb je het mentale model nodig dat je nooit hebt opgebouwd.

Dit is nog belangrijker voor junioren

Ervaren ontwikkelaars hebben tenminste een groot reservoir aan kennis opgebouwd door jarenlang problemen op de harde manier op te lossen. Voor iemand die vandaag begint, wordt die ervaring mogelijk nooit op dezelfde manier opgebouwd.

Als elke frustrerende debug-sessie aan een AI kan worden overgedragen, is er weinig stimulans om vier uur besteden aan het uitzoeken waarom een systeem zich gedraagt zoals het doet. En die vier uur zijn geen verloren tijd; dat is precies waar het mentale model vandaan komt.

Je leert systemen niet door ze succesvol te wijzigen; je zult ze pas succesvol kunnen wijzigen wanneer je in staat bent uit te leggen waarom ze falen.

Besteed het begrip niet uit

Ik denk niet dat de oplossing is om te stoppen met het gebruik van AI; integendeel. Gebruik het agressief. Laat het de boilerplate-code schrijven. Laat het je herinneren aan de syntaxis. Laat het een onbekende library verkennen. Laat het de saaie delen implementeren.

Maar houd het belangrijkste deel voor jezelf.

Je moet het probleem begrijpen. Je moet beslissen wat het systeem moet doen. Je moet de architecturale beslissingen nemen. Je moet kunnen uitleggen hoe de onderdelen in elkaar passen en waarom ze zo zijn ontworpen.

Laat de AI de code schrijven, niet de oplossingen ontwerpen.

De ontwikkelaar wordt meer een architect

Als het schrijven van code goedkoop en toegankelijk wordt voor iedereen, dan stopt het schrijven van code met een onderscheidende factor te zijn. De ontwikkelaars die eruit springen, zullen degenen zijn die systemen begrijpen.

Architectuur. Integratie. Gedistribueerde systemen. Observabiliteit. Foutmodi. Grenzen. Trade-offs. De zaken die zich rondom de code bevinden, in plaats van erin.

In die zin kan AI ontwikkelaars juist stimuleren om een meer architecturale rol aan te nemen.

De beste ontwikkelaars zullen niet degenen zijn die weigeren de machine hun code te laten schrijven. Het zullen degenen zijn die de machine gebruiken om hun systemen beter te begrijpen, terwijl ze stevig in controle blijven over de beslissingen.