💻 computer science

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

Este artículo presenta un estudio de caso que demuestra que la ingeniería emparejada con IA, cuando se ancla en una especificación ejecutable precisa y se valida mediante implementaciones paralelas de N-versiones, permite que un solo desarrollador produzca cinco puertos de software distintos en aproximadamente 120 horas, reviviendo efectivamente la metodología de programación de N-versiones de la década de 1980, la cual resultaba prohibitiva en términos de costos.

Autores originales: Jason Hickey

Publicado 2026-06-09

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Jason Hickey

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que quieres construir cinco versiones diferentes de una aplicación de dibujo compleja y de alta gama (como un mini-Adobe Illustrator). En los viejos tiempos, esto sería como contratar a cinco arquitectos maestros diferentes, cada uno hablando un idioma distinto, para diseñar la misma casa. Tomaría años y costaría una fortuna.

Jason Hickey, un solo desarrollador, hizo algo diferente. Construyó cinco versiones funcionales de esta aplicación (para Rust, Swift, OCaml, Python y un navegador web) en solo siete semanas, trabajando únicamente por las noches. No contrató a un equipo; usó la IA como su compañera.

Aquí te explico cómo lo hizo, de forma sencilla:

1. El "Plano Maestro" (La Especificación Ejecutable)

Normalmente, cuando construyes software para diferentes plataformas, tienes que escribir las reglas de la aplicación desde cero cinco veces. Si quieres cambiar cómo funciona un selector de colores, tienes que actualizar cinco bases de código distintas.

Hickey hizo lo contrario. Escribió un único "Plano Maestro" (un documento de 23,000 líneas escrito en un lenguaje llamado YAML).

La Analogía: Piensa en este plano no como un PDF estático, sino como una receta viva. No dice simplemente "haz un botón rojo"; dice: "Aquí está exactamente cómo se ve el botón, cómo reacciona cuando haces clic en él y qué sucede después".
La Magia: Este plano es "ejecutable". La computadora lee esta única receta y construye automáticamente la interfaz de usuario para las cinco aplicaciones diferentes. Si Hickey quiere cambiar una regla, la cambia en un solo lugar, y esto actualiza instantáneamente las cinco aplicaciones.

2. El "Dragón de Cinco Cabezas" (Programación N-Versión)

En la década de 1980, los ingenieros intentaron un método llamado "Programación N-Versión". La idea era: "Si construimos cinco versiones diferentes de un sistema de forma independiente, y todas coinciden, entonces debe ser correcto. Si no coinciden, sabemos que algo anda mal".

El Problema: Era demasiado caro. Construir cinco equipos diferentes para escribir cinco versiones distintas del mismo código era un desperdicio de dinero.
El Giro de la IA: Hickey revivió esta idea usando la IA. Debido a que la IA puede realizar el trabajo pesado de escribir el código para los diferentes lenguajes, él pudo permitirse construir cinco versiones siendo una sola persona.
La Red de Seguridad: Estas cinco versiones actúan como un jurado de cinco personas. Si la versión de "Rust" hace que un color se vuelva rojo, pero la versión de "Python" lo hace azul, el sistema detecta inmediatamente un problema. Realizan una "prueba diferencial" entre sí. Si no coinciden, significa que el Plano Maestro no era claro o que una de las versiones cometió un error.

3. La "Escotilla de Escape"

El Plano Maestro cubre aproximadamente el 90% del trabajo. Pero a veces, una plataforma de computadora específica (como un iPhone o un navegador web) necesita un truco especial que el plano general no puede describir.

La Analogía: Imagina que el plano es el plano de una casa estándar. Pero la casa de "Rust" necesita un sótano especialmente reforzado porque el terreno es rocoso. El plano gestiona las paredes y el techo para todos, pero el equipo de "Rust" tiene que construir su propio sótano especial.
Hickey llama a esto la Escotilla de Escape. Es la pequeña cantidad de código personalizado necesario para cada plataforma específica, mientras que el resto es compartido.

4. Cómo funcionó el proceso (El Bucle)

Hickey no se limitó a escribir código y esperar. Utilizó un bucle específico:

Diseño: Escribió un plan en lenguaje sencillo.
Revisión de la IA: Le pidió a la IA que encontrara lagunas en el plan ("¿Qué falta? ¿Qué es confuso?").
Actualización del Plano: Actualizó el Plano Maestro basándose en los consejos de la IA.
Construcción y Prueba: La IA generó el código para las cinco aplicaciones.
El "Ojo Humano" de Control: Esta fue la parte más lenta. Hickey observaba manualmente las cinco aplicaciones una al lado de la otra. Si una se veía extraña, sabía que el Plano necesitaba ser corregido.

