Crear una app para Mac con Claude Code

• Con Claude Code generó casi todo el código completo de una app de macOS de más de 20 mil líneas y la lanzó; el código escrito directamente por la persona fue de menos de 1,000 líneas
• Con la llegada de los agentes de programación con IA, la experiencia de desarrollo pasa de los IDE tradicionales a un enfoque centrado en prompts
• La generación de código en Swift y SwiftUI tiene ciertas limitaciones, pero se puede mejorar la calidad diseñando bien el priming, la ingeniería de contexto y los ciclos de retroalimentación
• Automatización, despliegue, documentación y pruebas: Claude se encargó de la mayor parte, reduciendo drásticamente el trabajo manual repetitivo y el tiempo invertido
• El IDE del futuro evolucionará hacia una nueva UX centrada no en el editor de código, sino en el uso de agentes y la gestión del contexto

---

La experiencia de lanzar una app de macOS solo con Claude Code

Resumen del proyecto

• Recientemente lanzó una app nativa de macOS llamada Context. Es una herramienta para desarrolladores para depurar servidores MCP
• Esta app fue hecha casi al 100% con Claude Code. De unas 20 mil líneas, ni siquiera 1,000 fueron escritas directamente por la persona
• Crear software con Claude todavía requiere habilidad del desarrollador, trabajo iterativo y capacidad para escribir buenos prompts
• Este artículo explica en detalle todo el proceso de crear la app con Claude Code, la elección de herramientas, sus ventajas y desventajas, y cómo generar código de alta calidad

1. De Copilot a Claude Code, y el cambio en el entorno de desarrollo

• La primera herramienta de programación con IA que usó fue GitHub Copilot, y notó que incluso el autocompletado simple aumentaba mucho la eficiencia de desarrollo
• Después aparecieron en masa herramientas de tipo agente como el modo agente de Cursor y Windsurf, que reúnen contexto de la base de código y automatizan incluso los ciclos de build y pruebas
• A diferencia de editores tradicionales como VS Code, Claude Code busca ser un entorno de agente puro, exclusivo de terminal y centrado en la entrada por prompts
• Es una UX simple que elimina la mayoría de las funciones típicas de un IDE y solo muestra una caja de prompt y el resultado
• El agente de programación no solo asiste al IDE existente, sino que intenta reemplazarlo por completo
• Aunque al principio era escéptico por la diferencia en interfaz y experiencia de uso respecto a las herramientas tradicionales, decidió probarlo porque le atrajo este nuevo enfoque

2. Retomar un side project

• Como muchos desarrolladores que trabajan tiempo completo, tenía una acumulación de side projects sin terminar
• Los prototipos se hacen rápido, pero en el último 20% del proceso falta tiempo y energía, así que muchas veces no llegan hasta un lanzamiento real
• A partir de la experiencia de probar servidores MCP, decidió crear personalmente una app nativa porque vio que hacía falta
• Fue en este proceso cuando empezó a usar Claude Code en serio y comprobó de primera mano cuánto puede ayudar un agente de IA

3. La gran capacidad de Claude Code para generar código

• Claude Code, que usa los modelos más recientes Sonnet 4 y Opus 4, realmente produce buen código con rapidez
• Lee el contexto del proyecto, entiende el estilo del código, consulta documentación y especificaciones relacionadas, implementa funciones y también escribe pruebas automáticamente
• Casi todo queda automatizado: build, iteración de pruebas, análisis de logs de consola y capturas de pantalla, e incluso corrección de bugs
• Con una fracción mínima del tiempo que normalmente dedicaría un desarrollador a escribir código, genera resultados de alta calidad
• Alcanza un nivel comparable al de incorporar a un empleado junior a un proyecto sin contexto previo y que complete una funcionalidad en pocos minutos

4. La calidad real del soporte para Swift y SwiftUI

• Se usó Swift 6.1, macOS 15.5 y la versión más reciente de SwiftUI
• Claude maneja bastante bien Swift hasta la versión 5.5, pero es más débil frente a cambios recientes como la concurrencia
• A veces comete errores al mezclar APIs modernas y legacy, así como Objective-C y SwiftUI
• En el caso de SwiftUI, los primeros borradores pueden ser algo incompletos o toscos, pero con indicaciones iterativas se pulen bastante bien
• Cuando el código de UI se vuelve complejo, aparecen errores del compilador como fallos de inferencia de tipos, y Claude puede refactorizar automáticamente en funciones más pequeñas
• Si se dejan instrucciones claras en el archivo CLAUDE.md, se puede elevar aún más la calidad del código de Claude
  • Por ejemplo: priorizar SwiftUI, seguir las Apple Human Interface Guidelines, aprovechar activamente las funciones más recientes de macOS y Swift 6, etc.
