Contexto técnico
Revisé el debate sobre Skills 2.0 y rápidamente entendí el punto central: la noticia no es que alguien haya reescrito radicalmente el sistema de skills. Según las descripciones disponibles, el enfoque se ha desplazado hacia las evaluaciones (evals) dentro del skill-creator; es decir, al mecanismo donde una habilidad no mejora por la mano de un desarrollador, sino a través de un ciclo de generación, verificación y selección.
Para mí, este es un claro indicador de la siguiente etapa. Llevo mucho tiempo diciendo a mis clientes que el prompting manual tiene un límite: un humano itera hipótesis de forma demasiado lenta, y sin una evaluación rigurosa, el sistema se degrada rápidamente en un conjunto de accidentes 'afortunados'.
En este contexto, la Darwin Gödel Machine no parece un exotismo académico, sino un modelo funcional para la futura arquitectura de IA. Analicé los detalles del enfoque: hay un agente base en un modelo fundacional congelado, un archivo de generaciones, selección probabilística de 'padres', automodificación de código o prompts, y una validación empírica obligatoria en benchmarks como SWE-bench y Polyglot.
El giro clave aquí es sumamente práctico. En lugar de intentar demostrar matemáticamente que un cambio es útil, el sistema lo comprueba en tareas reales. Para la ingeniería, esto es mucho más valioso porque las empresas no necesitan un agente filosóficamente impecable, sino un agente que resuelva problemas de manera estable en producción.
Impacto en los negocios y la automatización
Yo no vendería Skills 2.0 como una 'nueva opción mágica'. Lo interpretaría como una señal para el mercado: la integración de la inteligencia artificial está pasando del modo de ajuste manual a un modo de selección de soluciones gestionada.
Las empresas que ya saben construir bucles basados en evaluaciones (eval-first) ganarán. Perderán los equipos que aún creen que la automatización con IA es simplemente un buen prompt de sistema, un par de funciones y la esperanza de que el modelo 'lo entienda solo'.
En mis proyectos en Nahornyi AI Lab, las evaluaciones (evals) son casi siempre el punto donde nace el valor real. No es el modelo en sí. No es una interfaz atractiva. Es un entorno correctamente construido: escenarios de prueba, métricas de calidad, un entorno aislado (sandbox), registro de auditoría, capacidad de reversión (rollback) y un criterio claro de que el agente realmente ha mejorado.
Esto también cambia la forma de presupuestar. Si antes el cliente pagaba principalmente por el desarrollo de la solución de IA como un conjunto de integraciones y lógica empresarial, ahora es cada vez más necesario destinar fondos a la infraestructura de selección: entornos de prueba, conjuntos de datos de control, orquestación de ejecuciones, almacenamiento de versiones de agentes y políticas de seguridad.
Precisamente por eso, hacer automatización de IA 'sobre la marcha' se está volviendo peligroso. Cuantos más permisos obtiene un agente para cambiar su propio comportamiento, mayor es el precio de una mala arquitectura. Sin una integración de IA profesional, una empresa podría terminar con un sistema que se autodestruye en lugar de uno que se automejora.
Visión estratégica y análisis profundo
Aquí veo un cambio más profundo que simplemente automatizar la ingeniería de prompts. La siguiente etapa del desarrollo de software implica diseñar entornos donde el código, los agentes, las herramientas y los prompts evolucionen bajo el control de los LLM, pero dentro de un marco de ingeniería estrictamente definido.
El entorno en sí mismo se convierte en el producto principal de la arquitectura. No un solo agente, no un solo flujo de trabajo, sino un sistema donde se pueden generar variaciones de forma segura, probarlas frente a métricas de negocio y guardar incluso las ramas temporalmente débiles como potencialmente valiosas para futuras iteraciones.
Ya veo un análogo de este patrón en casos corporativos: primero, un equipo pide un 'asistente de soporte' o un 'agente de ventas', y un mes después resulta que el cuello de botella no está en el modelo. El cuello de botella es la falta de infraestructura de medición, donde se pueda entender rápidamente qué variación de comportamiento aumenta realmente la conversión, reduce el incumplimiento de los SLA o disminuye el coste de gestionar un caso.
Por lo tanto, mi pronóstico es simple. En los próximos 12 a 24 meses, el mercado se dividirá entre los que pedirán otra serie de prompts y los que comenzarán a construir arquitecturas de soluciones de IA como un sistema evolutivo con evals, archivos de versiones y automejora controlada. El segundo grupo no solo obtendrá una mejor calidad, sino también una economía de escalado mucho más estable.
Este análisis fue preparado por mí, Vadym Nahornyi, experto principal de Nahornyi AI Lab en arquitectura de IA, integración y automatización con IA. Si usted quiere algo más que simplemente probar la última tendencia de agentes, y prefiere construir un sistema que mejore de forma medible y funcione de forma segura en su empresa, le invito a discutir su proyecto conmigo y con el equipo de Nahornyi AI Lab.