Jas: AI-Paired Engineering as a Revival of N-Version Programming
Diese Arbeit präsentiert eine Fallstudie, die zeigt, dass KI-gestütztees Engineering, wenn es durch eine präzise ausführbare Spezifikation verankert und durch parallele N-Version-Implementierungen validiert wird, es einem einzelnen Entwickler ermöglicht, fünf unterschiedliche Software-Ports in etwa 120 Stunden zu erstellen, wodurch die kostenintensive N-Version-Programmierungsmethodik der 1980er Jahre effektiv wiederbelebt wird.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie möchten fünf verschiedene Versionen einer komplexen, High-End-Zeichen-App (wie ein Mini-Adobe Illustrator) bauen. In den alten Tagen wäre dies so gewesen, als würde man fünf verschiedene Meisterarchitekten anheuern, von denen jeder eine andere Sprache spricht, um dasselbe Haus zu entwerfen. Es hätte Jahre gedauert und ein Vermögen gekostet.
Jason Hickey, ein einzelner Entwickler, tat etwas anderes. Er baute fünf funktionierende Versionen dieser App (für Rust, Swift, OCaml, Python und einen Webbrowser) in nur sieben Wochen, indem er ausschließlich abends arbeitete. Er heuerte kein Team an; er nutzte KI als seinen Partner.
Hier ist die Erklärung, wie er es gemacht hat, vereinfacht dargestellt:
1. Der „Master-Bauplan“ (Die ausführbare Spezifikation)
Normalerweise, wenn Sie Software für verschiedene Plattformen entwickeln, müssen Sie die Regeln für die App fünfmal von Grund auf neu schreiben. Wenn Sie die Funktionsweise eines Farbwählers ändern wollen, müssen Sie dies in fünf verschiedenen Codebasen aktualisieren.
Hickey machte das Gegenteil. Er schrieb einen einzigen „Master-Bauplan“ (ein 23.000 Zeilen umfassendes Dokument, geschrieben in einer Sprache namens YAML).
- Die Analogie: Betrachten Sie diesen Bauplan nicht als statisches PDF, sondern als ein lebendiges Rezept. Er sagt nicht nur „mache einen roten Button“, sondern: „Hier ist genau festgelegt, wie der Button aussieht, wie er auf einen Klick reagiert und was als Nächstes passiert.“
- Die Magie: Dieser Bauplan ist „ausführbar“. Der Computer liest dieses eine Rezept und baut automatisch die Benutzeroberflächen für alle fünf verschiedenen Apps. Wenn Hickey eine Regel ändern möchte, ändert er sie an einer Stelle, und sie aktualisiert sofort alle fünf Apps.
2. Der „Fünfköpfige Drache“ (N-Version-Programmierung)
In den 1980er Jahren versuchten Ingenieure eine Methode namens „N-Version-Programmierung“. Die Idee war: „Wenn wir fünf verschiedene Versionen eines Systems unabhängig voneinander bauen und alle übereinstimmen, muss es richtig sein. Wenn sie uneinig sind, wissen wir, dass etwas nicht stimmt.“
- Das Problem: Es war zu teuer. Fünf verschiedene Teams anzuheuern, um fünf verschiedene Versionen desselben Codes zu schreiben, war eine Verschwendung von Geld.
- Der KI-Twist: Hickey belebte diese Idee mithilfe von KI wieder. Da die KI die schwere Arbeit des Codierens in den verschiedenen Sprachen übernimmt, konnte er es sich als Einzelperson leisten, fünf Versionen zu bauen.
- Das Sicherheitsnetz: Diese fünf Versionen fungieren wie eine fünfköpfige Jury. Wenn die „Rust“-Version der App eine Farbe auf Rot setzt, die „Python“-Version aber Blau macht, schlägt das System sofort Alarm. Sie führen einen „Differenztest“ durch. Wenn sie uneins sind, bedeutet das, dass der Master-Bauplan unklar war oder eine der Versionen einen Fehler gemacht hat.
3. Die „Notausgang-Lösung“ (The Escape Hatch)
Der Master-Bauplan deckt etwa 90 % der Arbeit ab. Aber manchmal benötigt eine spezifische Computerplattform (wie ein iPhone oder ein Webbrowser) einen speziellen Trick, den der allgemeine Bauplan nicht beschreiben kann.
- Die Analogie: Stellen Sie sich vor, der Bauplan ist ein Standard-Hausplan. Aber das „Rust“-Haus benötigt ein spezielles verstärktes Fundament, weil der Boden felsig ist. Der Bauplan kümmert sich für alle um Wände und Dach, aber das „Rust“-Team muss sein eigenes spezielles Fundament bauen.
- Hickey nennt dies die „Escape Hatch“ (Notausgang-Lösung). Es ist der kleine Teil des kundenspezifischen Codes, der für die jeweilige Plattform benötigt wird, während der Rest gemeinsam genutzt wird.
4. Wie der Prozess ablief (Die Schleife)
Hickey tippte nicht einfach nur Code und hoffte auf das Beste. Er nutzte eine spezifische Schleife:
- Design: Er entwarf einen Plan in einfacher Sprache.
- KI-Review: Er fragte die KI nach Lücken im Plan („Was fehlt? Was ist verwirrend?“).
- Bauplan-Update: Er aktualisierte den Master-Bauplan basierend auf dem Rat der KI.
- Bauen & Testen: Die KI generierte den Code für alle fünf Apps.
- Der „Check mit dem menschlichen Auge“: Dies war der langsamste Teil. Hickey betrachtete alle fünf Apps manuell nebeneinander. Wenn eine seltsam aussah, wusste er, dass der Bauplan korrigiert werden musste.
Das Ergebnis
- Zeit: ~120 Arbeitsstunden in den Abendstunden (etwa 7 Wochen).
- Output: Fünf voll funktionsfähige Apps, die dieselbe Kernlogik teilen.
- Kosten: Anstatt „mehrere Entwicklerjahre“ dauerte es nur einen Einzelnen wenige Monate.
Die Kehrseite (Einschränkungen)
Das Paper ist ehrlich darüber, was es nicht leistet:
- Es ist kein fertiges Produkt: Den Apps fehlen einige fortgeschrittene Funktionen, die in professionellen Werkzeugen zu finden sind (wie komplexe 3D-Meshes oder professionelle Druckfunktionen). Es ist eine „wesentliche Teilmenge“, kein perfektes Klone.
- Es ist von der KI abhängig: Wenn die KI verwirrt wird oder „halluziniert“ (falschen Code erfindet), erkennt das System dies, weil die fünf Versionen sich uneinig sind. Aber wenn die KI bei einer bestimmten Aufgabe schlecht ist, verlangsamt das den gesamten Prozess.
- Es braucht einen Menschen: Die KI erledigte das Tippen, aber ein Mensch musste die Ergebnisse prüfen, die Logik korrigieren und das „Gedächtnis“ des Projekts verwalten, damit die KI nicht vergaß, was sie gestern entschieden hatte.
Die wichtigste Erkenntnis
Dieses Paper argumentiert, dass KI die Ökonomie der Softwareentwicklung verändert hat.
Zuvor war das Bauen mehrerer Softwareversionen, um die Qualität sicherzustellen, zu teuer. Jetzt, da die KI die repetitive Codierarbeit übernimmt, kann ein einzelner Entwickler eine „Jury“ aus fünf Apps erstellen, die die Arbeit der anderen überprüfen. Dies macht eine Methode, die in den 1980er Jahren aufgrund der Kosten aufgegeben wurde, heute zu einem praktischen Werkzeug für eine einzelne Person.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.