Hay tres reglas operativas que separan a los equipos que escalan con IA de los equipos que solo aceleran su propio caos. Las tres son tan limpias que se pueden escribir en una servilleta. Y casi nadie las aplica. Las articulamos como claims canónicos en onext porque son la base del método con el que rediseñamos equipos de desarrollo — pero su valor no depende del método. Son verdaderas por sí solas, y cualquier Tech Lead que las interiorice la semana que viene cambia cómo construye software con IA.
Tres claims. Tres antídotos.
Los tres claims son estos:
Ninguno es complicado. Ninguno es nuevo en absoluto si llevas años trabajando en ingeniería seria. Lo que sí es nuevo es lo fácil que es violarlos cuando un equipo entero empieza a usar Copilot, Cursor o Windsurf simultáneamente sin método. La velocidad de adopción de la herramienta supera a la velocidad de adopción de la disciplina, y aparece la paradoja que el estudio de METR documentó el año pasado: developers que reportan +20% de productividad subjetiva mientras son −19% menos productivos medidos en commits, ciclo de PR y defectos en producción.
La paradoja no es defecto de la tecnología. Es ausencia de los tres claims. Y de los tres antídotos que los acompañan.
Claim 1: el modelo no es la fuente de verdad
El modelo — Claude, GPT-5, Gemini, el que sea — no recuerda. No mantiene estado entre conversaciones. No es auditable a posteriori. Y, sobre todo, no codifica las reglas reales del proyecto: la guía de estilo, las dependencias deprecadas, las decisiones arquitectónicas que el equipo tomó hace dos meses por razones que el chat actual ignora. Cuando un developer pregunta al modelo «¿cómo hago X en este repo?» y acepta la respuesta sin contrastar, está confiando en la memoria probabilística del modelo como si fuera la documentación oficial del proyecto. No lo es. Y cada vez que se confunden, hay deuda técnica latente firmada por un agente que mañana no podrá explicar por qué firmó.
Antídoto operativo: el equipo necesita una capa externa de contexto persistente que el agente consulte cada vez. No «el agente recuerda» — «el agente lee». Específicamente, hace falta un conjunto de documentos versionados que viven en el repo (o en un servicio de contexto) y que codifican las decisiones reales: la guía de estilo, las reglas de naming, las dependencias permitidas y prohibidas, los antipatrones detectados, los acuerdos de arquitectura. En nuestro trabajo llamamos a esto la constitución del proyecto — un fichero o conjunto de ficheros explícitos que el agente recibe como parte de cada prompt operativo, y que mantienen al modelo dentro del marco del proyecto en lugar de en el marco de «qué dice la web sobre esto en general».
Lo importante de la constitución no es su sofisticación. Es que exista y se actualice. Un equipo que arranca con diez reglas escritas en markdown y las refina cada sprint pasa de «el modelo decide cada vez» a «el modelo aplica nuestras decisiones». El cambio mental es enorme y se produce en semanas, no en años.
Claim 2: el chat no es el sistema
La segunda violación es la más común y la más invisible. El developer abre una conversación en Claude o Cursor, hace 40 mensajes hasta llegar a un commit que funciona, y cierra la pestaña. Tres semanas después necesita modificar lo que hizo, no recuerda por qué tomó cada decisión, abre otra conversación de cero y vuelve a iterar 40 mensajes para llegar a una variante distinta del mismo problema. La historia del razonamiento se ha perdido. El conocimiento ha vivido solo en el chat, que es efímero.
Cuando esto le pasa a un developer una vez, es anécdota. Cuando le pasa a un equipo de cincuenta developers todas las semanas, es la razón por la que la organización siente que tiene IA pero no acumula ventaja. El chat ha capturado la salida — el código — pero ha tirado la entrada, las restricciones, el contexto, el razonamiento. Y sin entrada no hay sistema, hay improvisación repetida.
Antídoto operativo: codificar workflows con quality gates automatizados que viven fuera del chat. La idea es trivial: en lugar de que cada conversación con el modelo sea ad hoc, hay un puñado de flujos definidos — idea-a-feature, quick-improvement, spike, audit — que el equipo ejecuta de forma consistente. Cada flujo tiene fases, cada fase tiene un objetivo y un quality gate que comprueba si la salida cumple criterios objetivos antes de pasar a la siguiente. El gate puede ser un linter, una validación de spec, un test, una checklist humana — pero existe, es automático y es el mismo para todos.
El equipo que codifica cuatro o cinco workflows con sus gates respectivos pasa de «cada developer tiene su propio diálogo con la IA» a «el equipo tiene un sistema operativo común con IA dentro». No es opcional para escalar más allá de diez personas trabajando en paralelo: con menos disciplina, los conflictos de criterio se multiplican exponencialmente. Con disciplina, la curva se aplana.
Claim 3: el código no es el único artefacto
La tercera violación es la que más cuesta corregir porque va contra una intuición que el desarrollo profesional lleva treinta años cultivando: «el código es la verdad; los documentos van a quedarse desactualizados de todas formas; mejor ahorrarse el papeleo y centrarse en lo que importa, que es lo que se compila». Es defendible en un mundo sin IA. En un mundo con IA es deuda en cámara lenta.
El motivo es que, cuando un agente colabora en el código, necesita entender qué se supone que el código debe hacer — no qué hace de hecho. La diferencia entre «qué debe hacer» y «qué hace» es donde viven los bugs. Si el único artefacto del equipo es el código, el agente solo puede inferir la intención retroactivamente, y va a equivocarse en los casos límite que no aparecen en los tests pero sí en el espíritu de las specs. Si el equipo mantiene specs, acceptance criteria, reglas de negocio y decisiones de diseño como ciudadanos de primera — versionados junto al código — el agente puede contrastar, y los humanos que revisan también.
Antídoto operativo: Spec-Driven Development. Las specs son la fuente; el código se deriva. El flujo cambia: antes de tocar código se actualiza la spec, después se valida que el código cumple la spec, después se mergea. Implementado bien, esto significa validación pre-commit contra spec (estructura, naming, dependencias, cobertura) y un hook de bloqueo de merge si el código no cumple. No es ciencia ficción — son herramientas que existen hace años. La novedad es la disciplina de usarlas como check obligatorio, no como adorno.
Hay un beneficio secundario importante: las specs bien mantenidas se vuelven el material que el agente usa para generar tests, documentación, ejemplos para onboarding de developers nuevos. El esfuerzo de escribir spec se amortiza tres veces.
Lo que separa «instalar Copilot» de «industrializar IA en tu equipo»
Tres claims. Tres antídotos. Capa externa de contexto. Workflows con gates. Spec-driven. Ninguno es complicado. Y, sin embargo, los equipos que los aplican son una minoría — incluso entre quienes pagan licencias premium de Cursor o Copilot para toda la plantilla.
La diferencia no es de herramientas. Es de disciplinas. Y las disciplinas se instalan en semanas si hay método; no se instalan nunca si no lo hay. Esa es la frontera real entre los equipos que escalan con IA y los que solo aceleran su propio caos.
En onext llamamos a esto industrializar el desarrollo con IA, y es el núcleo del programa de transformación que ofrecemos a equipos de desarrollo. Pero el valor de los tres claims no depende del programa: cualquier Tech Lead puede instalarlos por su cuenta si tiene autoridad, criterio y paciencia para que las primeras semanas duelan un poco. Los equipos que lo hacen por su cuenta llegan al mismo destino que los que contratan ayuda; tardan más y rompen más cristales en el camino. Es una decisión legítima.
La cita honesta que cierra la conversación
«Los agentes aún no son suficientemente fiables para ingeniería compleja.»
— Andrej Karpathy
Quien dice eso no es un escéptico anti-IA. Es uno de los ingenieros de IA más respetados del mundo. La conclusión operativa no es «no uses IA». Es: úsala con método. Los agentes no son fiables solos; con los tres claims interiorizados y los tres antídotos en producción, son herramientas notables. Sin ellos, son ilusión de progreso.
Si quieres llevarte algo accionable de esta lectura, hemos preparado cinco preguntas para auditar tu equipo dev con IA el lunes que viene. Una página A4, sin email obligatorio, descargable directa:
→ Descarga la auditoría de 5 preguntas
Si las cinco respuestas te dejan satisfecho, tu equipo está mejor que el 80% del mercado. Si te dejan incómodo, hablemos: info@onext.es — asunto «auditoría dev IA». Conversación de 30 minutos sin compromiso.
Fuentes: estudio METR 2024 sobre productividad de developers con herramientas IA (paradoja +20%/−19%); declaraciones públicas de Andrej Karpathy sobre fiabilidad de agentes en ingeniería compleja.
Lectura complementaria: Spec-Driven Development: la metodología · Context Engineering: la disciplina · MVP vs Especificación: el sesgo del Quick Ship