• Además, si se usan las guías del repositorio agent-rules, es posible generar código de aún mayor calidad

5. Se le puede pedir: "hazlo más bonito"

• Con prompts simples como "hazlo más bonito / más elegante / más usable", Claude puede mejorar el diseño de la UI
• Los bugs o mejoras de UI se pueden resolver pegando capturas de pantalla en Claude y dándole retroalimentación iterativa para que lo aplique de inmediato
• De forma más sistemática, también se le puede pedir primero: "propón cómo hacer más bonita la UI", y luego elegir solo los cambios deseados para aplicarlos

6. La importancia de la ingeniería de contexto

• Los modelos de IA recientes entienden bastante bien incluso prompts incompletos o con errores gramaticales
• Lo realmente importante es colocar solo la información necesaria dentro de una ventana de contexto limitada (200k tokens)
• Cuando Claude llena el contexto de la conversación, hace una compactación automática y reinicia el contexto con un resumen, pero en ese proceso existe riesgo de pérdida parcial de información, como detalles omitidos o degradación de calidad
• Por eso, la tarea clave al usar agentes de IA es la "ingeniería de contexto" para obtener el mayor nivel de calidad posible dentro de un contexto limitado

7. Priming del agente

• Como en este proceso de compactación se puede perder contexto importante, conviene en algunos casos pedir resúmenes manuales o hacer priming con información adicional
• Además de CLAUDE.md, si se le pide por prompt que lea y resuma por adelantado cierto código fuente o documentos de especificación, mejora la calidad de salida
• Incluso para bibliotecas nuevas o APIs recientes aparecidas después del cutoff de conocimiento de Claude, se puede convertir la documentación con herramientas específicas como Context7 o llm.codes para que Claude la entienda mejor
• El priming consiste en indicaciones como: "lee todos estos archivos fuente, documentos y especificaciones, y hazme un resumen", para que Claude comprenda por completo el contexto antes de empezar

8. El agente necesita una especificación clara (Spec)

• Para que Claude implemente una funcionalidad, hay que darle una especificación concreta y detallada si se quiere obtener el resultado esperado
• Lo de "crear una app con un prompt de una sola frase" que suele verse en demos en realidad solo alcanza nivel de prototipo
• Aunque la especificación no sea perfecta, basta con explicarla de la forma más cómoda, ya sea escribiendo o por voz

9. "Ultrathink and Make a Plan"

• Si Claude se lanza a implementar sin más, la calidad de salida baja, así que funciona bien pedirle primero que planifique usando modos de razonamiento extendido como think o ultrathink
• La calidad mejora si se revisa el plan paso a paso y se da retroalimentación antes de cada implementación
• Recomienda como lectura obligatoria el documento de Anthropic Claude Code: Best practices for agentic coding

10. Construir ciclos de retroalimentación

• La verdadera fortaleza de Claude Code se maximiza cuando puede operar ciclos de retroalimentación de forma independiente
• Es decir, lo clave es construir un ciclo automatizado en el que Claude modifique el código, haga el build, analice la causa de fallos reuniendo contexto y vuelva a iterar
• Mientras mejor se diseñen estos ciclos, más autónomamente podrá Claude completar código de alta calidad
• 1. Build
  • Claude debe poder realizar por sí mismo el proceso de build (compilación) de la app
  • En el caso de paquetes Swift, se puede compilar fácilmente con el comando swift build, y Claude lo maneja de forma natural
  • Pero en el caso de un target de app de macOS (por ejemplo, un proyecto de Xcode), Claude a menudo se confunde sobre qué comando xcodebuild debe usar
  • Para resolver este problema, usó una herramienta llamada XcodeBuildMCP, que le da a Claude una interfaz simplificada para construir y ejecutar la app con más facilidad