El Resultado

Tiempo: ~120 horas de trabajo nocturno (unas 7 semanas).
Producción: Cinco aplicaciones totalmente funcionales que comparten una lógica central.
Costo: En lugar de "múltiples años de desarrollador", le tomó a una sola persona unos pocos meses.

La Captura (Limitaciones)

El artículo es honesto sobre lo que esto no hace:

No es un producto terminado: A las aplicaciones les faltan algunas funciones avanzadas que se encuentran en herramientas profesionales (como mallas 3D complejas o funciones de impresión profesional). Es un "subconjunto sustancial", no un clon perfecto.
Depende de la IA: Si la IA se confunde o tiene "alucinaciones" (inventa código falso), el sistema lo detecta porque las cinco versiones no coincidirán. Pero si la IA es mala en una tarea específica, todo el proceso se ralentiza.
Necesita a un humano: La IA hizo la escritura, pero un humano tuvo que revisar los resultados, corregir la lógica y gestionar la "memoria" del proyecto para que la IA no olvidara lo que había decidido el día anterior.

La Gran Conclusión

Este artículo argumenta que la IA ha cambiado la economía de la ingeniería de software.
Anteriormente, construir múltiples versiones de un software para garantizar la calidad era demasiado costoso. Ahora, con la IA encargándose de la codificación repetitiva, un solo desarrollador puede construir un "jurado" de cinco aplicaciones para que revisen el trabajo de las demás. Esto convierte un método que fue abandonado en la década de 1980 debido al costo en una herramienta práctica para una sola persona hoy en día.

Resumen Técnico: La ingeniería emparejada con IA como un renacimiento de la programación de N-versiones

Planteamiento del problema
Las aplicaciones maduras de ilustración vectorial (por ejemplo, Adobe Illustrator, Inkscape) representan décadas de desarrollo por parte de grandes equipos sostenidos. Históricamente, extender tales aplicaciones o portarlas a nuevas plataformas se ha considerado inalcanzable para desarrolladores individuales debido al enorme volumen de código, la complejidad de los marcos de trabajo de la interfaz de usuario (UI) y la necesidad de una corrección rigurosa. El artículo investiga si la ingeniería emparejada con IA puede alterar esta realidad económica, permitiendo que un solo desarrollador produzca múltiples implementaciones de alta fidelidad de una aplicación de escritorio compleja en una fracción del tiempo tradicionalmente requerido.

Metodología
El autor, Jason Hickey, empleó una metodología centrada en dos salvaguardas específicas para permitir la "ingeniería emparejada con IA" a escala:

Una especificación precisa y ejecutable (Fuente única de verdad):
- El núcleo del proyecto es una especificación YAML de 23,000 líneas que define declarativamente los paneles, diálogos, herramientas, menús, modelos de estado y comportamientos reactivos de la aplicación.
- Esta especificación es ejecutable: un intérprete compartido (aprox. 12,500 líneas) lee el YAML al inicio y construye la interfaz de usuario directamente, en lugar de tratar el YAML como documentación para ser recodificada en cada lenguaje.
- La metodología utiliza un patrón de "escotilla de escape" (escape hatch): donde el YAML declarativo no puede expresar matices específicos de la plataforma (por ejemplo, renderizado acelerado por hardware, manejo específico de gestos), se escribe código nativo. Sin embargo, la lógica conceptual permanece en el YAML, asegurando que las decisiones de diseño se tomen una sola vez y se propaguen a todos los puertos.
Implementaciones paralelas como una capa de pruebas diferenciales integrada:
- En lugar de una única implementación, el desarrollador construyó cinco puertos funcionales en distintos lenguajes y marcos de trabajo: Rust (Dioxus), Swift (SwiftUI), OCaml, Python (PySide6) y un boceto basado en navegador con Flask/HTML.
- Estas implementaciones paralelas funcionan como un control continuo de corrección. Debido a que comparten la misma especificación pero utilizan diferentes renderizadores nativos e idiosincrasias de gestión de estado, las divergencias en el comportamiento o el resultado visual señalan inmediatamente un error en una implementación o una falta de especificidad en el YAML.
- Este enfoque revive la programación de N-versiones (Avizienis, 1985). Aunque la metodología original de la década de 1980 fue abandonada debido al costo prohibitivo de crear $N$ implementaciones independientes, el autor argumenta que la IA cambia fundamentalmente la economía. La IA gestiona el trabajo mecánico por puerto, haciendo que $N$ implementaciones sean factibles para un solo desarrollador, mientras que la diversidad de plataformas proporciona la independencia necesaria para detectar errores que las pruebas automatizadas pasan por alto.

