Contexto técnico
No estoy aquí para hablar de un gran lanzamiento, sino de una noticia mucho más útil: en el trabajo real con Opus 4.7 y Codex, vuelve a surgir un viejo problema. A nivel de planificación, suenan razonables, pero en cuanto empiezo a leer el diff línea por línea, la integración de la IA en el desarrollo deja de parecer segura.
Los detalles son desagradables. En un caso, un modelo en un proyecto con modelos de dominio simplemente omitió la capa de dominio, creó un nuevo repositorio y comenzó a operar con sus propias reglas. En otro, pedí que añadiera una capa de dominio y recibí una carpeta con una interfaz de repositorio y un extraño value object con un array, pero sin una entity. Formalmente, se hizo algo. Arquitectónicamente, es basura.
Y aquí está el punto importante: no tengo confirmación de fuentes externas de que Opus 4.7 o Codex fallen sistemáticamente en DDD como tipo de tarea. Hay muchas quejas sobre el ruido, el seguimiento literal de instrucciones, acciones autónomas cuestionables y una falta de fiabilidad general en el código, pero no sobre este patrón específico con las capas de dominio. Por lo tanto, honestamente lo llamaría no una propiedad demostrada del modelo, sino un riesgo práctico recurrente que yo ya incluiría en el proceso.
Lo que más me molesta no es el error en sí, sino su estilo. El modelo no dice: «No entendí la arquitectura». Con confianza, construye una estructura conveniente para sí mismo, como si la capa de dominio, los invariantes y los límites de los agregados fueran una parte decorativa del proyecto.
Si el plan carece de restricciones sólidas, improvisará. Si hay restricciones, aún puede desviarse silenciosamente hacia un camino más simple. Por eso hace tiempo que dejé de considerar los planes y comentarios bien redactados como una señal de calidad.
Impacto en el negocio y la automatización
Para un equipo, esto significa algo simple: la automatización con IA en el código no puede aplicarse en áreas arquitectónicamente sensibles sin barreras de protección. CRUD, pruebas, migraciones, refactorización rutinaria, sí. Lógica de dominio, contratos, invariantes, no sin control manual.
Ganan aquellos que tienen listas de verificación arquitectónicas, reglas para el agente y revisiones por capas. Pierden los equipos que miden la calidad por la velocidad de generación y el número de tareas cerradas.
Yo ya lo veo como un problema de arquitectura de IA, no solo como la elección de un modelo. Se necesitan guardrails en los prompts, linters para violaciones arquitectónicas, plantillas de directorios, pruebas para los límites de las capas y una revisión de diff obligatoria por un humano. En Nahornyi AI Lab, precisamente construimos este tipo de soluciones para clientes que necesitan crear automatización con IA sin sorpresas en producción.
Si un agente parece haber acelerado el desarrollo, pero el código comienza a desorganizarse entre las capas, es mejor detenerse ahora que pagar por una reescritura más tarde. En Nahornyi AI Lab, podemos analizar juntos su flujo de trabajo y construir un desarrollo de soluciones de IA para que la automatización ahorre tiempo en lugar de destruir el sistema desde adentro.