• 2. Test
  • Después de compilar el código, Claude debe poder ejecutar automáticamente las pruebas y analizar sus resultados
  • En paquetes Swift, las pruebas se ejecutan naturalmente con swift test, y Claude maneja bien ese proceso
  • Aún no probó que Claude ejecute directamente pruebas de toda la app o pruebas de UI, pero cree que también harían falta herramientas como XcodeBuildMCP
  • A partir de los resultados de las pruebas (logs de éxito o error), continúa el ciclo de corrección del código
• 3. Fix Bugs
  • Claude puede rastrear problemas agregando logs para depuración
  • Sin embargo, no puede manipular la app por sí mismo para generar esos logs
  • Hace falta que la persona use manualmente la app y luego copie los logs desde la consola para pegárselos a Claude
  • Este enfoque funciona bien en la práctica, pero si no se escriben suficientes pruebas unitarias o de UI desde antes, resulta difícil lograr una corrección de bugs totalmente automática
  • Para apps web existen soluciones de automatización de navegador como playwright-mcp, pero para apps nativas todavía faltan alternativas claras
• 4. Fix UX Issues
  • Para mejorar problemas de UI/UX se puede pegar capturas de pantalla directamente en Claude y darle retroalimentación iterativa
  • Herramientas como Peekaboo permiten automatizar capturas, pero siguen teniendo la limitación de que primero hay que llevar manualmente la app al estado deseado para poder tomar la captura
  • Es decir, incluso la automatización relacionada con UX todavía requiere intervención del usuario

11. Claude Code hace más que escribir código

• Como Claude Code funciona sobre un modelo de lenguaje grande (LLM) de propósito general, también puede usarse en muchas tareas no relacionadas directamente con desarrollo
• Por ejemplo, se le pueden pedir de manera natural tareas como editar textos dentro de la app, planear un release o proponer direcciones de mejora para funciones
• Una de las cosas especialmente útiles fue su capacidad de generar datos mock automáticamente en etapas tempranas cuando aún no había datos reales
  • Durante el desarrollo de la app Context, todavía no estaba terminada la biblioteca cliente de MCP para Swift, pero quería avanzar con prototipos de UI
  • En circunstancias normales, crear a mano datos mock convincentes habría sido muy tedioso y demandado mucho tiempo, así que probablemente ni siquiera lo habría intentado
  • Pero Claude generó en segundos datos mock muy creíbles, suficientes para crear estados de UI casi indistinguibles de los reales
  • De hecho, cuando compartió la UI con amigos, usó capturas basadas en esos datos mock y lograban una impresión comparable a la de un servicio real
  • En el caso de los servidores MCP, en ese momento muchas implementaciones solo cubrían una parte de la especificación oficial, así que era difícil obtener datos reales
  • Aun así, gracias a los datos mock generados por Claude, fue posible validar todo el flujo de la UI y el funcionamiento de las funciones

12. La era en que implementar automatización de alta calidad es (casi) gratis

• Una de las partes más dolorosas del último 20% al lanzar software es la automatización del proceso de release de la app
• En particular, en apps de macOS hay muchos pasos de despliegue complejos, como firma de código, notarización y empaquetado (creación de DMG), que antes solían retrasar el lanzamiento por depender de trabajo manual o scripts inestables
• Antes se terminaba configurando a la fuerza herramientas de automatización como fastlane o escribiendo scripts mínimos en Python
• En este proyecto, con solo unas cuantas horas de prompts iterativos y depuración, Claude generó un script completo de automatización de release
• Las tareas principales de ese script incluyen:
  • Verificación de configuración del entorno: comprobar que las herramientas necesarias estén correctamente instaladas
  • Generación automática del changelog: extraer historial de cambios desde commits de git y combinarlo con elementos escritos manualmente para generar release notes en HTML
  • Build y empaquetado de la app: automatizar todo el proceso desde build → firma de código → notarización → empaquetado DMG
  • Generación del feed de actualizaciones de Sparkle (appcast): entregar actualizaciones automáticas a usuarios existentes
  • Etiquetado y publicación del release: agregar tags en GitHub y publicar el release
  • Subida de símbolos a Sentry: cargar automáticamente símbolos de depuración para analizar crash reports
