El peligro del agilismo defensivo frente a la escala de la IA

Escudarse en que algo no entra en el ticket, archivar los marrones en un cajón de deuda técnica o aplazar lo incómodo para el siguiente trimestre: cualquiera que haya trabajado en equipo lo tiene visto de sobra. Sabes que un componente está roto por dentro, pero nadie quiere meterle mano por no frenar la entrega o por miedo a romper algo colateral. La planificación tiene sentido, pero se pervierte cuando sirve de excusa para esquivar lo evidente:

• Componentes de mil líneas que nadie se atreve a abrir por si algo explota.
• Estados globales imposibles de seguir donde nadie sabe de dónde viene cada cambio.
• Re-renders y efectos raros que se tapan metiendo otro useEffect para salir del paso.

Ahí reside el “agilismo defensivo”. Preferimos refugiarnos en una migración masiva de un año entero antes que abrir un componente roto y ponerle orden hoy. Planificar reescrituras eternas da una sensación estupenda de progreso ordenado en los tickets sin que nadie se queme las manos, mientras que arreglar el desorden real en producción da pánico porque expone fallos de verdad. Aplazar lo importante con la promesa de que la gran migración lo curará todo convierte la base de código en un castillo de naipes que será imposible de salvar cuando empiece a tambalearse.

Tres reuniones para mover un componente de sitio

Con la excusa del consenso, muchos equipos han conseguido que extraer un componente reutilizable o unificar dos botones requiera dos hilos en Slack, tres llamadas y la bendición de medio departamento.

A eso se le llama agilidad, pero en realidad es una “póliza colectiva”. Si decidimos entre ocho qué props ponerle a un botón, nadie se come el marrón si luego algo falla en el despliegue.

Y luego están las discusiones interminables en las pull requests. Pasarse media tarde debatiendo el orden de las propiedades de estilo o cómo desestructurar las props es perder el tiempo. Si una regla importa, se programa en el linter o en el pipeline de CI, y que la máquina proteste en trescientos milisegundos sin necesidad de asambleas.

Cuando la IA pica código, lo que cuenta es el criterio

Este modelo de trabajo ya crujía antes, pero frente a la escala de la IA directamente no se sostiene.

Hoy cualquier agente te genera un componente de interfaz, un hook o una pantalla completa en lo que tardas en pestañear. Si el trabajo de alguien consistía solo en traducir requisitos mascados a sintaxis y mover tareas en el tablero, tiene un problema: picar código sin pensar ya no tiene ningún misterio.

Ningún agente te va a frenar cuando metas el cuarto estado derivado en un contexto que re-renderiza media pantalla a cada tecla, ni le va a temblar el pulso por encadenar tres useEffect hasta convertir el formulario en un festival de tirones. La IA produce a una velocidad brutal exactamente la sintaxis que le pides, pero anticipar qué código envejece con dignidad y cuál es una trampa técnica a tres meses vista sigue dependiendo del criterio humano.

La velocidad de los modelos no sirve de nada sin arneses técnicos. Hay que blindar el código con tests para que el agente no tenga escapatoria y resuelva la tarea bien a la primera.

1. 01

   Las normas, a las herramientas

   Lo que pueda validar un linter o el CI en un segundo no se discute en reuniones.
2. 02

   Hacerse cargo de la jugada completa

   Menos traspasos entre departamentos y más autonomía para diseñar, probar y desplegar.
3. 03

   Cuidar los cimientos

   Evitar el sobrediseño no significa dejar que el código se pudra. Arreglar las cosas a tiempo ahorra semanas de parches.
4. 04

   Software en producción frente a mover tareas

   El valor real está en interfaces rápidas y fiables que no se caen, no en aparentar avance moviendo tickets.