Compositor: la IA abarata el desarrollo clean-room
Compositorclean-room разработкаИИ для программированияopen source
Compositor no es Photoshop, pero la señal es seria
No calificaría a Compositor como un clon demostrado de Photoshop: los materiales disponibles no prueban una completitud ni una compatibilidad de ese nivel. La página del proyecto Compositor de Robbie Tilton abrió el debate sobre crear rápidamente un editor gráfico clean-room con ayuda de IA. En septiembre de 2026, la señal principal no es que «Photoshop esté listo en días», sino que el paso de una especificación al código se ha abaratado drásticamente.
El respaldo cuantitativo más sólido para esta tesis no viene de Compositor, sino de la publicación MirrorCode. Allí, un modelo de frontera reimplementó una herramienta de Go de unas 16.000 líneas en 14 horas y por 251 dólares; Epoch AI estimó el trabajo humano equivalente entre dos y 17 semanas. Las cifras impresionan, pero una herramienta limitada y una suite gráfica madura pertenecen a categorías muy distintas.
Un sistema de la clase de Photoshop exige recrear mucho más que funciones. Hay que reconstruir arquitectura, comportamiento de la interfaz, gestión de recursos, rendimiento e innumerables casos límite no documentados. Por eso ProjDevBench y Vibe Code Bench evalúan la entrega de proyectos completos, no solo la resolución de tareas aisladas. Aun así, no prueban que un sistema autónomo pueda construir un sustituto íntegro de un producto maduro.
Clean-room tampoco es una fórmula mágica. El desarrollo debe basarse en una especificación independiente, no en el código original, y mantener una separación demostrable. Si el modelo ha visto una implementación protegida o la petición le exige replicar decisiones distintivas, la sala jurídicamente limpia se convierte enseguida en una sala con huellas dactilares.
El valor se desplaza del código al conocimiento del producto
La ingeniería no desaparece, pero sus capas más baratas se comprimen. La IA acelera la estructura del proyecto, el código repetitivo, las pruebas, la refactorización y las correcciones iterativas. Lo costoso pasa a ser una especificación exacta del comportamiento, validar compatibilidad, ajustar rendimiento y decidir qué similitudes son necesarias técnicamente y cuáles generan riesgo legal.
Para el código abierto, el cambio es real: un equipo pequeño puede validar antes una alternativa de nicho y llegar más rápido a un prototipo funcional. Para los propietarios de software maduro, la defensa deja de depender del volumen de código escrito y se apoya más en la calidad del producto, el ecosistema y los detalles de comportamiento acumulados. Sin embargo, un prototipo todavía no equivale a una herramienta fiable para el trabajo diario.
El código se está convirtiendo en la parte barata de una copia. Siguen siendo costosas dos cosas: una especificación precisa del comportamiento y una frontera demostrable entre compatibilidad y apropiación.