Contexto técnico
Este análisis me llamó la atención no por otra batalla de modelos, sino por la economía. Un equipo ejecutó varias metodologías SDD en un proyecto simple de cinco endpoints usando Claude Code y llegó a una conclusión muy madura: la calidad del resultado es prácticamente la misma, pero el coste puede variar hasta cinco veces. Para la automatización con IA, esta es casi la señal más importante del año.
Me gusta especialmente el cambio de enfoque. No se trata de «qué modelo es más inteligente en un benchmark», sino de «cuál es el modelo o agente más barato que puede implementar la especificación sin errores». Esa es una pregunta de ingeniería, no un fetiche por los modelos SOTA.
La discusión muestra que no probaron ideas abstractas, sino modos de trabajo muy prácticos: habilidades personalizadas para especificación, planificación, implementación en una sola fase y revisión con retroalimentación (pushback). El ejecutor por defecto usa Claude reasoning medium más Opus. Planean ejecutar los mismos escenarios en Codex Max, lo cual es el siguiente paso lógico.
La conclusión más contundente la formularía así: si ya necesitas un spec-kit, un claude-plan y un montón de parches complejos para que una tarea funcione, el problema no es el modelo. El problema es que el sistema es demasiado grande, está mal descompuesto o la especificación está escrita de tal manera que es difícil de ejecutar incluso para un buen agente.
Y aquí asiento con la cabeza, porque en las soluciones de IA reales para empresas veo lo mismo. Cuando una especificación es limpia, limitada y verificable, incluso un modelo más débil a menudo llega al resultado sin dramas. Cuando la especificación es ambigua, un agente caro simplemente comete errores más caros.
Qué cambia esto para los negocios y la automatización
Para las empresas, la conclusión es casi indecentemente práctica. Ahora tiene sentido gastar el presupuesto de implementación de inteligencia artificial no solo en modelos, sino en la disciplina de las especificaciones, las interfaces, los criterios de aceptación y una descomposición adecuada. Es más aburrido que comprar el nuevo Opus, pero la rentabilidad es mayor.
Ganan los equipos que saben describir un sistema como un conjunto de contratos pequeños y verificables. Pierden los que intentan solucionar el caos arquitectónico con una inferencia más costosa.
Añadiría otra capa importante. Si la calidad realmente se está nivelando entre metodologías, el mercado se desplaza gradualmente de «quién tiene el modelo más potente» a «quién ha construido un proceso que permite delegar cualquier tarea a un ejecutor más barato». Esto ya no es solo desarrollo, es la integración de la IA como sistema operativo de la empresa.
De ahí el interés en la idea de la «máquina de Gödel-Darwin» para escalar hipótesis dentro de una organización. Suena grandilocuente, pero la esencia es práctica: ejecutas variaciones de especificaciones, agentes y pipelines como hipótesis evolutivas, y luego analizas las métricas de tiempo, coste y calidad. No discutes sobre gustos, seleccionas lo que sobrevive.
No lo tomaría como una verdad universal, porque el caso de estudio es pequeño: cinco endpoints no son un monolito, ni un ERP heredado, ni un backend empresarial desordenado. Pero como señal de dirección, es potente. Si en un proyecto simple el precio varía 5 veces sin una diferencia notable en la calidad, en un flujo de tareas el efecto económico puede ser enorme.
En Nahornyi AI Lab, precisamente analizamos estos cuellos de botella con nuestros clientes. No «qué modelo comprar», sino dónde se rompe la descomposición, cómo reescribir las especificaciones para una ejecución fiable y dónde la construcción de AI automation realmente generará ahorros, no solo una demo vistosa. Si sientes que tu equipo ya está pagando de más por el caos en los procesos, podemos sentarnos y desglosarlo en una arquitectura de IA funcional, sin magia ni tokens de más.