Contribuciones clave

Un estudio de caso: Un solo desarrollador produjo cinco implementaciones multiplataforma de una aplicación de ilustración vectorial (27 herramientas, 14 paneles, 22 diálogos) durante aproximadamente 120 horas vespertinas (7 semanas de calendario).
Marco metodológico: Un flujo de trabajo específico que empareja una especificación ejecutable con implementaciones paralelas como una capa de pruebas diferenciales.
Informe de campo práctico: Documentación detallada de la ingeniería emparejada con IA en la práctica, incluyendo:
- Ingeniería de prompts: Bucles iterativos para convertir diseños en prosa a YAML y revisiones periódicas del código base.
- Gestión de estado: El papel crítico de la memoria persistente basada en archivos (57 entradas) para mantener el contexto a través de las sesiones.
- Modos de falla: Reporte honesto de las limitaciones de la IA, tales como "alucinaciones confiadas" de símbolos, deriva de contexto largo y la tendencia a elegir una interpretación de un requisito subespecificado sin señalar la ambigüedad.
Artefactos de código abierto: El proyecto completo, incluyendo la especificación de 23,000 líneas, los cinco puertos, 4,600 pruebas automatizadas y protocolos de prueba manual, está disponible en github.com/jyh/jas.

Resultos

Escala y alcance: El proyecto resultó en aproximadamente 336,000 líneas de código total (incluyendo el intérprete compartido y los cinco puertos). La especificación YAML compartida impulsó la lógica, mientras que el código nativo por puerto varió desde 0 líneas (OCaml, totalmente impulsado por YAML) hasta ~95,000 líneas (Rust, requiriendo un renderizado personalizado significativo).
Corrección mediante divergencia: La estrategia de implementación paralela identificó con éxito brechas en la especificación que habrían sido "silenciosamente erróneas" en un solo puerto. Ejemplos incluyen:
- El manejo de canales de color degenerados (por ejemplo, la saturación de HSB cayendo a cero).
- El tiempo de los comportamientos de "ajuste" (snap) en modos Web Safe RGB.
- La persistencia de estado en contextos de diálogo (por ejemplo, la reversión de campos hexadecimales).
- La lógica para "colores recientes" durante el arrastre de deslizadores.
Esfuerzo: El esfuerzo total se estimó en 120–160 horas de desarrollo. El autor señala que un solo puerto de alcance comparable utilizando herramientas convencionales requeriría típicamente 1–2 años de desarrollador; cinco puertos requerirían convencionalmente múltiples años de desarrollador.

Significado y afirmaciones
El documento no afirma que la aplicación resultante iguale la completitud de funciones de las herramientas comerciales maduras (carece de tipografía avanzada, efectos de rasterización y fidelidad completa de SVG). En su lugar, su importancia radica en demostrar un cambio en el límite de factibilidad para desarrolladores individuales.

El autor argumenta que, al combinar una especificación ejecutable precisa con implementaciones paralelas generadas por IA, un solo desarrollador puede alcanzar un alcance de trabajo que convencionalmente requiere múltiples años de desarrollo. Esto se enmarca como un renacimiento de la programación de N-versiones, donde la barrera económica para crear múltiples implementaciones independientes ha sido reducida por la IA. La metodología sugiere que, para dominios describibles de forma declarativa (como la UI y la lógica de aplicación), el valor de "pruebas diferenciales" de múltiples puertos puede realizarse sin la penalización de costo tradicional, siempre que se mantenga un riguroso control manual de pruebas y protocolos de gestión de memoria.

El documento mantiene la modestia, reconociendo que los resultados son una instantánea de las capacidades actuales de la IA (Claude Opus 4.6/4.7 en 2026) y que la metodología depende fuertemente de la experiencia de dominio del desarrollador y su capacidad para gestionar los modos de falla de la IA. La afirmación no es que la IA reemplace la necesidad de supervisión humana, sino que cambia la ecuación económica de la programación de N-versiones, haciendo que sea una estrategia viable para desarrolladores individuales para asegurar la corrección y la portabilidad.