💻 computer science

Jas: AI-Paired Engineering as a Revival of N-Version Programming

This paper presents a case study demonstrating that AI-paired engineering, when anchored by a precise executable specification and validated through parallel N-version implementations, enables a single developer to produce five distinct software ports in approximately 120 hours, effectively reviving the cost-prohibitive N-version programming methodology of the 1980s.

Original authors: Jason Hickey

Published 2026-06-09

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Jason Hickey

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you want to build five different versions of a complex, high-end drawing app (like a mini-Adobe Illustrator). In the old days, this would be like hiring five different master architects, each speaking a different language, to design the same house. It would take years and cost a fortune.

Jason Hickey, a single developer, did something different. He built five working versions of this app (for Rust, Swift, OCaml, Python, and a web browser) in just seven weeks, working only in the evenings. He didn't hire a team; he used AI as his partner.

Here is how he did it, explained simply:

1. The "Master Blueprint" (The Executable Specification)

Usually, when you build software for different platforms, you have to write the rules for the app from scratch five times. If you want to change how a color picker works, you have to update it in five different codebases.

Hickey did the opposite. He wrote one single "Master Blueprint" (a 23,000-line document written in a language called YAML).

The Analogy: Think of this blueprint not as a static PDF, but as a living recipe. It doesn't just say "make a red button"; it says, "Here is exactly how the button looks, how it reacts when you click it, and what happens next."
The Magic: This blueprint is "executable." The computer reads this one recipe and automatically builds the user interface for all five different apps. If Hickey wants to change a rule, he changes it in one place, and it instantly updates all five apps.

2. The "Five-Headed Dragon" (N-Version Programming)

In the 1980s, engineers tried a method called "N-Version Programming." The idea was: "If we build five different versions of a system independently, and they all agree, it must be right. If they disagree, we know something is wrong."

The Problem: It was too expensive. Building five different teams to write five different versions of the same code was a waste of money.
The AI Twist: Hickey revived this idea using AI. Because AI can do the heavy lifting of writing the code for the different languages, he could afford to build five versions as a single person.
The Safety Net: These five versions act like a five-person jury. If the "Rust" version of the app makes a color turn red, but the "Python" version makes it blue, the system immediately flags a problem. They "differential test" each other. If they disagree, it means the Master Blueprint was unclear, or one of the versions made a mistake.

3. The "Escape Hatch"

The Master Blueprint covers about 90% of the work. But sometimes, a specific computer platform (like an iPhone or a web browser) needs a special trick that the general blueprint can't describe.

The Analogy: Imagine the blueprint is a standard house plan. But the "Rust" house needs a special reinforced basement because the ground is rocky. The blueprint handles the walls and roof for everyone, but the "Rust" team has to build their own special basement.
Hickey calls this the Escape Hatch. It's the small amount of custom code needed for each specific platform, while the rest is shared.

4. How the Process Worked (The Loop)

Hickey didn't just type code and hope. He used a specific loop:

Design: He wrote a plan in plain English.
AI Review: He asked the AI to find holes in the plan ("What's missing? What's confusing?").
Blueprint Update: He updated the Master Blueprint based on the AI's advice.
Build & Test: The AI generated the code for all five apps.
The "Human Eye" Check: This was the slowest part. Hickey manually looked at all five apps side-by-side. If one looked weird, he knew the Blueprint needed fixing.

The Result

Time: ~120 hours of evening work (about 7 weeks).
Output: Five fully functional apps sharing one core logic.
Cost: Instead of "multiple developer-years," it took a single person a few months.

The Catch (Limitations)

The paper is honest about what this doesn't do:

It's not a finished product: The apps are missing some advanced features found in professional tools (like complex 3D meshes or professional printing features). It's a "substantial subset," not a perfect clone.
It relies on the AI: If the AI gets confused or "hallucinates" (makes up fake code), the system catches it because the five versions will disagree. But if the AI is bad at a specific task, the whole thing slows down.
It needs a human: The AI did the typing, but a human had to check the results, fix the logic, and manage the "memory" of the project so the AI didn't forget what it decided yesterday.

The Big Takeaway

This paper argues that AI has changed the economics of software engineering.
Previously, building multiple versions of software to ensure quality was too expensive. Now, with AI handling the repetitive coding, a single developer can build a "jury" of five apps to check each other's work. It turns a method that was abandoned in the 1980s due to cost into a practical tool for one person today.

Technical Summary: AI-Paired Engineering as a Revival of N-Version Programming