• Después de terminar el script, incluso pudo mejorar la UI de la CLI con un prompt de una sola línea: "haz más bonito el output de la CLI"
• El resultado final fue código Python de unas 2,000 líneas; si lo hubiera hecho manualmente, probablemente se habría quedado solo con lo indispensable, pero gracias a Claude logró terminarlo con alta calidad
• Gracias a este script de automatización, ahora ahorra decenas de minutos de trabajo repetitivo en cada release
• Basta con describir la especificación en lenguaje natural y luego dar retroalimentación a Claude sobre los errores detectados durante la ejecución para que complete la mayor parte del trabajo

13. El IDE del futuro será completamente distinto

• Durante este proyecto, las únicas dos herramientas que realmente usó de principio a fin fueron Claude Code y GitHub Desktop (para ver diffs)
• Casi no hicieron falta funciones centrales de un IDE tradicional como árbol de archivos, editor de código, extensiones o plugins
• En contadas ocasiones abrió Xcode para corregir código directamente, pero casi no usó funciones propias de Xcode como SwiftUI Previews o el View Debugger
• Justamente porque este es el momento en que las capacidades de los agentes de programación con IA están en su punto más bajo, intuye que en adelante los IDE evolucionarán hacia una forma completamente nueva

• Copilot, Cursor y Windsurf partieron todos de VS Code y fueron agregando funciones, pero VS Code en sí casi no difiere de los IDE de JetBrains de hace 20 años
• Proyectos como Warp intentan modernizar la terminal y convertirla en un entorno de desarrollo para agentes, pero considera que una UX centrada en la terminal tampoco será la respuesta definitiva del futuro

• La clave del IDE del futuro será permitir que el desarrollador prepare eficazmente el contexto del agente (priming) y diseñe y gestione ciclos de retroalimentación
• Es decir, la perspectiva es que dejará de girar alrededor del editor de código para transformarse profundamente en una UX centrada en el uso de agentes y la gestión del contexto

14. Volver a lanzar side projects

• Lo más impactante de este recorrido no fue tanto haber creado una app genial, sino haber recuperado la capacidad de volver a lanzar side projects reales por cuenta propia
• Como si hubiera ganado 5 horas extra cada día, y todo eso por apenas $200 al mes
• Gracias a agentes de programación con IA como Claude Code, recuperó el impulso y la confianza para convertir en realidad ideas que había postergado durante mucho tiempo

[geek12356]

Hazlo mucho

[GN⁺]

Comentarios de Hacker News

