💻 computer science

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

Questo articolo presenta un caso di studio che dimostra come l'ingegneria accoppiata all'IA, quando ancorata a una specifica eseguibile precisa e validata attraverso implementazioni parallele N-version, permetta a un singolo sviluppatore di produrre cinque porting software distinti in circa 120 ore, rianimando efficacemento la metodologia della programmazione N-version della costosa degli anni '80.

Autori originali: Jason Hickey

Pubblicato 2026-06-09

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jason Hickey

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di voler costruire cinque versioni diverse di un'app di disegno complessa e di alto livello (come una mini-Adobe Illustrator). Nei vecchi tempi, questo sarebbe stato come assumere cinque diversi architetti maestri, ognuno dei quali parla una lingua diversa, per progettare la stessa casa. Ci sarebbero voluti anni e sarebbe costato una fortuna.

Jason Hickey, un singolo sviluppatore, ha fatto qualcosa di diverso. Ha costruito cinque versioni funzionanti di questa app (per Rust, Swift, OCaml, Python e un browser web) in soli sette settimane, lavorando solo la sera. Non ha assunto un team; ha usato l'IA come partner.

Ecco come ci è riuscito, spiegato in modo semplice:

1. Il "Progetto Maestro" (La Specifica Eseguibile)

Di solito, quando si costruisce un software per diverse piattaforme, è necessario scrivere le regole dell'app da zero per cinque volte. Se vuoi cambiare il funzionamento di un selettore di colori, devi aggiornare cinque diversi database di codice.

Hickey ha fatto l'opposto. Ha scritto un unico "Progetto Maestro" (un documento di 23.000 righe scritto in un linguaggio chiamato YAML).

L'analogia: Pensa a questo progetto non come a un PDF statico, ma come a una ricetta vivente. Non dice solo "crea un pulsante rosso"; dice: "Ecco esattamente come appare il pulsante, come reagisce quando lo clicchi e cosa succede dopo".
La magia: Questo progetto è "eseguibile". Il computer legge questa singola ricetta e costruisce automaticamente l'interfaccia utente per tutte e cinque le app. Se Hickey vuole cambiare una regola, la cambia in un unico punto, e questa si aggiorna istantaneamente in tutte e cinque le app.

2. Il "Drago a Cinque Teste" (Programmazione N-Version)

Negli anni '80, gli ingegneri provarono un metodo chiamato "Programmazione N-Version". L'idea era: "Se costruiamo cinque versioni diverse di un sistema in modo indipendente, e tutte sono d'accordo, allora deve essere corretto. Se dissentono, sappiamo che c'è qualcosa che non va".

Il problema: Era troppo costoso. Costruire cinque versioni diverse dello stesso codice con cinque team differenti era uno spreco di denaro.
Il tocco dell'IA: Hickey ha ripreso in mano questa idea usando l'IA. Poiché l'IA può fare il lavoro pesante di scrivere il codice per i diversi linguaggi, lui poteva permettersi di costruire cinque versioni come una singola persona.
La rete di sicurezza: Queste cinque versioni agiscono come una giuria di cinque persone. Se la versione in "Rust" dell'app fa diventare un colore rosso, ma la versione in "Python" lo fa diventare blu, il sistema segnala immediatamente un problema. Esse effettuano un "test differenziale" tra loro. Se dissentono, significa che il Progetto Maestro non era chiaro o che una delle versioni ha commesso un errore.

3. La "Scappatoia" (Escape Hatch)

Il Progetto Maestro copre circa il 90% del lavoro. Ma a volte, una specifica piattaforma informatica (come un iPhone o un browser web) richiede un trucco speciale che il progetto generale non può descrivere.

L'analogia: Immagina che il progetto sia un piano standard per una casa. Ma la casa in "Rust" ha bisogno di un seminterrato speciale rinforzato perché il terreno è roccioso. Il progetto gestisce le pareti e il tetto per tutti, ma il team "Rust" deve costruire il proprio seminterrato speciale.
Hickey chiama questo la "Scappatoia" (Escape Hatch). È la piccola quantità di codice personalizzato necessaria per ogni specifica piattaforma, mentre il resto è condiviso.

4. Come ha funzionato il processo (Il Ciclo)

Hickey non si è limitato a digitare codice sperando nel meglio. Ha usato un ciclo specifico:

Progettazione: Ha scritto un piano in linguaggio naturale.
Revisione dell'IA: Ha chiesto all'IA di trovare le lacune nel piano ("Cosa manca? Cosa è confuso?").
Aggiornamento del Progetto: Ha aggiornato il Progetto Maestro in base ai consigli dell'IA.
Costruzione e Test: L'IA ha generato il codice per tutte e cinque le app.
Il controllo dell' "Occhio Umano": Questa è stata la parte più lenta. Hickey ha guardato manualmente tutte e cinque le app affiancate. Se una appariva strana, sapeva che il Progetto doveva essere sistemato.

Il Risultato

Tempo: Circa 120 ore di lavoro serale (circa 7 settimane).
Output: Cinque app completamente funzionanti che condividono la stessa logica centrale.
Costo: Invece di "molteplici anni di sviluppatore", è bastata una singola persona per alcuni mesi.

Il Rovescio della Medaglia (Limitazioni)

Il documento è onesto su ciò che questo non fa:

Non è un prodotto finito: Alle app mancano alcune funzioni avanzate presenti negli strumenti professionali (come complessi mesh 3D o funzioni di stampa professionale). È un "sottoinsieme sostanziale", non un clone perfetto.
Dipende dall'IA: Se l'IA si confonde o "allucina" (inventa codice falso), il sistema lo rileva perché le cinque versioni non saranno d'accordo. Ma se l'IA è scarsa in un compito specifico, l'intero processo rallenta.
Ha bisogno di un umano: L'IA ha fatto la parte della digitazione, ma un essere umano doveva controllare i risultati, correggere la logica e gestire la "memoria" del progetto affinché l'IA non dimenticasse ciò che aveva deciso il giorno precedente.

Il Grande Messaggio

Questo documento sostiene che l'IA ha cambiato l'economia dell'ingegneria del software.
In precedenza, costruire più versioni di un software per garantirne la qualità era troppo costoso. Ora, con l'IA che gestisce la parte ripetitiva della codifica, un singolo sviluppatore può costruire una "giuria" di cinque app che controllano il lavoro l'una dell'altra. Trasforma un metodo che era stato abbandonato negli anni '80 a causa dei costi in uno strumento pratico per una singola persona oggi.

Sintesi Tecnica: L'Ingegneria Accoppiata con l'IA come Rinascita della Programmazione N-Version

Problema
Le applicazioni mature di illustrazione vettoriale (ad es. Adobe Illustrator, Inkscape) rappresentano decenni di sviluppo da parte di grandi team strutturati. Storicamente, estendere tali applicazioni o portarle su nuove piattaforme è stato considerato fuori portata per i singoli sviluppatori a causa del volume enorme di codice, della complessità dei framework UI e della necessità di una rigorosa correttezza. Il documento investiga se l'ingegneria accoppiata con l'IA possa alterare questa realtà economica, consentendo a un singolo sviluppatore di produrre molteplici implementazioni ad alta fedeltà di una complessa applicazione desktop in una frazione del tempo tradizionalmente richiesto.

Metodologia
L'autore, Jason Hickey, ha impiegato una metodologia centrata su due specifiche salvaguardie per abilitare l' "ingegneria accoppiata con l'IA" su larga scala:

Una Specifica Precisa ed Eseguibile (Singola Fonte di Verità):
- Il cuore del progetto è una specifica YAML di 23.000 righe che definisce in modo dichiarativo i pannelli, le finestre di dialogo, gli strumenti, i menu, i modelli di stato e i comportamenti reattivi dell'applicazione.
- Questa specifica è eseguibile: un interprete condiviso (circa 12.500 righe) legge lo YAML all'avvio e costruisce direttamente l'interfaccia utente, invece di trattare lo YAML come documentazione da ricodificare in ogni linguaggio.
- La metodologia utilizza un pattern di "scappatoia" (escape hatch): laddove lo YAML dichiarativo non può esprimere le sfumature specifiche di una piattaforma (ad es. il rendering accelerato dall'hardware, la gestione specifica dei gesti), viene scritto codice nativo. Tuttavia, la logica concettuale rimane nello YAML, garantendo che le decisioni di progettazione vengano prese una sola volta e propagate a tutte le porte.
Implementazioni Parallele come Strato di Differential-Testing Integrato:
- Invece di un'unica implementazione, lo sviluppatore ha costruito cinque port version working su distinti linguaggi e framework: Rust (Dioxus), Swift (SwiftUI), OCaml, Python (PySide6) e uno schizzo basato su browser con Flask/HTML.
- Queste implementazioni parallele fungono da controllo continuo della correttezza. Poiché condividono la stessa specifica ma utilizzano diversi renderer nativi e idiomi di gestione dello stato, le divergenze nel comportamento o nell'output visivo segnalano immediatamente un bug in un'implementazione o un'underspecificazione nello YAML.
- Questo approccio ravviva la programmazione N-version (Avizienis, 1985). Sebbene la metodologia originale degli anni '80 sia stata abbandonata a causa del costo proibitivo di creare $N$ implementazioni indipendenti, l'autore sostiene che l'IA cambi fondamentalmente l'economia. L'IA gestisce il lavoro meccanico per ogni porta, rendendo le $N$ implementazioni fattibili per un singolo sviluppatore, mentre la diversità delle piattaforme fornisce l'indipendenza necessaria per rilevare errori che i test automatizzati perdono.

Contributi Chiave

Un Caso di Studio: Un singolo sviluppatore ha prodotto cinque port cross-platform di un'applicazione di illustrazione vettoriale (27 strumenti, 14 pannelli, 22 finestre di dialogo) in circa 120 ore serali (7 settimane solari).
Framework Metodologico: Un workflow specifico che accoppia una specifica eseguibile con implementazioni parallele come strato di differential-testing.
Rapporto di Campo Pratico: Documentazione dettagliata dell'ingegneria accoppiata con l'IA in pratica, tra cui:
- Prompt Engineering: Cicli iterativi per convertire i design testuali in YAML e revisioni periodiche del codebase.
- Gestione dello Stato: Il ruolo critico della memoria persistente basata su file (57 voci) per mantenere il contesto tra le sessioni.
- Modalità di Fallimento: Segnalazione onesta dei limiti dell'IA, come le "allucinazioni sicure" di simboli, il drift del contesto lungo e la tendenza a scegliere un'interpretazione di un requisito sottospecificato senza segnalare l'ambiguità.
Artefatti Open Source: Il progetto completo, inclusa la specifica di 23.000 righe, i cinque port, 4.600 test automatizzati e i protocolli di test manuale, è disponibile su github.com/jyh/jas.

Risultati

Scala e Ambito: Il progetto ha prodotto circa 336.000 righe di codice totale (inclusi l'interprete condiviso e i cinque port). La specifica YAML condivisa ha guidato la logica, mentre il codice nativo per ogni port variava da 0 righe (OCaml, interamente guidato dallo YAML) a circa 95.000 righe (Rust, che richiedeva un rendering personalizzato significativo).
Correttezza tramite Divergenza: La strategia di implementazione parallela ha identificato con successo lacune nella specifica che sarebbero state "silenziosamente errate" in un singolo port. Esempi includono:
- Gestione di canali colore degeneri (ad es. la saturazione HSB che scende a zero).
  ima.
- Tempistica dei comportamenti di "snap" nelle modalità Web Safe RGB.
- Persistenza dello stato nei contesti di dialogo (ad es. il ripristino del campo esadecimale).
- Logica per i "colori recenti" durante il trascinamento degli slider.
Sforzo: Lo sforzo totale è stato stimato in 120–160 ore di sviluppo. L'autore nota che un singolo port di portata comparabile utilizzando strumenti convenzionali richiederebbe tipicamente 1–2 anni di lavoro di uno sviluppatore; cinque port richiederebbero convenzionalmente diversi anni di lavoro di più sviluppatori.

Significatività e Rivendicazioni
Il documento non sostiene che l'applicazione risultante eguagli la completezza di funzionalità degli strumenti commerciali maturi (mancano il text shaping avanzato, gli effetti raster e la piena fedeltà SVG). Invece, la sua importanza risiede nel dimostrare uno spostamento del confine di fattibilità per i singoli sviluppatori.

L'autore sostiene che combinando una specifica eseguibile precisa con implementazioni parallele generate dall'IA, un singolo sviluppatore può raggiungere un ambito di lavoro che convenzionalmente richiede diversi anni di lavoro di sviluppatori. Questo è inquadrato come una rinascita della programmazione N-version, dove la barriera economica per creare molteplici implementazioni indipendenti è stata abbassata dall'IA. La metodologia suggerisce che per i domini descrivibili in modo dichiarativo (come l'interfaccia utente e la logica applicativa), il valore del "differential-testing" di più port può essere realizzato senza il tradizionale costo penale, a condizione di mantenere rigorosi protocolli di test manuale e gestione della memoria.

Il documento rimane modesto, riconoscendo che i risultati sono un'istantanea delle attuali capacità dell'IA (Claude Opus 4.6/4.7 nel 2026) e che la metodologia dipende fortemente dall'esperienza di dominio dello sviluppatore e dalla sua capacità di gestire i fallimenti dell'IA. La tesi non è che l'IA sostituisca la necessità di supervisione umana, ma che cambi l'equazione economica della programmazione N-version, rendendola una strategia vitale per i singoli sviluppatori per garantire correttezza e portabilità.