Problem Statement
Mature vector illustration applications (e.g., Adobe Illustrator, Inkscape) represent decades of development by large, sustained teams. Historically, extending such applications or porting them to new platforms has been considered out of reach for individual developers due to the sheer volume of code, the complexity of UI frameworks, and the need for rigorous correctness. The paper investigates whether AI-paired engineering can alter this economic reality, enabling a single developer to produce multiple, high-fidelity implementations of a complex desktop application in a fraction of the time traditionally required.

Methodology
The author, Jason Hickey, employed a methodology centered on two specific safeguards to enable "AI-paired engineering" at scale:

A Precise, Executable Specification (Single Source of Truth):
- The core of the project is a 23,000-line YAML specification that declaratively defines the application's panels, dialogs, tools, menus, state models, and reactive behaviors.
- This specification is executable: a shared interpreter (approx. 12,500 lines) reads the YAML at startup and constructs the UI directly, rather than treating the YAML as documentation to be re-encoded in each language.
- The methodology utilizes an "escape hatch" pattern: where the declarative YAML cannot express platform-specific nuances (e.g., hardware-accelerated rendering, specific gesture handling), native code is written. However, the conceptual logic remains in the YAML, ensuring design decisions are made once and propagated to all ports.
Parallel Implementations as a Built-in Differential-Testing Layer:
- Instead of a single implementation, the developer built five working ports across distinct languages and frameworks: Rust (Dioxus), Swift (SwiftUI), OCaml, Python (PySide6), and a browser-based Flask/HTML sketch.
- These parallel implementations function as a continuous correctness check. Because they share the same specification but utilize different native renderers and state management idioms, divergences in behavior or visual output immediately signal either a bug in an implementation or an underspecification in the YAML.
- This approach revives N-version programming (Avizienis, 1985). While the original 1980s methodology was abandoned due to the prohibitive cost of creating $N$ independent implementations, the author argues that AI fundamentally changes the economics. AI handles the mechanical per-port work, making $N$ implementations feasible for a single developer, while the diversity of platforms provides the necessary independence to catch errors that automated tests miss.

Key Contributions

A Case Study: A single developer produced five cross-platform implementations of a vector illustration application (27 tools, 14 panels, 22 dialogs) over approximately 120 evening hours (7 calendar weeks).
Methodological Framework: A specific workflow pairing an executable specification with parallel implementations as a differential-testing layer.
Practical Field Report: Detailed documentation of AI-paired engineering in practice, including:
- Prompt Engineering: Iterative loops for converting prose designs to YAML and periodic codebase reviews.
- State Management: The critical role of persistent, file-based memory (57 entries) to maintain context across sessions.
- Failure Modes: Honest reporting of AI limitations, such as "confident hallucinations" of symbols, long-context drift, and the tendency to pick one interpretation of an underspecified requirement without flagging ambiguity.
Open Source Artifacts: The full project, including the 23,000-line specification, five ports, 4,600 automated tests, and manual testing protocols, is available at github.com/jyh/jas.

Results

Scale and Scope: The project resulted in approximately 336,000 lines of total code (including shared interpreter and five ports). The shared YAML specification drove the logic, while per-port native code ranged from 0 lines (OCaml, fully YAML-driven) to ~95,000 lines (Rust, requiring significant custom rendering).
Correctness via Divergence: The parallel implementation strategy successfully identified specification gaps that would have been "silently wrong" in a single port. Examples include:
- Handling of degenerate color channels (e.g., HSB saturation dropping to zero).
- Timing of "snap" behaviors in Web Safe RGB modes.
- State persistence in dialog contexts (e.g., hex field reversion).
- Logic for "recent colors" during slider drags.
Effort: The total effort was estimated at 120–160 developer-hours. The author notes that a single port of comparable scope using conventional tools would typically require 1–2 developer-years; five ports would conventionally require multiple developer-years.

Significance and Claims
The paper does not claim that the resulting application matches the feature completeness of mature commercial tools (it lacks advanced text shaping, raster effects, and full SVG fidelity). Instead, its significance lies in demonstrating a shift in the feasibility boundary for single developers.

The author argues that by combining a precise executable specification with AI-generated parallel implementations, a single developer can achieve a scope of work that conventionally requires multiple developer-years. This is framed as a revival of N-version programming, where the economic barrier to creating multiple independent implementations has been lowered by AI. The methodology suggests that for domains describable declaratively (like UI and application logic), the "differential-testing" value of multiple ports can be realized without the traditional cost penalty, provided the developer maintains rigorous manual testing and memory management protocols.

The paper remains modest, acknowledging that the results are a snapshot of current AI capabilities (Claude Opus 4.6/4.7 in 2026) and that the methodology relies heavily on the developer's domain expertise and ability to manage AI failure modes. The claim is not that AI replaces the need for human oversight, but that it changes the economic equation of N-version programming, making it a viable strategy for individual developers to ensure correctness and portability.