• Hasta hace apenas 2 años, yo estaba convencido de que era un ingeniero de Python realmente sobresaliente, pero ahora puedo crear en días o incluso horas apps móviles nativas, apps de escritorio que se comunican con Slack, APIs escritas en Go y hasta aplicaciones web completas basadas en React.
  Se siente como haber obtenido un superpoder, como si brotaran la productividad, la velocidad y la creatividad, pero al mismo tiempo también siento una tristeza extraña.
  Mi profesión, mi pasión y todo aquello que me costó tanto tiempo aprender y por lo que incluso hice sacrificios, ahora está siendo reemplazado en gran parte por máquinas.
  Las empresas que hacen estas herramientas apenas están en la línea de salida.
  Me pregunto qué significará esto para la próxima generación de ingenieros y hasta dónde llegará esta tendencia.
  También me pregunto si alguien más siente lo mismo que yo.

  • Haber llegado a manejar con eficiencia herramientas tan diversas como nativo, móvil, Go y React en múltiples plataformas fue posible gracias a mi experiencia en desarrollo de software como ingeniero de Python.
    Lo que los LLM reemplazan es la necesidad de memorizar detalles menores y específicos de cada plataforma.
    Aunque no me sepa de memoria la sintaxis de un for en Go, aun así puedo escribir código útil en Go de inmediato.
    Sigue siendo indispensable entender los principios básicos: bucles, conceptos de Go, programación estructurada, compiladores y scripts de build y de pruebas.
    A la gente sin formación en programación le falta mucho en esa parte.
    Siento que los LLM son un amplificador y acelerador que vuelve aplicable de inmediato a distintos lenguajes y plataformas el conocimiento difuso que he acumulado durante una larga carrera.
    Antes resolvía todo solo con Python, JavaScript y SQL porque me daba flojera volver a aprender las diferencias menores de cada nuevo lenguaje o plataforma.
    Ahora uso con gusto Go, Bash, AppleScript, jq, ffmpeg, e incluso estoy considerando proyectos en Swift.

  • He visto a personas sin formación técnica crear cosas con LLM, y por lo general son mucho más lentas o casi siempre fracasan.
    Puede que las habilidades técnicas no sean estrictamente indispensables al final, pero la capacidad de comunicarse con claridad sí lo es.
    Incluso con solo entender HTML, uno puede insertar texto de forma ordenada para que el LLM entienda mejor y con más claridad.
    Sigo creyendo que tener base técnica es una ventaja.

  • Creo que los trabajadores artesanales de antes de la Revolución Industrial debieron sentir algo parecido.
    Pero hay que tener en cuenta que la mayoría no recibía educación adecuada, que 1 o 2 de sus hijos morían antes de los 10 años por enfermedades menores, y que vivían sin electricidad, agua corriente, plomería interior ni refrigeradores.
    Fabricar herramientas con las propias manos tiene algo romántico, como escribir código Python totalmente a mano, pero a medida que la época avanza, creo que vivir en capas más abstractas termina siendo una ventaja incluso para nuestros antepasados.
    Nadie te impide escribir tu propio código Python a mano, y seguro habrá gente que lo disfrute como hobby, igual que quien practica artesanía con grafito.

  • Me cuesta estar de acuerdo con la idea de que ahora las máquinas sustituyen la profesión, la pasión y las habilidades que he construido.
    Las máquinas solo siguen instrucciones, sin experiencia, previsión, reflexión, capacidad de planificación ni creatividad.
    Solo las personas tienen ideas, creatividad, objetivos y empatía, y pueden persuadir a otras con buenas ideas o considerar el contexto según la situación.
    Más que desaparecer, creo que la profesión de programador se está moviendo a un nivel de abstracción mucho más alto.
    Antes uno podía ser desarrollador sin saber nada de bits, bytes o una sola línea de ensamblador, aunque hubo una época en que el ensamblador era indispensable.
    Ahora vivimos en una era en la que ya ni siquiera hace falta conocer un lenguaje de programación; basta con entender bien el inglés y los requisitos para que se produzca un programa.
    Aun así, quienes entienden la estructura de memoria, el ensamblador y los conceptos de bajo nivel siguen comprendiendo mejor lo que ocurre detrás y, cuando hace falta, pueden hacerlo mejor.
    Eso no significa que las capas superiores de abstracción se vuelvan inútiles o vayan a desaparecer.

  • Yo siento exactamente lo mismo.
    Llevo más de 20 años desarrollando software de manera profesional, y de verdad disfrutaba mucho este trabajo.
    Ahora uso Claude Code al 100% y mi productividad claramente ha subido, pero antes el proceso se sentía como un arte, mientras que ahora da la impresión de producción industrial en masa.
    Quiero volver a encontrar algo propio que me permitía sumergirme a fondo en el software dentro de esta nueva realidad, y es cierto que gran parte de esa diversión se ha reducido.

• Está muy bien escrito y da gusto leerlo.
  Los IDE del futuro serán completamente distintos a los de hoy.
  Yo también empecé con Cursor, luego usé IDE potenciados sobre VS Code y al final terminé pasándome a Claude Code.
  Eso hizo que la terminal cobrara más importancia, así que migré mi flujo de trabajo en iTerm hacia Ghostty (rápido, ligero y moderno), Tmux, Tmuxinator y NeoVim.
  Reviso archivos con los comandos cat o bat, a veces solo edito texto, y casi todo el trabajo pesado se lo dejo a Claude Code.
  En NeoVim o Emacs básicamente solo escribo especificaciones y prompts, y me encanta este flujo de trabajo.
  No solo para generar código: también le asigno tareas a Claude Code cuando necesito modificar archivos de configuración de zsh, neovim, ghostty, etc.
  Hasta refactorizar archivos de configuración toma solo unos minutos.
  También le encargo preguntas sobre el codebase, refactors, documentación del código, generación de mensajes de commit y demás. Pure awesomeness.

  • Al final mencionaste que también hace preguntas sobre el codebase, refactors, documentación del código e incluso commits con sentido; yo también tuve la experiencia de lograr excelentes mensajes de commit con CC poniendo información y ejemplos de Conventional Commits en el archivo CLAUDE.md.

  • Me pregunto si CC hace respaldo automático de archivos personales de configuración como .zshrc antes de modificarlos.

