Antes de integrar código open source escrito por IA, haz una comprobación de tres preguntas
Comprueba la paridad, la salida principal que falta y la licencia antes de integrar código open source generado por IA en un producto de una sola persona.

Estás mirando un repositorio que parece ser el componente que falta en tu producto. Tiene una interfaz limpia, un README con capturas de pantalla y una insignia de licencia que parece prometedora. Copiar el código es la parte fácil. La parte difícil es decidir si el próximo tramo de trabajo se dedicará a arreglar lo que el modelo dejó a medias.
Un proyecto reciente muestra la trampa. Brandon Thomas, un desarrollador con base en Atlanta, dijo que usó Claude Opus 5.5, un modelo de IA, y Rust, un lenguaje de programación de sistemas, para recrear siete aplicaciones de Adobe, incluyendo Photoshop e Illustrator. Las herramientas eran reemplazos clean-room en Rust para los programas cerrados de Adobe, con compilaciones para navegador incluidas. PhotoCraft reportó cobertura completa de menús, con una precisión de coincidencia de píxeles cercana al 65 %. Los niveles de finalización eran desiguales: EffectCraft se situó en torno al 94 %, FilmCraft en torno al 85 % y PrintCraft en torno al 35 % sin un renderizador PDF.
Para un operador en solitario, integrar una herramienta creativa recreada es, ante todo, una decisión de mantenimiento. Estás adoptando una base de código cuyo autor puede ser un agente, un desarrollador en solitario o ambos. Dedica una hora antes de compilar para que la brecha sea visible antes del lanzamiento.
Responde estas tres preguntas antes de copiar el código
Cada pregunta de abajo es un requisito, no una puntuación. Si no puedes responderla con claridad, detente y trata el repositorio como una demo, no como una dependencia.
- Paridad: ¿El código realmente hace el trabajo que necesitas, o solo el trabajo que parece impresionante en una demo? Ejecuta el flujo de trabajo principal con datos reales, no con archivos de muestra. Si la salida es lo suficientemente cercana para tu cliente, anota dónde se queda corta.
- Salida principal que falta: ¿Cuál es la salida principal que tu cliente espera y que el proyecto no ha publicado? Un renderizador, exportador o formato que falta puede convertir una pequeña omisión en un producto entero.
- Licencia: ¿Qué te permite hacer la licencia con el código y qué te obliga a publicar? Lee el archivo de licencia, no la insignia.
La paridad importa porque una demo puede ocultar lo que un menú no puede mostrar: un pipeline funcional. La salida que falta suele ser la salida por la que tu cliente paga. La licencia va antes de copiar porque una insignia permisiva puede seguir llevando obligaciones que no esperabas.
La licencia es la última pregunta, no la primera
Una insignia de licencia es solo un resumen; el contrato es el archivo. Los siete repositorios llevaban licencias MIT o Apache-2.0 y se ejecutaban de forma nativa en macOS, Windows y Linux, además de WebAssembly. Apache 2.0 permite el uso comercial, la modificación y la redistribución sin límites adicionales. Un desarrollador en solitario a menudo puede integrar ese código sin activar de inmediato una obligación de publicación. Pero la GPL es diferente: exige a quien usa públicamente una versión modificada que publique el código fuente modificado.
Joseph Saveri Law Firm y Matthew Butterick presentaron a finales de 2022 una demanda colectiva alegando que Microsoft y OpenAI violaron licencias open source en relación con GitHub Copilot. No necesitas resolver esa cuestión legal antes de empezar. Sí necesitas saber si el código que estás integrando proviene de una fuente cuya licencia puedes leer y defender de verdad.
Lee los informes de errores como tu estimación de mantenimiento
El rastreador de errores es la parte más honesta del repositorio. Pocos issues significan que la estimación de mantenimiento es desconocida, no inexistente. Los issues mayoritariamente cosméticos pueden ser algo con lo que puedes lanzar. Los issues agrupados en torno a la exportación, el rendimiento o la compatibilidad de archivos son la lista de cosas que arreglarás después del lanzamiento.
Los hilos de la comunidad te dicen lo mismo desde fuera. El proyecto llegó a la portada de Hacker News, reuniendo 107 puntos y 165 comentarios. Ese tipo de atención es útil, pero no es un certificado de calidad. Un hilo en portada puede estar lleno de entusiasmo, y el entusiasmo puede ser por la idea, no por el código. Cuenta las horas que dedicarías a responder las preguntas de esos hilos, porque esas son las horas que tus clientes te pedirán que dediques.
El desarrollador dijo que las aplicaciones gratuitas con licencia MIT/Apache se sostendrían vendiendo acceso basado en tokens al modelo de IA visual actual de Artcraft y su IDE. Ese modelo de negocio no es el tuyo. Importa porque te dice en qué está optimizando el autor. Si el repositorio gratuito existe para dirigir a los usuarios hacia un modelo de pago, las funciones que faltan pueden faltar a propósito. Lee la lista de issues antes de decidir si esa brecha es la que te toca construir.