Convierte un puerto de Amiga de 1993 en un nicho de código legado con un LLM
Un puerto de un juego de Amiga poco conocido, hecho en un fin de semana con un LLM, puede convertirse en un nicho de código legado de pago si la prueba es verificable.
La prueba es el producto
La mayoría de los proyectos paralelos se quedan como proyectos paralelos, y está bien. Los que se convierten en negocios suelen hacerlo convirtiendo un artefacto pequeño y difícil en evidencia. En el código legado, lo más raro no es otro puerto. Es una prueba que puedes mostrar a un desconocido: lo antiguo todavía funciona, lo nuevo es fiel y el proceso estuvo controlado.
Rabah Shihab construyó el juego de Amiga Babylonian Twins en 1993 en Bagdad en un Amiga 500, escribiéndolo en ensamblador 68000 puro. Ese tipo de artefacto es un caso de prueba perfecto para un creador con horas limitadas: es antiguo, pequeño, cargado emocionalmente e imposible de falsificar.
El juego fue el primer título comercial de Irak, pero se mantuvo sin publicar después de que Commodore, el fabricante de Amiga, colapsó y las sanciones asustaron a las editoras. La historia le da a la obra una razón para existir más allá de una demo. También muestra por qué la preservación es un servicio: el software antiguo no envejece bien, y las personas que lo necesitan a menudo no tienen tiempo para convertirse en investigadores.
Los discos originales pueden obtenerse sin costo desde itch.io, mientras que la Definitive Edition reconstruida está disponible en iOS y Android, con un lanzamiento en Steam que, según se dice, es para el otoño. La distribución importa, pero la lección más profunda es que un artefacto terminado puede sostener un nicho. Si puedes restaurar algo poco conocido y demostrarlo, puedes vender la misma confianza a estudios, aficionados y propietarios de sistemas embebidos que tienen miedo a su propio código antiguo.
Un puerto manual anterior para iPhone en 2010 usó un motor creado desde cero de aproximadamente 34,000 líneas de C++ y alcanzó más de dos millones de descargas. Perseguir ese número pasa por alto el punto: el trabajo de código legado puede tener una cola larga cuando la prueba es lo suficientemente concreta para que un desconocido pueda confiar en ella.
No hizo el puerto él mismo; la IA se encargó del trabajo de formatos de archivo y ensamblador, mientras él solicitaba, probaba y tomaba decisiones. Esa división del trabajo es el modelo de negocio real para un creador con horas limitadas. El LLM hace la lectura tediosa y los primeros borradores. Tú conservas el juicio, las pruebas y la decisión final sobre lo que cuenta como fiel.
El LLM logró que las fuentes de 1993 se ensamblaran de nuevo con un ensamblador en un Mac de Apple Silicon, continuando hasta que la salida coincidiera con los binarios enviados byte a byte. Ese es el tipo de objetivo que hace que un proyecto paralelo se sienta como un servicio: no 'parece cercano', sino 'aquí está la comprobación, y pasa'.
La escalera de producto de código legado
Usa la misma forma para tu propio proyecto de fin de semana. El objetivo es una prueba repetible de que puedes tomar código antiguo y frágil y volverlo confiable de nuevo, no una empresa de restauración de juegos retro. El alcance puede mantenerse pequeño.
- Elige un artefacto. Elige algo lo suficientemente pequeño como para terminarlo en unos pocos fines de semana: un juego homebrew, una utilidad antigua, firmware de controlador, una demo, un formato de nivel, un archivo de guardado o un solo módulo de una base de código más grande. El artefacto debe tener un propietario claro, un modo de fallo claro y una razón por la que alguien pagaría para entenderlo.
- Define un objetivo verificable. Decide qué significa 'hecho' antes de empezar. Que sea jugable es bueno. Ser idéntico byte a byte es más fuerte. Una suite de pruebas que pasa, una suma de verificación, una grabación antes y después o un diff que explica cada cambio pueden funcionar. El objetivo debe ser algo que un lector escéptico pueda comprobar sin confiar en tu palabra.
- Deja que el LLM haga la lectura. Pídele que lea formatos de archivo, explique ensamblador, compare binarios, proponga traducciones y genere casos de prueba. Mantén los prompts acotados. No pidas un puerto completo en un solo mensaje. Pide una hipótesis, un parche, una explicación, una prueba. Tu labor es mantener el trabajo acotado y la evidencia limpia.
- Documenta la prueba. Escribe las notas que querrías si fueras el cliente. Incluye el estado inicial, el objetivo, los comandos que ejecutaste, los fallos que viste, las decisiones que tomaste y el resultado final. Una breve publicación pública es suficiente. El documento es el producto. También es la página de ventas.
- Vende preservación, puertos o migración. Una vez que existe la prueba, empaqueta la misma habilidad. Ofrece una auditoría de alcance fijo para código antiguo, una pasada de preservación para un juego homebrew, un plan de migración para firmware embebido o un informe de compatibilidad para una herramienta legada. Vendes la confianza de que lo antiguo puede entenderse, probarse y llevarse adelante, no horas.
Qué lo convierte en un nicho, no en una demo
Una demo es algo que hiciste. Un nicho es algo que puedes hacer de nuevo para otra persona. La diferencia suele ser la prueba. Si tu publicación dice 'lo porté', es una demo. Si dice 'aquí está el binario antiguo, aquí está la nueva compilación, aquí está la prueba y aquí está por qué la diferencia es aceptable', es un servicio.
Mantén el alcance lo suficientemente pequeño como para que un fin de semana realmente lo termine. Esa es la ventaja silenciosa del nicho de código legado: no necesitas un equipo, un servidor ni un presupuesto de marketing. Necesitas un artefacto, un objetivo, una investigación asistida por LLM y un documento que haga el resultado verificable.
Empieza con un artefacto y un resultado verificable. Si funciona, tienes un nicho. Si no, tienes una lección útil y una base de código más limpia.