• Terminal + Claude Code + carpeta del proyecto
  De verdad apenas ahora me doy cuenta de que con eso basta.
  Nunca me gustó mucho configurar un IDE completo porque era engorroso, y para compilar de forma cruzada según el SO la configuración de QT también era complicada, así que siempre pensé que la combinación editor + terminal era la más lógica.
  Ahora, con Claude Code ayudando a procesar solicitudes como otra ventana de terminal abierta, siento que subí de nivel: de desarrollador a líder de proyecto.
  Y sin el estrés de administrar empleados.
  Desde que salió Claude en marzo, en apenas unos meses he terminado todos los side projects que llevaba tiempo queriendo hacer.

• Hace 1 o 2 años pensé algo así: para un desarrollador experimentado, los LLM son asistentes excelentes; si intentas que reemplacen a un desarrollador experimentado, son un desastre; y para un desarrollador inexperto, son asistentes peligrosos.
  Cuando lo experimentas por ti mismo, en general esa idea encaja bastante bien.
  Ahora sí creo que para desarrolladores inexpertos los LLM pueden llegar a ser buenos mentores, pero en la práctica parece mucho más común ver a gente haciendo cambios al azar sin entender por qué el código funciona, repitiendo intentos hasta que más o menos corre.
  Al final, en ese contexto, se me reafirma más la idea inicial de que los LLM son asistentes peligrosos.
  En esos casos, los bugs sutiles o problemas quedan escondidos en el código sin que nadie los note, y aun cuando se detectan, muchas veces no se entiende su causa.

• Me impresionó especialmente la conclusión de que, gracias a los asistentes LLM, el último 20% para terminar un side project se redujo muchísimo.
  Para mí, lo más interesante de este recorrido no son las apps nuevas, sino que ahora puedo saciar mis ganas de programar y volver a publicar side projects limpios y bien terminados.
  Es como si de pronto tuviera 5 horas extra al día, y con 200 dólares al mes basta.

• Yo lo uso sobre todo para crear pequeñas utilidades, y funciona increíblemente bien.
  Con Claude logré implementar en unas pocas horas, tal como quería, una utilidad que muestra el estado de tareas de launchctl/launchd (ejecutándose / descargadas / fallidas, etc.) como el ícono de menú de OrbStack.

  • Yo también hice una app de iOS y un plugin de Wordpress para mi propio disfrute, y quedé realmente satisfecho.
    Creo que cada vez más gente hará esto; me pregunto si no deberíamos compartir todos ese código en github.

• Si alguien lleva haciendo software para Mac desde 2008, seguramente habría detectado rápido en qué se estaba equivocando Claude y lo habría corregido enseguida.

  • Herramientas como Claude Code sirven para amplificar habilidades y experiencia previas.
    De ningún modo reemplazan la pericia.

  • Al final, en la última parte del texto se revela que este trabajo cuesta 200 dólares al mes, y a mí hasta me cuesta gastar 50 dólares en Autodesk, aunque sea algo indispensable para mi hobby principal.
    Creo que estas empresas de IA ni siquiera son rentables, y cuando los inversionistas empiecen a exigir ganancias será inevitable que suban mucho los costos o que baje la calidad del servicio.
    Si estos modelos terminan perdiendo demandas por ofrecer código con el que fueron entrenados sin autorización, la capacidad de Claude para generar Swift también caerá de inmediato.
    ¿De verdad hay que esperar que Disney pierda en las demandas contra la IA? Lo dudo.
    Sinceramente, quizá mi comentario no aporte mucho, pero el cansancio con la IA ya es realmente grave.
    A estas alturas, creo que este tipo de posts deberían prohibirse en HN y en otros foros de tecnología.
    Si alguien publicara que escribió código fácilmente usando Google o StackOverflow, todos responderían con sarcasmo porque sería algo trivial; creo que estos posts son básicamente lo mismo.
    Ya cansa eso de presumir que uno puede "colgarse gratis" de la IA para sus hobbies o su trabajo.

• Hacer herramientas personalizadas para mí con cosas como Windsurf y herramientas CLI se volvió muchísimo más fácil que antes.
  Es una época realmente interesante.

• Siento que pronto llegará el día en que alguien use un LLM para clonar macOS entero.

• Hace unas semanas, usando tooling con LLM, retro68 y c++, logré hacer funcionar un renderizador wireframe de 6DOF en una app para System 6 (Mac clásico).