La primera semana de febrero llegó con varios lanzamientos encima de la mesa al mismo tiempo: un nuevo cliente para un agente de coding popular, novedades de herramientas, actualizaciones de modelos, y el tipo de ruido que en otro año hubiera sido la noticia del trimestre pero que hoy dura un martes. Le estaba compartiendo el listado a alguien del equipo cuando me preguntó: “¿cuál arrancamos a evaluar primero?”. Y me di cuenta de que la pregunta que yo tenía en la cabeza era otra: ¿cuál no evaluamos todavía?
Hay algo en la forma en que construimos nuestra relación con la tecnología —y, sobre todo, en la forma en que lideramos equipos técnicos— que convierte a decir que no en un acto casi contracultural. La industria glorifica al que se mantiene al día, al que ya probó lo que nadie probó, al que lleva el pulso de todo lo que sale. Quedarse atrás se siente como un riesgo profesional. Decir “eso no lo evaluamos todavía” se siente, en el mejor caso, como una confesión de que no alcanzamos a llegar a todo; en el peor, como un acto de negligencia.
Pero llevo suficiente tiempo en esto como para ver el patrón que ese impulso deja cuando no se controla. Equipos que saltaron de herramienta en herramienta sin dominar ninguna. Bases de código que tienen tres formas distintas de hacer lo mismo, porque cada vez que llegó una forma nueva nadie tomó la decisión de descartar la anterior. Developers agotados no por el trabajo en sí, sino por la presión de mantenerse al día con una corriente que corre más rápido de lo que se puede nadar. Y, en los casos más serios, proyectos que fracasaron no porque eligieron mal la herramienta, sino porque eligieron demasiadas y ninguna bien.
La semana que lo puso en evidencia#
En los primeros días de este mes, quienes trabajamos cerca del desarrollo de software recibimos varias novedades casi en simultáneo. Un nuevo cliente para uno de los agentes de coding más usados, con novedades de integración que ponían sobre la mesa preguntas reales sobre cómo incorporarlo al flujo de trabajo. Actualizaciones de modelos. Movimientos en el ecosistema de modelos locales que cambian las opciones para quien quiere correr IA sin depender de una nube. Todo en cuestión de días.
La reacción natural —y entendible— en un equipo es saltar a evaluar. Porque lo que no evaluamos, en algún sentido, ya nos pasó por arriba. Eso no es paranoia: es la realidad de un campo donde la ventana entre “novedad” y “práctica estándar” se cerró a meses lo que antes llevaba años. El que espera demasiado llega tarde. El que no espera nada se ahoga.
Pero hay un problema en ese reflejo, y tardé bastante en nombrarlo con claridad: cuando todo tiene la misma urgencia, nada tiene urgencia real. La presión de evaluar todo a la vez es, en la práctica, una forma de no elegir. Y no elegir, en tecnología, tiene un costo que no aparece en ningún dashboard pero que se paga igual.
Hay un nombre para ese costo que se está empezando a usar y que me parece muy preciso: deuda cognitiva. Margaret-Anne Storey, investigadora de la Universidad de Victoria, lo describió este mes en un artículo que dio bastante que hablar. La diferencia con la deuda técnica clásica, dice Storey, es que la deuda cognitiva no vive en el código: vive en las personas. Es la degradación de la comprensión compartida de un sistema, el momento en que el equipo ya no puede explicar por qué las cosas están como están, y en que cada cambio nuevo se vuelve más difícil porque nadie conserva el modelo mental de lo que se construyó. No es el sistema el que se rompió: es el entendimiento colectivo del sistema.
Lo que me interesa de esa idea es que la acumulación de herramientas sin criterio es una de sus principales fuentes. Cuando sumamos cosas sin descartar otras, el inventario crece pero la comprensión no. El equipo sabe usar tres herramientas a medias en lugar de conocer una bien. Y eso no se resuelve con documentación ni con sprints de limpieza: se resuelve con la disciplina de no acumular lo que no se va a poder sostener.
Qué significa, en concreto, decir que no#
Quiero ser preciso aquí, porque “decir que no” es una de esas expresiones que suenan fáciles hasta que intentamos aplicarlas. No estoy hablando de ignorar lo relevante ni de construir un equipo que mira para adentro y pierde el contacto con el campo. Eso sería tan malo como el problema opuesto. Estoy hablando de algo más específico: la habilidad de distinguir, en el momento en que algo llega, entre lo que merece atención ahora, lo que merece estar en el radar para después, y lo que simplemente no merece entrar. Y de tomar esa decisión con criterio deliberado, no por inercia ni por miedo.
En términos concretos, toma tres formas que se solapan pero que conviene separar.
La primera es decir que no a las herramientas. No toda herramienta nueva que aparece en el radar del equipo merece una evaluación inmediata. La pregunta que conviene hacerse no es “¿esto es interesante?” —casi todo lo que circula en el campo lo es— sino “¿el problema que resuelve esta herramienta es el problema que tenemos nosotros, hoy?”. Si la respuesta es no, la herramienta puede quedar anotada para después. No ignorada: anotada. La diferencia importa. Ignorarla es perder el mapa; anotarla para cuando el contexto cambie es mantenerlo sin que nos consuma.
La segunda es decir que no a los proyectos. Esta es la más difícil porque implica conversaciones incómodas, y a veces implica decepcionar a alguien. Pero el mayor valor de quien lidera tecnología no siempre está en lo que habilita, sino en lo que protege al equipo de intentar. Un líder que acepta todo lo que llega porque “es difícil decirle que no al negocio” o porque “no quiero que piensen que el equipo no puede” está sacrificando el foco de largo plazo por la comodidad de corto plazo. El equipo que no tiene capacidad de rechazar trabajo no tiene verdadera capacidad de hacer bien el que acepta.
La tercera es decir que no para uno mismo, que quizás sea la más contracultural de las tres. En un campo donde el valor percibido está ligado a la amplitud —cuántos modelos conoce cada uno, cuántas herramientas probó, cuántos lenguajes maneja— elegir deliberadamente no seguir algo tiene un costo de imagen que es real aunque sea injusto. Pero lo contrario tiene un costo más alto: el de la atención dispersa, el de saber un poco de todo y mucho de nada, el de estar siempre al día con lo nuevo y nunca con nada lo suficiente como para hacerlo bien.
El costo que no contabilizamos#
Hay una forma de desgaste en los equipos técnicos que es difícil de medir y fácil de ignorar hasta que ya es tarde. Es la acumulación de cosas que el equipo empezó a evaluar, adoptó parcialmente, dejó a medias, o simplemente cargó en el radar sin procesar. Cada herramienta nueva que se suma sin que ninguna salga. Cada framework que se agregó cuando el anterior todavía existía. Cada proceso que se lanzó encima del anterior porque el anterior dejó de funcionar pero nadie tomó la decisión formal de cerrarlo.
Esa deuda de atención es prima hermana de la deuda técnica, y como ella, no aparece en los reportes hasta que se manifiesta en los síntomas: contexto que diverge en las reuniones porque distintos miembros del equipo siguieron cosas distintas, decisiones que se demoran porque nadie sabe bien cuál es el estado actual de algo, developers que salen agotados de una semana normal y no saben bien explicar por qué.
Lo que la explosión de herramientas de las últimas semanas vuelve a poner en evidencia es un patrón que viene de antes pero que se aceleró. Nunca fue tan fácil agregar algo al radar del equipo. Y nunca fue tan difícil sacar. La asimetría entre el costo de incorporar algo nuevo —bajo, casi cero en el momento— y el costo de mantenerlo en el tiempo —acumulativo, invisible, pero real— es uno de los problemas más subestimados de cómo gestionamos la tecnología colectivamente.
La objeción honesta#
Antes de seguir, quiero nombrar el riesgo del argumento contrario, porque existe y es legítimo. Hay una versión de “decir que no” que no es sabiduría táctica sino miedo disfrazado de criterio. Un equipo que rechaza evaluar todo lo nuevo porque “ya tenemos lo que necesitamos” o porque “esto también va a pasar” puede quedarse atrás no por elección deliberada sino por inercia conservadora. Y en un campo donde la brecha entre quien adoptó algo a tiempo y quien no puede medirse en meses, ese riesgo es real.
La diferencia entre el no que construye y el no que protege en falso está en una sola cosa: la claridad del criterio que lo sostiene. Un equipo que dice “no evaluamos esto ahora porque estamos priorizando X, y cuando terminemos X lo revisamos” está tomando una decisión activa. Un equipo que dice “no evaluamos esto porque no nos parece” —o peor, porque nadie tiene tiempo de discutirlo— está siendo pasivo aunque suene a decisión.
Decir que no sin criterio es tan malo como decir que sí a todo. La habilidad no está en el no: está en el porqué que lo sostiene.
Cómo se desarrolla este músculo#
Si tuviera que nombrar tres cosas concretas que marcan la diferencia en los equipos que hacen bien esto, serían estas.
Primero, separar el radar del backlog del ahora. Tener un lugar explícito donde las cosas nuevas van cuando llegan —sin evaluarlas de inmediato— y un proceso periódico, mensual o bimestral, para decidir qué pasa del radar al trabajo real. Esto saca la presión de evaluar en caliente y permite tomar distancia antes de comprometerse.
Segundo, el principio de que para que algo entre, algo tiene que salir. No como regla burocrática, sino como disciplina de foco: si el equipo ya tiene tres formas de hacer X y llega una nueva que también hace X, la pregunta es cuál de las tres reemplaza, no si se suma como cuarta. Sin ese principio, el inventario de herramientas no tiene límite natural.
Tercero, hacer explícito el criterio de evaluación. No “¿es buena esta herramienta?” sino “¿resuelve el problema que tenemos, en el contexto en que estamos, con los recursos disponibles?”. La diferencia es entre una evaluación abstracta y una evaluación situada. Y solo las evaluaciones situadas terminan en decisiones reales.
El criterio que separa a los equipos que hacen buen uso de las herramientas disponibles de los que se ahogan en ellas no suele ser técnico: es editorial. Tienen desarrollado un músculo para seleccionar qué entra y qué no, para darse permiso de dejar pasar lo que no les corresponde todavía, y para no confundir el radar con la lista de trabajo. Ese músculo no se desarrolla automáticamente con la experiencia; se desarrolla con práctica deliberada, como cualquier otro.
Lo que me queda claro, después de esta semana, es que la velocidad del campo no va a bajar. Lo que puede crecer es nuestra capacidad de navegar esa velocidad sin dejar que nos arrastre. El no que se dice con criterio no es una derrota: es uno de los pocos actos de liderazgo que se puede tomar en silencio, sin reunión ni aprobación, y que de todas formas cambia el rumbo del equipo.
¿En sus equipos tienen un lugar explícito donde van las cosas nuevas antes de ser evaluadas, o todo llega directo a la pila de lo urgente? ¿Y cuándo fue la última vez que sacaron algo del inventario de herramientas, no porque dejó de funcionar, sino porque decidieron que ya no valía la pena mantener?
Fuentes consultadas#
- OpenAI, “Introducing the Codex app”, 2 de febrero de 2026. También cubierto por Reuters y CNBC.
- Simon Willison, “Tom Dale on AI and developer wellbeing”, 6 de febrero de 2026. Con referencia al tweet original de Tom Dale.
- Margaret-Anne Storey, “How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt”, Universidad de Victoria, 9 de febrero de 2026.
- Martin Fowler, fragmento sobre deuda cognitiva, martinfowler.com, 13 de febrero de 2026.