Jas: AI-Paired Engineering as a Revival of N-Version Programming
Dit artikel presenteert een casestudy die aantoont dat door AI-gepaarde engineering, wanneer verankerd door een precieze uitvoerbare specificatie en gevalideerd via parallelle N-versie-implementaties, één ontwikkelaar in staat stelt om in ongeveer 120 uur vijf verschillende softwareports te produceren, waarmee de kostbare N-versie-programmeer-methodologie uit de jaren 1980 effectief wordt nieuw leven ingeblazen.
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
Stel je voor dat je vijf verschillende versies wilt bouwen van een complexe, hoogwaardige tekenapp (zoals een mini-Adobe Illustrator). In de oude dagen zou dit betekenen dat je vijf verschillende meesterarchitecten inhuurt, die elk een andere taal spreken, om hetzelfde huis te ontwerpen. Het zou jaren duren en een fortuin kosten.
Jason Hickey, een enkele ontwikkelaar, deed iets anders. Hij bouwde vijf werkende versies van deze app (voor Rust, Swift, OCaml, Python en een webbrowser) in slechts zeven weken, waarbij hij alleen in de avonduren werkte. Hij huurde geen team in; hij gebruikte AI als zijn partner.
Hier is hoe hij het deed, eenvoudig uitgelegd:
1. De "Master Blueprint" (De Uitvoerbare Specificatie)
Normaal gesproken, wanneer je software voor verschillende platforms bouwt, moet je de regels voor de app vijf keer vanaf nul schrijven. Als je wilt veranderen hoe een kleurkiezer werkt, moet je dat in vijf verschillende codebases bijwerken.
Hickey deed het tegenovergestelde. Hij schreef één enkele "Master Blueprint" (een document van 23.000 regels geschreven in een taal genaamd YAML).
- De Analogie: Denk aan dit blauwdruk niet als een statisch PDF-bestand, maar als een levend recept. Het zegt niet alleen "maak een rode knop"; het zegt: "Hier is precies hoe de knop eruit ziet, hoe hij reageert als je erop klikt, en wat er daarna gebeurt."
- De Magie: Dit blauwdruk is "uitvoerbaar". De computer leest dit ene recept en bouwt automatisch de gebruikersinterface voor alle vijf de verschillende apps. Als Hickey een regel wil veranderen, verandert hij die op één plek, en dat werkt direct door in alle vijf de apps.
2. De "Vijfhofdraak" (N-Version Programming)
In de jaren 80 probeerden ingenieurs een methode genaamd "N-Version Programming". Het idee was: "Als we vijf verschillende versies van een systeem onafhankelijk van elkaar bouwen, en ze zijn het allemaal eens, dan moet het wel kloppen. Als ze het oneens zijn, weten we dat er iets mis is."
- Het Probleem: Het was te duur. Het bouwen van vijf verschillende teams om vijf verschillende versies van dezelfde code te schrijven, was een verspilling van geld.
- De AI-Twist: Hickey herleefde dit idee met behulp van AI. Omdat AI het zware werk kan doen om de code voor de verschillende talen te schrijven, kon hij het zich als een eenling veroorloven om vijf versies te bouwen.
- Het Veiligheidsnet: Deze vijf versies fungeren als een jury van vijf personen. Als de "Rust"-versie van de app een kleur rood maakt, maar de "Python"-versie maakt hem blauw, dan signaleert het systeem onmiddellijk een probleem. Ze voeren een "differentieel testen" op elkaar uit. Als ze het oneens zijn, betekent dit dat de Master Blueprint onduidelijk was, of dat een van de versies een fout heeft gemaakt.
3. De "Escape Hatch" (De Ontsnappingsroute)
De Master Blueprint dekt ongeveer 90% van het werk. Maar soms heeft een specifiek computerplatform (zoals een iPhone of een webbrowser) een speciale truc nodig die de algemene blauwdruk niet kan beschrijven.
- De Analogie: Stel je voor dat het blauwdruk een standaard huisplan is. Maar het "Rust"-huis heeft een speciale versterkte kelder nodig omdat de grond rotsachtig is. Het blauwdruk behandelt de muren en het dak voor iedereen, maar het "Rust"-team moet zijn eigen speciale kelder bouwen.
- Hickey noemt dit de Escape Hatch. Het is de kleine hoeveelheid aangepaste code die nodig is voor elk specifief platform, terwijl de rest gedeeld wordt.
4. Hoe het proces werkte (De Lus)
Hickey typte niet zomaar code en hoopte op het beste. Hij gebruikte een specifieke lus:
- Ontwerp: Hij schreef een plan in gewone mensentaal.
- AI Review: Hij vroeg de AI om gaten in het plan te vinden ("Wat ontbreekt er? Wat is verwarrend?").
- Blueprint Update: Hij verfijnde de Master Blueprint op basis van het advies van de AI.
- Bouwen & Testen: De AI genereerde de code voor alle vijf de apps.
- De "Menselijke Blik" Check: Dit was het langzaamste deel. Hickey keek handmatig naar alle vijf de apps naast elkaar. Als één app er vreemd uitzag, wist hij dat de Blueprint aangepast moest worden.
Het Resultaat
- Tijd: ~120 uur werk in de avonduren (ongeveer 7 weken).
- Output: Vijf volledig functionele apps die één kernlogica delen.
- Kosten: In plaats van "meerdere ontwikkelaarjaren", kostte het één persoon een paar maanden.
De Kanttekeningen (Beperkingen)
Het paper is eerlijk over wat dit niet doet:
- Het is geen afgewerkt product: De apps missen enkele geavanceerde functies die in professionele tools te vinden zijn (zoals complexe 3D-meshes of professionele printfuncties). Het is een "substantieel deel", geen perfecte kloon.
- Het is afhankelijk van de AI: Als de AI in de war raakt of "hallucineert" (nepcode verzint), vangt het systeem dit op omdat de vijf versies het dan oneens zullen zijn. Maar als de AI slecht is in een specifieke taak, vertraagt het hele proces.
- Het heeft een mens nodig: De AI deed het typwerk, maar een mens moest de resultaten controleren, de logica aanpassen en het "geheugen" van het project beheren zodat de AI niet vergat wat er gisteren was besloten.
De Belangrijkste Les
Dit paper betoogt dat AI de economie van software engineering heeft veranderd.
Voorheen was het bouwen van meerdere versies van software om kwaliteit te garanderen te duur. Nu, met AI die het repetitieve programmeerwerk overneemt, kan een enkele ontwikkelaar een "jury" van vijf apps bouwen om elkaars werk te controleren. Het verandert een methode die in de jaren 80 werd opgegeven vanwege de kosten, in een praktisch hulpmiddel voor één persoon vandaag de dag.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.