[{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/agentes-ia/","section":"Tags","summary":"","title":"Agentes-Ia","type":"tags"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/arquitectura/","section":"Tags","summary":"","title":"Arquitectura","type":"tags"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/criterio-t%C3%A9cnico/","section":"Tags","summary":"","title":"Criterio Técnico","type":"tags"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/desarrollo-de-software/","section":"Tags","summary":"","title":"Desarrollo De Software","type":"tags"},{"content":"Hay momentos en tecnología en los que uno siente que se quedó atrás durante un fin de semana. El viernes todavía estábamos tratando de entender una idea, el lunes aparece otra etiqueta que promete superarla y, antes de que podamos probar si algo cambió de verdad, ya hay cursos, diagramas, manifiestos y perfiles profesionales alrededor del nuevo término.\nEn inteligencia artificial esa sensación se volvió casi permanente. Pasamos de hablar de prompt engineering a context engineering, después de harness engineering, más tarde de loop engineering y ahora de graph engineering. Cada nombre intenta capturar una parte real del problema, pero la velocidad con la que se reemplazan también produce una confusión bastante menos útil: parece que cada cambio de vocabulario inaugura una disciplina completa y deja obsoleto todo lo anterior.\nEl 18 de julio de 2026, Peter Steinberger publicó en X una pregunta de apenas doce palabras:\n“Are we still talking loops or did we shift to graphs yet?”\nLa frase se puede traducir como: “¿Seguimos hablando de ciclos o ya pasamos a los grafos?”. No presentó un framework, no describió un patrón nuevo y ni siquiera utilizó la expresión Graph Engineering. Sin embargo, alcanzó para empujar una conversación enorme. En pocos días aparecieron explicaciones, comparaciones y declaraciones sobre una nueva etapa de la ingeniería de agentes.\nNo me interesa discutir si el término es válido o si debería desaparecer. Esa pelea se vuelve vieja casi tan rápido como la etiqueta. Me interesa algo más cercano a nuestro trabajo: qué ocurre cuando el nombre de una práctica cambia más rápido que nuestra capacidad de entenderla, y cuánto cuesta tomar decisiones técnicas desde esa sensación de urgencia.\nPorque detrás del ruido hay dos verdades que pueden convivir. Diseñar flujos con estado, bifurcaciones, ciclos y varios agentes no nació en julio de 2026. Pero los agentes actuales sí están volviendo más visible, más frecuente y también más difícil ese tipo de arquitectura. Si reducimos todo a “es puro humo”, podemos ignorar un problema real. Si aceptamos cada nombre como una revolución, podemos terminar reconstruyendo lo que ya sabíamos, solo que con menos memoria y más ansiedad.\nDoce palabras y una disciplina nueva # La velocidad de esta historia es parte del tema. Steinberger hizo una pregunta breve y ambigua. Se podía leer como una observación técnica, pero también como una broma sobre la rapidez con la que la industria cambia de vocabulario. La interpretación se volvió más grande que el mensaje original.\nEso no significa que la expresión haya nacido de la nada. Hay usos anteriores y, para cuando apareció aquel post, distintas personas ya venían describiendo la evolución desde agentes que repiten un ciclo hacia sistemas compuestos por varios nodos conectados. Lo que ocurrió ese fin de semana no fue la invención de una técnica. Fue la cristalización de un nombre.\nEsta diferencia parece menor, pero es importante. Cuando una tecnología nueva obliga a desarrollar capacidades que antes no existían, tiene sentido revisar nuestras categorías. En cambio, cuando una etiqueta agrupa prácticas conocidas bajo un título atractivo, conviene separar el valor del vocabulario del valor de la arquitectura.\nLangChain lo reconoció pocos días después desde un lugar difícil de ignorar: el equipo construye LangGraph, uno de los frameworks más asociados con esta conversación. En un artículo titulado “3 Years of Graph Engineering with LangGraph”, sus autores escribieron que la idea no era nueva y la describieron como el nombre más reciente para una forma ya establecida de construir agentes confiables.\nEse reconocimiento no invalida el término. Le devuelve proporción.\nLas palabras son necesarias. Nos permiten señalar un conjunto de problemas sin explicarlos desde cero en cada conversación. Cuando alguien habla de un patrón Observer, una cola de mensajes o una máquina de estados, no está fingiendo haber inventado esos mecanismos; está usando un vocabulario compartido para pensar y trabajar con otros. El problema empieza cuando el nombre deja de ser un atajo para conversar y se convierte en la prueba de que estamos frente a una ruptura.\nEntonces ya no preguntamos qué cambió en el sistema. Preguntamos si nuestro equipo “hace Graph Engineering”, si deberíamos contratar un “Graph Engineer” o si la arquitectura actual quedó vieja. La discusión se mueve desde el problema hacia la identidad, y ese desplazamiento tiene consecuencias.\nLo que ya sabíamos antes de los agentes # Si le quitamos el nombre de moda, el dibujo resulta bastante conocido. Tenemos una serie de pasos que reciben información, realizan una tarea, modifican un estado y deciden qué debe ocurrir después. Algunos pasos pueden ejecutarse en paralelo; otros dependen de un resultado anterior. Puede haber condiciones, reintentos, caminos alternativos, pausas, intervención humana y una forma explícita de terminar.\nLa documentación actual de LangGraph lo explica con una sencillez que ayuda: los nodos hacen el trabajo y las aristas indican qué sucede después. El estado atraviesa ese recorrido y permite que el sistema conserve la información necesaria para continuar. Un nodo puede contener un modelo, un agente completo o código tradicional. La forma de grafo no obliga a que todo sea inteligente ni autónomo.\nNada de eso debería resultarnos extraño. En diciembre de 2016, casi una década antes de esta discusión, AWS presentó Step Functions como una forma de coordinar aplicaciones distribuidas mediante flujos visuales y máquinas de estados. Los estados podían ejecutarse de manera secuencial o paralela, tomar decisiones, manejar errores y definir transiciones. Azure Logic Apps, Google Cloud Workflows y muchas herramientas de automatización resolvieron variantes del mismo problema.\nTampoco es una novedad exclusiva de la nube. Quienes trabajamos con procesos de negocio, motores de workflows, pipelines de datos, sagas, orquestadores o interfaces con estados complejos venimos utilizando ideas parecidas desde hace años. Cambian las herramientas, las restricciones y el nivel de abstracción, pero persisten las preguntas: dónde vive el estado, quién decide la próxima transición, qué ocurre cuando un paso falla, cómo reanudamos el proceso y cómo entendemos lo que pasó después.\nPor eso decir que pasamos “de ciclos a grafos” puede ser útil como explicación inicial, pero también puede confundir. Un ciclo ya puede formar parte de un grafo. De hecho, un agente que planifica, ejecuta, verifica y vuelve a intentar hasta alcanzar una condición de salida es una estructura cíclica dentro de un flujo mayor. No estamos reemplazando una figura por otra como quien descarta una tecnología antigua. Estamos ampliando el nivel en el que diseñamos la coordinación.\nUn agente puede resolver una tarea dentro de su propio ciclo. Un sistema más complejo puede necesitar un nodo que investigue, otro que escriba, uno que revise, una validación determinista y una intervención humana cuando la confianza sea baja. Ese conjunto puede representarse como un grafo, pero el dibujo no resuelve por sí solo ninguno de los problemas difíciles. Solamente los hace visibles.\nHay algo nuevo, pero no está en la forma # Sería cómodo terminar acá y decir que todo esto son máquinas de estados con otro nombre. También sería incompleto.\nLo que está cambiando no es el concepto matemático de grafo ni la idea de orquestar pasos. Está cambiando lo que podemos colocar dentro de cada nodo. Durante años, un nodo de un workflow representaba una función, una llamada a un servicio o una tarea relativamente acotada. Hoy puede contener un agente que usa herramientas, consulta distintas fuentes, toma decisiones intermedias y trabaja durante varios minutos antes de devolver un resultado.\nEsa diferencia aumenta la capacidad del sistema, pero también introduce una incertidumbre nueva. Una función tradicional debería producir una salida razonablemente predecible para una entrada conocida. Un agente opera dentro de límites bastante más blandos: interpreta una instrucción, selecciona herramientas, administra contexto y puede recorrer caminos diferentes en dos ejecuciones parecidas.\nLangChain describe esta evolución de una manera interesante: antes los nodos podían contener código determinista o una llamada a un modelo; ahora pueden contener una ejecución completa de un agente. Desde ese punto de vista, la novedad no está en conectar cajas con flechas, sino en que cada caja puede tomar decisiones más complejas y menos previsibles.\nMicrosoft muestra algo similar en la documentación de GraphFlow para AutoGen. Su flujo dirigido permite secuencias, trabajo en paralelo, bifurcaciones condicionales y ciclos con condiciones de salida. La propia documentación recomienda usarlo cuando hace falta controlar con precisión el orden de intervención de los agentes o cuando resultados diferentes deben conducir a pasos distintos. También advierte que la funcionalidad todavía es experimental.\nEse último detalle importa. En medio del entusiasmo es fácil mirar un diagrama de varios agentes y asumir que más especialización produce automáticamente un sistema mejor. Pero cada nodo agrega llamadas, contexto, costo, latencia y una nueva superficie de error. Cada transición necesita una regla. Cada resultado intermedio puede contaminar el siguiente. Y si varios agentes trabajan en paralelo, tarde o temprano alguien tiene que combinar sus respuestas, resolver contradicciones y decidir cuál merece confianza.\nEl grafo permite representar esa complejidad. No la elimina.\nQuizás ahí esté el aporte más valioso de esta etapa: estamos empezando a discutir la arquitectura de los agentes más allá del modelo y del prompt. Hablamos de persistencia, observabilidad, recuperación, límites de autoridad, condiciones de salida, validaciones y puntos de intervención humana. Son temas viejos en ingeniería de software, pero adquieren una forma particular cuando parte del flujo puede razonar, improvisar y equivocarse con una respuesta convincente.\nNegar esa diferencia porque la estructura general ya existía sería tan pobre como declarar que todo cambió porque apareció un nombre nuevo. La práctica técnica está evolucionando. Lo que no necesitamos es fingir que evoluciona sin historia.\nEl costo de renombrar el oficio cada seis semanas # Podría parecer que esta discusión solo afecta a quienes pasan demasiado tiempo en redes sociales. Si mañana dejamos de decir Graph Engineering y aparece otra expresión, los sistemas van a seguir funcionando igual. Sin embargo, las etiquetas no se quedan en la conversación. Entran en las hojas de ruta, en los presupuestos, en las búsquedas laborales y en la forma en que los equipos evalúan su propio conocimiento.\nCuando cada patrón se presenta como una disciplina independiente, la identidad profesional empieza a pegarse a herramientas y términos cada vez más pequeños. Ya no alcanza con ser ingeniero de software y entender orquestación, sistemas distribuidos, estado, concurrencia y recuperación. Parece necesario convertirse en especialista del nombre que está circulando esa semana.\nEsto produce una sensación rara: gente con años resolviendo procesos complejos puede sentirse atrasada porque no reconoce una etiqueta, mientras alguien que aprendió la etiqueta ayer puede parecer actualizado sin haber enfrentado nunca el problema en producción. El vocabulario, que debería ayudarnos a compartir conocimiento, empieza a ocultar la experiencia que importa.\nTambién complica la contratación. Si una empresa publica que busca un “Graph Engineer”, ¿qué está pidiendo realmente? ¿Alguien que conozca LangGraph? ¿Una persona con experiencia en sistemas multiagente? ¿Un arquitecto capaz de diseñar workflows con estado? ¿Un ingeniero de datos que entienda grafos? ¿O simplemente alguien que pueda construir el producto que la empresa todavía no terminó de definir?\nUna búsqueda así puede atraer perfiles por coincidencia de palabras y dejar afuera a personas que dominan los fundamentos. Peor aún, puede hacer que la empresa crea que su problema se resuelve incorporando una especialidad, cuando todavía no sabe si necesita más de un agente.\nEn “2025: el año en que la IA se volvió plural y el criterio se volvió escaso” planteaba que, cuando las herramientas se multiplican, el diferencial deja de ser el acceso y pasa a ser el criterio para elegir. Con las etiquetas ocurre algo parecido. Cuantos más nombres aparecen, menos valor tiene conocerlos todos y más importante se vuelve entender qué problema hay debajo.\nLa deuda técnica también puede empezar por una palabra. Un equipo ve una arquitectura de referencia, siente que un solo agente quedó anticuado y divide un flujo simple entre cinco agentes especializados. Aparecen routers, memorias compartidas, subgrafos, evaluadores y capas de coordinación. La demo se vuelve más impresionante, pero ahora hay que observar cinco comportamientos probabilísticos, pagar sus ejecuciones, depurar sus conversaciones y mantener reglas de transición que antes no existían.\nSi esa complejidad permite resolver algo que el diseño anterior no podía, puede estar justificada. Si entró para demostrar que el equipo adoptó el paradigma del momento, se transforma en deuda impulsada por el miedo a quedar atrás.\nUn grafo también puede organizar mejor nuestros errores # Existe una tentación particular en los sistemas multiagente: confundir división del trabajo con calidad. Como cada agente tiene un rol claro —investigador, programador, revisor, tester— el conjunto se parece a un equipo y transmite una sensación de control. Pero poner nombres profesionales dentro de cajas no convierte automáticamente sus interacciones en un proceso confiable.\nUn agente investigador puede encontrar una fuente incorrecta. El redactor puede usarla con seguridad. El revisor puede evaluar la coherencia del texto sin comprobar el origen. El agente final puede aprobar un resultado prolijo que conserva el error inicial. El grafo habrá funcionado exactamente como fue diseñado y, aun así, habrá producido algo equivocado.\nEn este sentido, el problema se conecta con “Lo que la IA no puede diseñar”. Allí la tensión estaba entre producir y entender: un sistema puede generar mucho material correcto en apariencia sin que nadie haya construido un modelo mental suficiente para sostenerlo. Un grafo de agentes puede aumentar esa distancia. Ya no delegamos solo la producción de código o texto; también delegamos partes de la coordinación, la revisión y la decisión sobre cuándo el trabajo está terminado.\nPor eso una arquitectura de agentes no debería empezar por cuántos nodos tiene, sino por dónde necesita determinismo. ¿Qué resultado puede quedar librado al juicio de un modelo y cuál exige una regla verificable? ¿Qué acciones son reversibles? ¿Dónde debemos guardar el estado para poder reconstruir una ejecución? ¿Qué agente tiene permiso para actuar y cuál solamente puede sugerir? ¿Quién valida que una condición de salida representa éxito y no cansancio del sistema?\nEstas preguntas no aparecen en el dibujo más vistoso. Aparecen cuando intentamos operar el sistema.\nUn grafo bien diseñado puede ayudarnos justamente porque permite hacer explícitos esos límites. Puede separar la exploración probabilística de la validación determinista. Puede establecer una pausa antes de una acción sensible, guardar checkpoints, restringir herramientas por nodo y llevar un registro de las transiciones. También puede permitir que distintas tareas usen modelos diferentes según costo, capacidad o riesgo.\nPero para obtener esos beneficios necesitamos tratar el grafo como arquitectura y no como escenografía. Las flechas deben representar decisiones que podamos explicar. El estado tiene que tener dueño, forma y ciclo de vida. Los errores deben conducir a una recuperación pensada, no a un ciclo infinito de agentes intentando convencerse entre sí. Y la observabilidad tiene que permitir entender qué ocurrió sin leer una conversación interminable después del incidente.\nLa pregunta importante no es si el sistema parece una organización. Es si alguien puede hacerse cargo de él cuando la organización artificial se equivoca.\nLa objeción necesaria: los nombres también construyen conocimiento # Hasta acá podría parecer que la solución es rechazar cualquier término nuevo y volver a hablar únicamente de patrones clásicos. No creo que alcance.\nUn nombre puede ordenar una conversación dispersa. Context engineering, por ejemplo, ayudó a mover el foco desde la habilidad de escribir una instrucción ingeniosa hacia un problema más amplio: qué información recibe el modelo, cuándo la recibe, cómo se selecciona y qué se deja afuera. Muchas de esas prácticas ya existían, pero el nombre permitió verlas como parte de una misma responsabilidad.\nCon Graph Engineering puede pasar algo parecido. La expresión puede servir para agrupar el diseño de nodos, transiciones, estado compartido, bifurcaciones, paralelismo, checkpoints y controles humanos en sistemas de agentes. Para alguien que llega desde el desarrollo de aplicaciones y nunca trabajó con un motor de workflows, esa etiqueta puede abrir una puerta hacia conceptos que de otro modo quedarían escondidos detrás de terminología académica o de infraestructura.\nAdemás, los sistemas con agentes sí presentan problemas que merecen especialización. Evaluar salidas no deterministas, administrar contexto entre nodos, evitar que un error se propague y diseñar permisos para componentes autónomos no son detalles menores. Que sus fundamentos tengan historia no significa que podamos resolverlos de memoria.\nEl punto no es dejar de nombrar. Es pedirle al nombre que haga un trabajo útil.\nUna etiqueta vale cuando reduce ambigüedad, reúne problemas relacionados y permite que dos personas entiendan de qué están hablando. Pierde valor cuando se usa para inflar una novedad, reemplazar la explicación o crear una identidad profesional antes de que exista un cuerpo de conocimiento relativamente estable.\nTal vez la prueba más simple sea intentar explicar la práctica sin usar su nombre. Si podemos decir que necesitamos coordinar varios agentes, conservar estado, ejecutar algunas tareas en paralelo, decidir rutas según resultados y detener el flujo frente a una acción sensible, ya tenemos una conversación técnica. Después podemos llamar a eso Graph Engineering para abreviar. Si solo podemos defender la arquitectura repitiendo la etiqueta, probablemente todavía no entendimos qué estamos construyendo.\nUna forma más tranquila de mirar la próxima ola # Los líderes técnicos no pueden ignorar todas las tendencias hasta que maduren. Parte del trabajo consiste justamente en mirar antes, experimentar y detectar qué puede cambiar el producto o la forma de construirlo. El problema no es prestar atención. Es convertir atención en adopción antes de pasar por una pregunta concreta.\nFrente a una nueva “ingeniería”, conviene empezar por traducirla. ¿Qué problema resuelve en nuestro sistema? ¿Qué capacidad nos da que hoy no tenemos? ¿Qué complejidad agrega? ¿Podemos obtener el mismo resultado con una estructura más simple? ¿Seguiría teniendo sentido si mañana dejáramos de usar el nombre?\nNo hace falta convertir esas preguntas en un comité que bloquee cualquier experimento. Pueden ser un filtro liviano. Si queremos probar una arquitectura de varios agentes, armemos un caso acotado, midamos calidad, costo, tiempo y capacidad de recuperación. Comparemos contra un agente único o incluso contra un workflow mayormente determinista. Observemos no solo el caso feliz, sino también qué tan difícil resulta explicar un fallo.\nEsta comparación es importante porque la sofisticación visual engaña. Un grafo con muchos nodos puede parecer más evolucionado que un ciclo simple, pero la arquitectura no es una escalera en la que siempre debamos subir al peldaño siguiente. A veces un agente con buenas herramientas, una condición de salida clara y una validación sólida resuelve mejor el problema. Otras veces ni siquiera necesitamos un agente: necesitamos código.\nLa decisión madura no es elegir la forma más nueva. Es usar la menor complejidad capaz de sostener el comportamiento que necesitamos.\nEso también cuida a los equipos. La fatiga no aparece solo por aprender herramientas nuevas; aparece por sentir que el conocimiento adquirido vence demasiado rápido. Cuando conectamos una tendencia con fundamentos conocidos, el aprendizaje deja de ser una carrera por memorizar nombres. Un desarrollador que entiende máquinas de estados, concurrencia, idempotencia, observabilidad, contratos y manejo de errores tiene una base para evaluar LangGraph, AutoGen o la herramienta que aparezca después. Tendrá que aprender APIs y particularidades, claro, pero no empieza de cero cada vez.\nEsa continuidad devuelve algo de calma. Nos permite reconocer la novedad sin entregarle toda la agenda.\nLo que queda cuando el nombre desaparece # Graph Engineering puede consolidarse como una disciplina reconocible o puede ser reemplazado pronto por otra expresión. No sabemos todavía cuánto va a durar la etiqueta. Lo que sí sabemos es que los sistemas de agentes van a necesitar coordinación, estado, límites, evaluación, recuperación y personas capaces de entender el conjunto.\nPeter Steinberger no anunció una tecnología con aquella pregunta. Quizás por eso la reacción resulta tan reveladora. Doce palabras alcanzaron para que una parte de la industria sintiera que había comenzado una etapa nueva. Esa velocidad habla menos de los grafos que de nuestra necesidad de ordenar un campo que cambia demasiado rápido.\nLos nombres pueden ayudarnos a hacerlo, siempre que no confundamos el mapa con el territorio. Un mapa nuevo puede mostrar caminos que antes no veíamos, pero no cambia las montañas, los riesgos ni la distancia que hay que recorrer. En software, esas montañas siguen siendo bastante conocidas: sistemas que fallan, estados que se pierden, decisiones que nadie puede explicar, dependencias que se multiplican y equipos que terminan sosteniendo lo que una demo no mostró.\nLa ingeniería empieza cuando bajamos de la etiqueta a esas consecuencias.\nPor eso, frente al próximo término, quizás no necesitemos correr a cambiar nuestros títulos ni reconstruir la arquitectura. Podemos hacer algo menos espectacular y bastante más útil: preguntar qué problema nombra, qué parte es realmente nueva y qué fundamentos siguen siendo los mismos.\nSi después de quitarle el nombre la idea todavía mejora nuestro sistema, vale la pena aprenderla. Si solo queda la urgencia de no quedar afuera de la conversación, tal vez no estemos frente a una nueva ingeniería. Tal vez estemos frente al viejo miedo de siempre, esta vez dibujado como un grafo.\nFuentes consultadas # Peter Steinberger, “Are we still talking loops or did we shift to graphs yet?”, X, 18 de julio de 2026. Sydney Runkle y Harrison Chase, “3 Years of Graph Engineering with LangGraph”, LangChain, 22 de julio de 2026. LangChain, “Graph API overview”, documentación de LangGraph, consultada el 27 de julio de 2026. Jeff Barr, “New – AWS Step Functions – Build Distributed Applications Using Visual Workflows”, AWS News Blog, 1 de diciembre de 2016. Microsoft, “GraphFlow (Workflows)”, documentación de AutoGen, consultada el 27 de julio de 2026. ","date":"27 de julio de 2026","externalUrl":null,"permalink":"/blog/2026-07-27-graph-engineering-el-nombre-es-nuevo-el-problema-no/","section":"Blog","summary":"Hay momentos en tecnología en los que uno siente que se quedó atrás durante un fin de semana. El viernes todavía estábamos tratando de entender una idea, el lunes aparece otra etiqueta que promete superarla y, antes de que podamos probar si algo cambió de verdad, ya hay cursos, diagramas, manifiestos y perfiles profesionales alrededor del nuevo término.\n","title":"Graph Engineering: el nombre es nuevo, el problema no","type":"blog"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/","section":"Hernan Rocca","summary":"","title":"Hernan Rocca","type":"page"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/inteligencia-artificial/","section":"Tags","summary":"","title":"Inteligencia-Artificial","type":"tags"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/liderazgo-t%C3%A9cnico/","section":"Tags","summary":"","title":"Liderazgo Técnico","type":"tags"},{"content":"","date":"27 de julio de 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"A veces me cuesta separar mi historia personal de la historia de nuestra profesión, porque en tecnología muchos llegamos aprendiendo como se podía: leyendo documentación, copiando ejemplos, rompiendo cosas, preguntando en foros, mirando código ajeno y volviendo a intentar cuando algo no funcionaba. Algunos pasaron por la universidad, otros por cursos, otros por trabajos que los obligaron a aprender a los golpes. Pero casi nadie pudo vivir de lo que aprendió una sola vez. En software, tarde o temprano, todos tenemos que volver a aprender sin pedir demasiado permiso.\nA mediados de mayo, esa idea me volvió a aparecer por un camino inesperado: un paper sobre médicos haciendo vibe coding. No desarrolladores profesionales, no equipos de producto, no startups buscando levantar inversión, sino clínicos intentando construir pequeñas herramientas para resolver problemas concretos de su día a día. Y ahí se me mezclaron varias conversaciones que venimos teniendo en este blog: la IA como acelerador, el peligro de confundir velocidad con criterio, y ese lugar incómodo donde la credencial visible no siempre coincide con el oficio real.\nCuando alguien que conoce el problema empieza a construir # A fines de abril se publicó en arXiv un trabajo llamado “Vibe coding for clinicians: democratising bespoke software development for digital health innovation”. La idea central es simple y potente: muchas personas que trabajan en salud se encuentran todos los días con problemas demasiado específicos, demasiado pequeños o demasiado poco atractivos comercialmente como para que una empresa de software los resuelva. Son dolores reales, pero no siempre tienen mercado. Entonces quedan ahí, sostenidos por planillas, procesos manuales, atajos, notas, formularios mal adaptados y paciencia humana.\nEl paper plantea que el vibe coding puede abrir una puerta interesante para ese tipo de casos. Un médico o una médica que entiende muy bien el problema, pero no sabe programar en profundidad, puede usar lenguaje natural para prototipar una herramienta sencilla, validar una idea o darle forma inicial a algo que antes dependía por completo de conseguir tiempo técnico. No lo presentan como reemplazo de desarrolladores profesionales. Al contrario, el texto habla de habilidades de base, desafíos, límites y guardrails para llevar algo a despliegue. Esa aclaración es importante, porque cambia por completo el tono de la conversación.\nLa novedad no es que ahora cualquiera pueda construir cualquier sistema serio sin saber nada. Esa fantasía ya la discutimos varias veces y, cuanto más la miramos, menos se sostiene. La parte interesante es otra: personas que antes estaban condenadas a explicar un problema una y otra vez, esperando que alguien con capacidad técnica tuviera tiempo para escucharlas, ahora pueden producir una primera forma. Imperfecta, limitada, probablemente insegura si se la empuja donde no corresponde, pero suficiente para mostrar una intención con más fuerza que una reunión o un documento.\nEsto conecta con algo que en desarrollo conocemos muy bien. A veces la persona que más entiende el problema no es la que sabe escribir el código más elegante. Y a veces la persona que sabe escribir el código más elegante no entiende todavía qué parte del problema duele de verdad. Cuando esas dos cosas se encuentran, aparece buen software. Cuando se separan demasiado, aparecen sistemas correctos en los papeles y torpes en la realidad.\nPor eso el ejemplo de los clínicos me resulta más interesante que otro anuncio de herramienta para developers. Nos obliga a mirar la programación no solo como escritura de código, sino como una forma de convertir comprensión del mundo en algo ejecutable. Y si lo pensamos así, el autodidacta entra naturalmente en escena. No como el héroe solitario que sabe más que todos, sino como alguien que no espera a que el camino esté completamente autorizado para empezar a entender.\nLa profesión siempre tuvo algo de autodidacta # El tema del autodidacta en tecnología es delicado porque se puede caer muy rápido en dos caricaturas. De un lado está la romantización: el genio que aprende solo, desprecia todo título, no necesita a nadie y descubre verdades que los demás no ven. Del otro lado está la desconfianza automática: si no pasó por el camino formal, entonces su conocimiento es sospechoso, incompleto o amateur. Las dos miradas son pobres.\nLa realidad de nuestra profesión suele ser más mezclada. Hay gente formada en universidades excelentes que además se sigue formando sola toda la vida. Hay gente sin título que construyó una profundidad técnica enorme a fuerza de curiosidad, trabajo y errores. Hay gente con credenciales fuertes que dejó de aprender hace años. Y hay autodidactas que confunden independencia con soberbia, que también los hay. Ningún camino garantiza criterio por sí solo.\nLo difícil de negar es que el software, como oficio, premia la capacidad de aprender por cuenta propia. No porque el aprendizaje formal no sirva, sino porque la velocidad del campo lo vuelve insuficiente si se queda quieto. Stack Overflow, en su encuesta de 2024, decía que los recursos online eran la principal forma de aprender a programar para el 82% de las respuestas, y que la documentación técnica seguía siendo una fuente central de aprendizaje. Un año después, la encuesta de 2025 mostraba que más de un tercio de quienes respondieron habían aprendido a usar herramientas de IA para su trabajo o carrera en el último año. No hace falta leer esos datos como una celebración de “la educación formal murió”; alcanza con leerlos como una señal de algo que vivimos todos los días: programar es estudiar en movimiento.\nY estudiar en movimiento no es cómodo. No tiene el orden de un programa cerrado ni la tranquilidad de que alguien ya filtró todo por nosotros. Muchas veces aprendemos porque un error nos dejó sin salida, porque una librería cambió, porque una arquitectura ya no alcanza, porque un proveedor modificó sus reglas, porque una herramienta nueva aparece y no podemos ignorarla. El autodidacta, en ese sentido, no es necesariamente alguien que aprende solo en una habitación. Es alguien que aprendió a no quedarse esperando a que el permiso, el curso perfecto o la certificación ideal lleguen antes que la necesidad.\nA mí esa actitud me interesa. No como rebeldía adolescente contra las instituciones, sino como una forma adulta de responsabilidad. Cuando un problema cae sobre la mesa, alguien tiene que leer, probar, preguntar, equivocarse, volver a leer y construir una opinión propia. En equipos técnicos reales, esa capacidad vale muchísimo. Y en una época de IA, probablemente valga más, no menos.\nJuzgar por los ojos, tocar con las manos # En el capítulo XVIII de El Príncipe, Maquiavelo escribe que los hombres juzgan más por los ojos que por las manos, porque todos pueden ver pero pocos pueden tocar. La frase aparece en un contexto político, hablando de apariencia, reputación y poder. Pero llevada con cuidado a nuestro mundo, sirve para pensar la diferencia entre lo visible y lo vivido.\nEn tecnología también juzgamos mucho por los ojos. Vemos títulos, cargos, nombres de empresas, certificaciones, repositorios con muchas estrellas, dashboards, métricas, presentaciones prolijas, demos que funcionan. Todo eso puede aportar información, claro. No hay que despreciarlo. Un título puede representar años de esfuerzo; una certificación puede ordenar conocimiento; una trayectoria en una empresa exigente puede decir algo sobre la experiencia de una persona. El problema aparece cuando confundimos esas señales con la totalidad del oficio.\nTocar con las manos es otra cosa. Es haber tenido que sostener un sistema cuando el caso feliz se terminó. Es haber hecho una migración que parecía simple y no lo era. Es haber leído documentación hasta entender por qué una API se comporta distinto de lo que prometía. Es haber aceptado una dependencia y después pagar el costo. Es haber arreglado un incidente sin tener todo el contexto, o haber dicho que no a una solución que brillaba en la demo pero no cerraba con la realidad del equipo.\nEse conocimiento no siempre queda bien empaquetado en una credencial. A veces tampoco queda bien explicado en un CV. Pero se nota cuando la conversación se pone concreta. Se nota en las preguntas que alguien hace, en los riesgos que anticipa, en la humildad con la que valida, en la capacidad de decir “esto no lo sé” sin quedarse paralizado. Ahí aparece el oficio.\nPor eso el autodidacta valioso no es el que rechaza la mirada de los demás, sino el que aprendió a tocar el problema con las manos. No se queda solamente con lo que parece correcto. Lo prueba, lo contrasta, lo rompe si hace falta, y recién después empieza a confiar.\nLa IA baja la barrera, pero también baja algunas defensas # Acá entra la parte nueva de esta época. Durante años, aprender por cuenta propia exigía atravesar cierta fricción. Había que leer documentación, instalar cosas, pelear con errores tontos, entender un mensaje de compilación, buscar en foros, comparar respuestas, preguntar de una manera que otros pudieran responder. Esa fricción era molesta, pero también enseñaba. Obligaba a construir paciencia, vocabulario y criterio mínimo para saber qué estaba pasando.\nLa IA cambió parte de ese recorrido. Hoy alguien puede describir una idea y obtener una primera versión funcional sin atravesar todo ese camino previo. Eso es impresionante. También es peligroso si se confunde con aprendizaje completo.\nEn el post anterior, cuando hablamos de lo que la IA no puede diseñar, la idea de fondo era que producir no es lo mismo que entender. Lalit Maganti pudo construir en tres meses algo que llevaba ocho años postergando, pero también tuvo que tirar un mes entero de trabajo porque el código funcionaba sin que él lo entendiera lo suficiente. Ese caso era de un ingeniero experimentado. Ahora imaginemos ese mismo fenómeno en manos de alguien que recién está entrando a un dominio técnico, o que conoce muy bien el problema de negocio pero todavía no sabe distinguir un prototipo de una base mantenible.\nAhí aparece una tensión que me parece central: la IA puede volver más autodidacta a mucha gente, pero también puede permitirle saltear aprendizajes que antes eran incómodos y necesarios. Puede ayudar a explorar más rápido, pero también puede tapar la ignorancia con una respuesta que suena segura. Puede acercar al médico, al analista, al operador o al fundador de una pyme a la construcción de una herramienta útil, pero si no hay una práctica de validación, también puede dejarlo con una pieza que parece software y se comporta como una deuda esperando su momento.\nGitHub, en su Octoverse 2025, mostró una señal interesante: más de 36 millones de desarrolladores se sumaron a la plataforma en un año, y casi el 80% de los nuevos desarrolladores usó Copilot durante su primera semana. La IA ya no está entrando al final del recorrido, como una herramienta avanzada para gente con años de oficio. Para mucha gente, está en el inicio. Eso cambia la forma en que se aprende, y todavía estamos entendiendo qué se gana y qué se pierde en ese cambio.\nMi intuición es que se gana velocidad, acceso y confianza para empezar. Y eso no es poco. Pero se puede perder algo si no somos cuidadosos: la relación directa con el error. Esa relación áspera, incómoda y a veces frustrante que te obliga a entender por qué algo no funciona. Si la IA nos resuelve siempre la próxima línea antes de que hayamos masticado el problema, corremos el riesgo de avanzar con menos cicatrices, pero también con menos profundidad.\nAutodidacta no es aprender sin otros # Hay una confusión habitual que conviene sacar del medio: ser autodidacta no significa aprender aislado. De hecho, casi nadie aprende así. Aprendemos leyendo a otros, copiando patrones, haciendo preguntas, mirando cómo una comunidad resuelve problemas, recibiendo correcciones, discutiendo con gente que sabe más, y también enseñando lo poco que vamos entendiendo. Lo autodidacta no está en la ausencia de otros; está en la iniciativa propia para ordenar ese aprendizaje.\nEsto importa porque la IA puede empujar una versión demasiado solitaria del aprendizaje. Una conversación con un modelo puede ser muy útil, pero si se convierte en el único espejo, nos puede dejar encerrados en una burbuja muy prolija. El modelo responde siempre, no se cansa, no se ríe de la pregunta, no nos expone frente a nadie. Eso ayuda a animarse, especialmente al principio. Pero también puede quitar una parte valiosa del aprendizaje técnico: la fricción con otras miradas.\nEn un equipo, una mala idea no solo se corrige con un test. A veces se corrige porque alguien pregunta “¿por qué lo hiciste así?”. O porque otro recuerda que esa integración ya falló antes. O porque una persona de producto explica un caso que no habíamos considerado. O porque alguien con más experiencia reconoce un patrón de deuda que todavía no se ve en la superficie. Esa conversación no es un trámite; es parte del aprendizaje.\nEl autodidacta que más me interesa no es el que se encierra en su propio criterio, sino el que se vuelve dueño de su proceso de aprendizaje sin volverse dueño absoluto de la verdad. Sabe buscar solo, pero también sabe pedir revisión. Sabe avanzar sin permiso, pero no sin responsabilidad. Sabe construir una hipótesis, pero la pone a prueba. Sabe que una respuesta de la IA puede destrabar una idea, pero no la convierte automáticamente en conocimiento propio.\nEn este punto la credencial y el autodidactismo dejan de ser enemigos. Una buena formación formal puede dar bases, lenguaje, disciplina y mapa. Una buena actitud autodidacta permite seguir caminando cuando el mapa se queda viejo. Lo que necesitamos en tecnología no es elegir una contra la otra, sino combinar lo mejor de ambas: fundamentos y curiosidad, método y hambre, comunidad y autonomía.\nLa objeción honesta # La objeción a esta defensa del autodidacta es necesaria: aprender por cuenta propia también puede salir mal. No todo cuestionamiento es profundidad. No toda independencia es criterio. A veces el autodidacta se enamora de su propio camino y empieza a despreciar cualquier advertencia externa. Confunde no haber pedido permiso con no necesitar revisión. Y ahí deja de ser una fortaleza para convertirse en un riesgo.\nEsto se vuelve todavía más sensible con IA, porque la herramienta puede reforzar esa ilusión. Si uno le pregunta con suficiente insistencia, casi siempre obtiene una explicación que acompaña su dirección. Puede pedir una arquitectura, después pedir argumentos para defenderla, después pedir respuestas a las objeciones, y terminar rodeado de texto convincente sin haber pasado por una validación real. Antes el autodidacta tenía que pelearse más con la realidad; ahora puede pelearse durante horas con una simulación de realidad que le contesta muy bien.\nPor eso no me gusta romantizar. Hay autodidactas brillantes y autodidactas peligrosos, del mismo modo que hay profesionales formados excelentes y profesionales formados que se esconden detrás del diploma. La diferencia no está en el origen del aprendizaje, sino en la relación con la verdad, con el error y con los demás.\nUn autodidacta sano no se define por aprender solo, sino por hacerse cargo de lo que todavía no sabe. Esa es la parte menos vistosa y más importante. No alcanza con decir “yo aprendo por mi cuenta” si después no verificamos, no leemos documentación, no dejamos que otros revisen, no entendemos los límites de lo que construimos y no aceptamos cuando una decisión propia estaba mal. La autonomía sin humildad se parece demasiado a la improvisación.\nTambién conviene reconocer algo incómodo: las instituciones cumplen una función. No todo sello es decorado. En medicina, en ingeniería civil, en seguridad, en sistemas críticos, las credenciales, los procesos y las revisiones existen porque el costo del error puede ser enorme. El problema no es que existan filtros; el problema es creer que el filtro reemplaza al criterio, o que quien no pasó por ese filtro no puede construir comprensión genuina en ningún terreno.\nLo que conviene cuidar en esta nueva etapa # Si el vibe coding para clínicos nos dice algo, no es que los médicos vayan a reemplazar a los equipos de software ni que los desarrolladores profesionales nos volvimos accesorios. Nos dice que la frontera de quién puede empezar a construir se está moviendo. Personas con conocimiento profundo de un dominio van a poder prototipar más. Equipos chicos van a poder probar más ideas. Gente que antes quedaba afuera del primer paso técnico va a poder acercarse. Eso es bueno.\nPero cuanto más se abre la puerta de entrada, más importante se vuelve enseñar qué hay después de la puerta. No alcanza con celebrar que alguien hizo una app en una tarde. La pregunta importante es qué aprendió mientras la hacía, qué entiende de lo que quedó funcionando, qué riesgos sabe detectar, qué partes no debería tocar sin ayuda, qué datos está manejando, qué pasa si falla y quién se hace cargo cuando deja de ser experimento.\nPara los equipos técnicos, esto puede ser una oportunidad enorme si no la leemos desde el miedo. En lugar de pelear contra usuarios internos que empiezan a prototipar, quizás convenga ayudarlos a hacerlo mejor. Darles marcos simples, espacios seguros, reglas de datos, criterios para distinguir demo de producto, caminos para pedir revisión y formas de traer esas ideas al equipo sin que se conviertan en sistemas paralelos imposibles de mantener.\nEse puede ser un rol nuevo del área técnica: no solo construir todo, sino elevar la capacidad de construcción responsable alrededor suyo. Algo parecido a lo que pasó con las planillas durante décadas. Nadie en tecnología pudo impedir que negocio usara Excel para resolver problemas reales. La pregunta siempre fue si mirábamos para otro lado hasta que la planilla se volvía crítica, o si ayudábamos a ordenar, integrar y profesionalizar lo que había nacido como solución de emergencia.\nCon la IA puede pasar algo parecido, pero más rápido y con más alcance. Van a aparecer prototipos, automatizaciones, scripts, flujos y pequeñas herramientas creadas por personas que conocen el problema mejor que el stack. Algunas serán descartables. Otras van a mostrar necesidades reales que el roadmap no estaba viendo. Y otras, si nadie las mira, se pueden transformar en riesgo operativo.\nEl desafío no es cerrar la puerta. Es poner un umbral claro entre aprender, prototipar y operar.\nAprender sin pedir permiso, pero no sin hacerse cargo # Creo que por eso el tema autodidacta vuelve con tanta fuerza en este momento. La IA nos está devolviendo una pregunta antigua con una forma nueva. Antes preguntábamos si hacía falta un título para programar. Ahora quizás la pregunta sea si hace falta entender para construir. Y esa pregunta, aunque parezca exagerada, empieza a aparecer cada vez que alguien arma algo funcional sin haber pasado por el camino técnico tradicional.\nMi respuesta, por ahora, es incómoda pero bastante simple: para empezar a construir, cada vez hace falta menos. Para hacerse cargo de lo construido, hace falta igual o más que antes.\nEse es el punto donde se juntan el oficio autodidacta, Maquiavelo y la IA. Juzgar por los ojos es ver la herramienta funcionando, la demo respondiendo, el formulario guardando datos, el agente explicando su propio código. Tocar con las manos es entender qué pasa cuando cambia una regla, cuando aparece un dato raro, cuando hay que auditar un acceso, cuando otra persona hereda el proyecto, cuando el error deja de ser una molestia y se vuelve consecuencia.\nAprender por cuenta propia sigue siendo una de las capacidades más valiosas de nuestra profesión. No porque nos haga más libres de toda autoridad, sino porque nos obliga a construir una autoridad interior que no depende únicamente de que alguien nos diga qué estudiar después. Pero esa libertad tiene precio: exige método, paciencia, humildad y una relación honesta con el error.\nTal vez el autodidacta que necesitamos en tiempos de IA no sea el que aprende más rápido ni el que produce más con menos instrucciones. Tal vez sea el que sabe cuándo la herramienta lo está ayudando a entender y cuándo solo lo está ayudando a avanzar sin entender. Esa diferencia va a importar cada vez más.\nY quizás la pregunta que conviene llevarnos a nuestros equipos no sea quién tiene más credenciales ni quién usa más IA, sino otra más difícil de medir: cuando algo parece funcionar, ¿tenemos gente capaz de tocarlo con las manos, entenderlo de verdad y hacerse cargo de lo que pasa después?\nFuentes consultadas # Ariel Yuhan Ong, Iain Livingstone, Caroline Kilduff, Mertcan Sevgi, David A. Merle, Eden Ruffell, Pearse A. Keane y Fares Antaki, “Vibe coding for clinicians: democratising bespoke software development for digital health innovation”, arXiv, enviado el 24 de abril de 2026, revisado el 27 de abril de 2026. Stack Overflow, “2024 Developer Survey”, 2024. Stack Overflow, “2025 Developer Survey”, 2025. GitHub, “Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1”, 28 de octubre de 2025, actualizado el 28 de febrero de 2026. Nicolás Maquiavelo, El Príncipe, capítulo XVIII, 1513. ","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/blog/post-aprender-sin-pedir-permiso/","section":"Blog","summary":"Durante años, la tecnología dejó lugar para quienes aprendían por su cuenta, rompían cosas, leían documentación y construían criterio fuera de los caminos formales. Con la IA y el vibe coding, esa frontera se vuelve más borrosa: cada vez más personas pueden crear prototipos sin saber programar en profundidad. El desafío no es defender el diploma ni romantizar al autodidacta, sino entender qué tipo de aprendizaje nos permite tocar los problemas con las manos y no quedarnos solo con lo que parece conocimiento.","title":"Aprender sin pedir permiso: el oficio autodidacta en tiempos de IA","type":"blog"},{"content":"","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/tags/aprendizaje/","section":"Tags","summary":"","title":"Aprendizaje","type":"tags"},{"content":"","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/tags/autodidacta/","section":"Tags","summary":"","title":"Autodidacta","type":"tags"},{"content":"","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/tags/criterio-tecnico/","section":"Tags","summary":"","title":"Criterio-Tecnico","type":"tags"},{"content":"","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/tags/desarrollo/","section":"Tags","summary":"","title":"Desarrollo","type":"tags"},{"content":"","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/tags/ia/","section":"Tags","summary":"","title":"Ia","type":"tags"},{"content":"","date":"15 de mayo de 2026","externalUrl":null,"permalink":"/tags/vibe-coding/","section":"Tags","summary":"","title":"Vibe-Coding","type":"tags"},{"content":"","date":"25 de abril de 2026","externalUrl":null,"permalink":"/tags/cultura-tecnica/","section":"Tags","summary":"","title":"Cultura-Tecnica","type":"tags"},{"content":"","date":"25 de abril de 2026","externalUrl":null,"permalink":"/tags/liderazgo-tecnico/","section":"Tags","summary":"","title":"Liderazgo-Tecnico","type":"tags"},{"content":"A veces la IA nos ayuda tanto que cuesta ver en qué momento dejó de ayudarnos. Nos destraba, nos acelera, nos pone algo funcionando delante de los ojos y nos da esa sensación tan adictiva de avance. Y, sin embargo, en desarrollo de software hay una diferencia enorme entre avanzar y estar construyendo algo que después vamos a poder sostener.\nVengo pensando esto desde que empezamos a hablar de vibe coding. Primero apareció el deslumbramiento, después las primeras dudas, y con el tiempo empezaron a llegar las historias más interesantes: no las que venden magia ni las que decretan que todo es humo, sino las que muestran el uso real, con sus beneficios y sus cicatrices. Este post nace de una de esas historias.\nNo quiero usarla para decir que la IA sirve o no sirve. Esa discusión ya quedó chica. Me interesa otra cosa: entender qué parte del trabajo técnico puede acelerar una IA y qué parte, aunque nos incomode, sigue necesitando que alguien piense, decida y se haga cargo.\nUna historia de éxito con una cicatriz adentro # Este mes leí un post de Lalit Maganti, ingeniero de Google, que me quedó dando vueltas varios días. El artículo se llama “Eight years of wanting, three months of building with AI” y cuenta cómo construyó syntaqlite, un conjunto de herramientas para trabajar mejor con SQLite: parser, formatter, linter, validador, extensiones para editores y documentación. Dicho en una línea suena a otro relato de éxito con IA, pero lo valioso está justamente en que no intenta venderlo como una historia limpia.\nMaganti venía cargando esa idea desde hacía ocho años. No era una de esas ideas que uno anota un martes y olvida el jueves; era algo que tenía sentido para su trabajo, algo que le molestaba no tener, pero que siempre quedaba postergado porque combinaba dos condiciones difíciles: era complejo y, además, tedioso. Había que entender partes profundas de SQLite, trabajar sobre parser, reglas de gramática, tests, tooling, documentación. Es el tipo de proyecto que puede entusiasmar en abstracto y agotarte apenas abrís el editor.\nCon agentes de coding, logró hacerlo avanzar. En unos tres meses publicó una primera versión y cerró una deuda personal que llevaba demasiado tiempo esperando. Hasta ahí, la historia confirma algo que muchos ya intuíamos o estamos viviendo: la IA puede ser extraordinaria para romper la inercia. A veces no necesitamos que resuelva todo; necesitamos que transforme una idea inmanejable en algo concreto que podamos mirar, discutir y corregir.\nLo interesante empieza cuando cuenta lo que pasó en enero. Maganti decidió probar una versión extrema del trabajo con IA: usar Claude Code para delegar casi todo. Diseño, implementación, estructura general, decisiones técnicas. Él mismo describe su rol de ese momento como el de un manager semi técnico que iba pidiendo cosas y dejando que el agente construyera. Y el resultado inicial, visto desde afuera, parecía muy bueno: había parser, formatter, playground web, soporte para distintas piezas del proyecto y más de quinientos tests.\nPero cuando se sentó a revisar el código en serio, apareció el problema que ningún demo muestra. El código funcionaba, sí, pero él no lo entendía lo suficiente. Lo llamó “complete spaghetti”: funciones repartidas en lugares raros, archivos enormes, una estructura frágil y una sensación muy conocida para cualquiera que haya tenido que mantener sistemas reales. Eso anda ahora, pero no lo voy a poder sostener.\nEntonces tomó una decisión dolorosa y sana: tiró ese primer mes de trabajo y empezó de nuevo.\nPara mí, ahí está el centro de la historia. No en que la IA haya logrado escribir mucho código, ni en que haya fallado. Las dos cosas son ciertas y ninguna alcanza por sí sola. Lo importante es que la misma herramienta que destrabó el proyecto también permitió postergar decisiones de diseño que no convenía postergar. Y cuando esas decisiones volvieron a la mesa, volvieron con intereses.\nCuando la IA nos ayuda a empezar # No me interesa escribir este post desde el lugar cómodo de “cuidado con la IA”. Sería injusto, y además no es lo que pienso. Sin IA, probablemente syntaqlite no existiría, o existiría mucho más tarde, más chico y con menos alcance. El propio Maganti lo dice con claridad: la IA fue la razón por la que el proyecto dejó de ser una idea pesada en la cabeza y se convirtió en algo real.\nEsa parte se reconoce muy fácil desde nuestro trabajo cotidiano. Muchas veces el problema no es que no sepamos hacer algo, sino arrancar. Darle forma inicial a una idea, escribir la primera versión de un flujo, armar un borrador de arquitectura, entender por dónde entrar a una librería o generar un ejemplo para empezar a discutir. En ese terreno, la IA puede ser una diferencia enorme porque nos permite pasar de la nebulosa al material. Y cuando hay material, aunque sea imperfecto, pensamos mejor.\nEsto conecta con lo que veníamos hablando en posts anteriores sobre el vibe coding. En “Después del vibe coding: qué quedó y qué se cayó” intenté separar el grano de la paja: no quedarme ni con la promesa exagerada de que ya no hacía falta saber programar, ni con el cinismo de que todo era humo. Lo que quedó, para mí, era bastante concreto: la velocidad de exploración. Poder probar un enfoque, descartarlo, pedir otra variante y tener una conversación con algo que funciona cambió la forma en que muchos empezamos a pensar ciertos problemas.\nPero esa ventaja tiene una condición: tenemos que seguir dentro del proceso. La IA sirve mucho como generadora de material para pensar; empieza a complicarnos cuando la convertimos en reemplazo del pensamiento. Una cosa es pedirle una primera forma para reaccionar, romper, corregir y bajar a la realidad del proyecto. Otra muy distinta es dejar que tome decisiones que después el equipo va a tener que sostener en producción, en mantenimiento, en una migración, en un incidente o frente a otro desarrollador que pregunte por qué eso quedó así.\nAhí cambia el tipo de responsabilidad. Mientras estamos explorando, equivocarse es parte del juego. En producción, equivocarse también es parte del juego, pero el costo lo paga alguien. Lo paga el equipo que mantiene, el cliente que sufre un error, la persona que entra nueva y no entiende nada, o el negocio que descubre tarde que la arquitectura elegida no aguanta el próximo cambio.\nPor eso encuentro tan potente el caso de Maganti. No porque nos diga “usen IA” o “no usen IA”, sino porque muestra una frontera clara: la IA fue excelente para romper la inercia, para generar pruebas, para acelerar código obvio y para acompañar aprendizaje. Fue mucho peor cuando se le pidió que cargara con el diseño profundo del sistema.\nEl piloto automático y el costo que llega después # Hay una diferencia que en software conocemos desde mucho antes de la IA: no es lo mismo que algo funcione a que algo se pueda mantener. Un sistema puede funcionar porque nadie lo toca, porque dos personas conocen los rituales para no romperlo, porque el caso feliz está cubierto o porque todavía no apareció el cambio que lo obliga a mostrar sus costuras. La IA no inventó ese problema, pero puede hacerlo crecer a una velocidad nueva.\nAhora podemos generar más estructura aparente en menos tiempo: más archivos, más tests, más documentación, más comentarios, más carpetas y más explicaciones. Todo eso produce una sensación muy fuerte de avance. El repositorio se mueve, los commits se acumulan, la demo responde y el agente explica con seguridad por qué hizo lo que hizo. Pero un sistema puede tener mucha actividad alrededor y estar mal pensado igual.\nEl primer mes de syntaqlite es un ejemplo muy claro. Había más de quinientos tests, y eso no es menor. De hecho, muchos de esos tests después le sirvieron para reconstruir con más seguridad. Pero los tests no reemplazaban una base conceptual clara. Podían decir que ciertas funciones devolvían lo esperado en ciertos casos; no podían decir si las responsabilidades estaban bien ubicadas, si la API iba a ser cómoda de usar, si la separación entre componentes iba a soportar el crecimiento o si el proyecto tenía una forma que alguien pudiera razonar dentro de seis meses.\nEsa es una de las trampas de esta etapa: vamos a ver muchos repositorios con apariencia de madurez mayor a la real. Código prolijo, tests generados, documentación generada, nombres razonables, explicaciones elegantes. Todo eso ayuda, claro, pero también puede tapar la pregunta más importante: ¿alguien pensó de verdad la forma del sistema?\nLa arquitectura no está para decorar diagramas ni para que un documento quede lindo en una wiki. Está para poner límites, para definir qué decisiones ya están tomadas, qué partes pueden cambiar sin romper todo, qué dependencias aceptamos y cuáles no, qué comportamiento esperamos del sistema cuando deja de estar en el caso feliz. Cuando la IA entra fuerte al flujo de desarrollo, esos límites se vuelven más importantes, no menos. Si el proyecto tiene una forma clara, la IA puede trabajar dentro de esa forma. Si el proyecto ya es confuso, la IA puede copiar esa confusión con una prolijidad que engaña.\nMaganti cuenta otro efecto que suena muy humano: la pérdida de contacto con el propio código. No necesariamente dejar de entender la arquitectura general, sino perder el detalle vivo de qué vive dónde, qué función llama a cuál, qué cambio resolvía qué problema y por qué una componente quedó de cierta manera. Cuando eso pasa, la conversación con el agente se degrada. Ya no le pedimos que cambie una clase concreta; empezamos a pedirle que cambie “eso que hace tal cosa”, y el agente tiene que reconstruir a medias lo que nosotros dejamos de tener claro.\nEse momento es incómodo porque invierte el rol. El desarrollador empieza a parecerse al manager que pide cosas sobre un código que no entiende. Y cualquiera que haya trabajado en sistemas reales sabe lo peligroso que es eso: se toman decisiones desde la superficie, se aceptan explicaciones que suenan razonables y se pierde el modelo mental que permite detectar cuando algo está torcido aunque compile.\nEscribir código nunca fue solamente producir texto que la máquina ejecuta. También es construir una representación mental del sistema: saber qué partes son delicadas, qué atajos se tomaron, qué decisiones sostienen el diseño, qué cosas no conviene tocar sin mirar dos veces. Cuando delegamos demasiado, podemos seguir produciendo código mientras dejamos de construir ese modelo. Y un equipo que pierde el modelo mental compartido empieza a depender de rituales, documentación generada y consultas permanentes al agente para entender lo que, en realidad, debería formar parte de su oficio.\nLa trampa de medir insumos # Mientras leía el caso de Maganti apareció otro tema que encaja demasiado bien con esta conversación: el tokenmaxxing. TechCrunch publicó el 17 de abril un artículo titulado “\u0026lsquo;Tokenmaxxing\u0026rsquo; is making developers less productive than they think”, y la idea funciona casi como una caricatura de esta etapa: medir o celebrar el uso de herramientas de IA por la cantidad de tokens consumidos.\nLa lógica suena simple: más tokens, más uso; más uso, más productividad. El problema está en el salto que hay entre una cosa y la otra. Medir tokens es medir insumo, no resultado. Es como medir líneas de código para saber si un equipo produce buen software. Ya aprendimos hace décadas que más líneas no significan mejor sistema; pueden significar más valor, pero también más ruido, más mantenimiento, más superficie de error y más deuda.\nCon los tokens pasa algo parecido. Que alguien use mucho una herramienta de IA no dice, por sí solo, que esté generando más valor. Puede estar investigando mejor, automatizando tareas repetitivas, revisando código, aprendiendo un dominio nuevo o destrabando trabajo real. Pero también puede estar quemando tokens para producir prototipos que va a tirar, preguntar cosas que estaban en la documentación, generar código que después otra persona va a tener que limpiar o inflar una métrica interna que alguien puso de moda.\nEl artículo de TechCrunch junta varias señales de empresas de analítica de ingeniería que apuntan en la misma dirección. Waydev trabaja con más de cincuenta clientes y más de diez mil ingenieros; según su CEO, algunos managers ven tasas de aceptación de código generado por IA del 80% o 90%, pero al mirar el churn posterior descubren que una parte importante de ese código se revisa, se cambia o se reescribe en las semanas siguientes. GitClear reportó en enero que los usuarios frecuentes de IA tenían mucho más churn que quienes no la usaban. Faros AI, en su informe de marzo de 2026, habla de aumentos fuertes en tamaño de PR, bugs por PR, tiempo de review, incidentes por PR y churn en contextos de alta adopción de IA. Jellyfish, por su parte, analizó datos del primer trimestre de 2026 y encontró algo lógico pero importante: más tokens se correlacionan con más output, pero a un costo por unidad mucho más alto.\nDicho en criollo: se mueve más la máquina, pero no necesariamente se aprovecha mejor la energía.\nNo conviene leer estos datos como una condena definitiva. Varias de estas empresas venden herramientas para medir productividad de ingeniería, así que también tienen incentivos propios. Pero incluso con esa salvedad, el patrón es demasiado familiar como para ignorarlo: cuando una métrica se vuelve objetivo, la gente aprende a jugar el juego de esa métrica. Si celebramos tokens, la gente va a consumir tokens. Si celebramos PRs, la gente va a mover PRs. Si celebramos líneas, la gente va a escribir líneas. Y ninguna de esas cosas garantiza que el sistema haya quedado mejor.\nThe Pragmatic Engineer contó otro ángulo de esta misma historia: leaderboards internos, dashboards de consumo y equipos donde algunos developers empiezan a sentir que usar poca IA puede hacerlos parecer poco “AI-native”. Ese tipo de presión cultural me preocupa más que la herramienta en sí, porque convierte una capacidad útil en una performance. Ya no usamos IA porque mejora una tarea concreta, sino porque tenemos que demostrar que la estamos usando.\nLas métricas de volumen son seductoras porque son fáciles de mostrar. En un dashboard quedan lindas. Dan una sensación de movimiento. Pero muchas veces son pobres para explicar si estamos construyendo mejor. Y esto pega directo en el liderazgo técnico, porque cuando la presión por adoptar IA llega desde arriba, es muy tentador buscar una métrica rápida para demostrar avance: usuarios activos, tokens consumidos, porcentaje de código asistido por IA, cantidad de PRs creados con ayuda de agentes.\nNo digo que esas métricas no sirvan para nada. Sirven como señales parciales. Pueden mostrar adopción, uso, gasto, fricción o interés. El problema aparece cuando dejan de ser señales y se convierten en objetivos. Ahí empiezan a empujar comportamientos que después paga el sistema.\nY cuando el uso se vuelve un símbolo, el criterio se corre del centro.\nEl senior no desaparece, se mueve # Hay una pregunta que escucho bastante: si la IA escribe código, ¿qué queda para los developers? La entiendo, pero me parece incompleta. En sistemas reales, el trabajo de desarrollo nunca fue solo escribir código. Fue entender un problema, conversar con negocio, detectar supuestos, elegir una solución que el equipo pueda sostener, anticipar riesgos, simplificar, revisar, probar, operar, aprender de incidentes y explicar decisiones cuando algo no sale como esperábamos.\nLa IA puede ayudar en muchas de esas partes, pero no se hace responsable por ellas. No tiene historia del sistema en el mismo sentido en que la tiene una persona que estuvo en las migraciones, en los incidentes, en las conversaciones incómodas con negocio y en las decisiones que después hubo que defender. Puede recibir contexto, sí, y cada vez va a recibir más. Pero una cosa es procesar contexto y otra es cargar con la memoria operativa de un equipo.\nPor eso no veo al rol senior perdiendo importancia. Lo veo cambiando de lugar. Antes un senior podía destacarse mucho por escribir buen código, rápido y con pocas vueltas. Eso sigue teniendo valor, pero quizás su aporte más importante en esta etapa sea otro: evitar que el equipo acepte código correcto en el lugar equivocado, una abstracción que parece elegante pero no encaja, una dependencia innecesaria, una arquitectura que el agente defiende muy bien pero que no soporta el negocio real.\nEse trabajo es menos vistoso. No siempre deja un commit grande. A veces el valor está en lo que no se escribió, en la dependencia que no se agregó, en el flujo que se simplificó, en el refactor que se hizo antes de que el sistema se volviera inmanejable o en la pregunta incómoda que frenó una mala decisión. Y eso también es productividad, aunque ningún leaderboard de tokens lo capture bien.\nLa IA, en ese sentido, expone el criterio. Cuando implementar era más costoso, parte del criterio estaba mezclado con la habilidad de producir. Ahora que producir se acelera, la capacidad de decidir qué aceptar, qué rechazar y qué revisar se vuelve más visible. Un buen developer puede ir mucho más rápido con IA. Pero alguien sin suficiente experiencia también puede aceptar mucho más rápido soluciones que no entiende. Y el costo de eso rara vez aparece al hacer merge; aparece después, cuando el sistema pide mantenimiento.\nUsarla bien también es una práctica de equipo # Hay otro punto que no conviene dejar en el plano individual. Usar IA en desarrollo no puede depender solamente del estilo personal de cada developer. Si cada persona usa una herramienta distinta, con criterios distintos, pegando contexto distinto, aceptando código con niveles de revisión distintos y documentando de formas distintas, el equipo empieza a trabajar de manera despareja. No por mala intención, sino porque no hay acuerdos compartidos.\nY cuando no hay acuerdos, la IA completa los huecos. Igual que completa código.\nLos equipos van a necesitar conversaciones más explícitas. Para qué usamos IA y para qué no. Qué tipo de tareas admiten baja supervisión y cuáles requieren revisión humana fuerte. Qué información no se puede pegar en herramientas externas. Qué reglas de arquitectura debe respetar cualquier salida generada. Qué hacemos cuando una solución funciona pero no encaja con los acuerdos del proyecto. Cómo dejamos registro de decisiones importantes tomadas con ayuda de IA. En qué momento una persona tiene que parar, leer el código y recuperar el modelo mental antes de seguir pidiendo cambios.\nNo se trata de burocratizar todo ni de matar la experimentación. Al contrario: la experimentación necesita territorio seguro para no convertirse en accidente. Si vamos a usar agentes para tocar código, revisar repositorios, abrir PRs o automatizar partes del flujo, necesitamos pensar el arnés de esos agentes. Qué herramientas tienen permitidas, qué memoria usan, qué logs dejan, quién revisa sus cambios, qué pasa si fallan, cuánto dependemos del proveedor del modelo y qué costo tendría cambiarlo mañana.\nEsto también conecta con otra conversación que aparece cada vez más en proyectos serios: no alcanza con elegir el mejor modelo del momento. Los modelos cambian, los precios cambian, las políticas cambian, la disponibilidad cambia. Si construimos procesos críticos demasiado pegados a un proveedor o a una forma específica de responder, después el costo de movernos puede ser enorme. La capa importante no debería ser solo la llamada a una API, sino el proceso que rodea esa llamada: reglas, memoria, herramientas, límites, revisión y capacidad de reemplazo.\nLa IA empieza a parecerse menos a una herramienta aislada y más a una capa de arquitectura. Y como toda capa de arquitectura, necesita diseño.\nLa objeción honesta # Antes de cerrar la idea, conviene mirar la objeción más fuerte a todo esto: si Maganti no hubiera usado IA con cierta audacia, probablemente no habría construido syntaqlite. O lo habría construido mucho más tarde, con menos alcance y menos energía. Si cada vez que aparece una herramienta potente la rodeamos de advertencias, procesos y miedo, también podemos matar lo mejor que trae.\nEsa objeción es válida. De hecho, conviene tenerla presente. La IA no es solo un riesgo a controlar; es una capacidad nueva que nos permite hacer cosas que antes no encaramos. Puede bajar la barrera de entrada a proyectos pesados, acelerar aprendizaje, facilitar documentación, generar tests, ayudar a leer código heredado, proponer alternativas y acompañarnos en tareas repetitivas que consumían demasiada energía.\nEl problema no es usarla mucho. El problema es usarla sin distinguir el terreno. Hay tareas donde la salida es verificable: una función concreta, un test sobre una regla clara, un script acotado, una explicación inicial de un stack trace. Ahí la IA puede ir muy rápido porque tenemos formas relativamente simples de validar si sirve. Pero hay tareas donde la respuesta no es local ni objetiva: diseñar una API que se sienta bien, definir la arquitectura de un sistema que va a crecer, elegir una dependencia que condiciona al equipo, decidir qué parte conviene no construir. Ahí la IA puede ayudar a pensar, pero no debería decidir por nosotros.\nQuizás la regla más simple sea esta: cuanto menos entendemos el terreno, menos deberíamos delegar la decisión final. La IA puede ayudarnos a explorar un dominio nuevo, pero si todavía no sabemos distinguir una buena solución de una mala, estamos en el momento de ir con más cuidado, no con menos. Las respuestas que suenan correctas son especialmente peligrosas cuando no tenemos suficiente contexto para discutirlas.\nLo que me deja esta historia es una distinción que vale la pena llevar a cada equipo: producción y criterio no son lo mismo. Durante años estuvieron muy mezclados, porque para producir software había que escribir mucho código y, al escribirlo, íbamos construyendo comprensión. Ahora la producción se acelera, y eso nos obliga a cuidar con más intención la parte que no se acelera igual.\nEntender qué construir sigue llevando tiempo. Decidir qué no construir sigue llevando tiempo. Diseñar una arquitectura que soporte cambios sigue llevando tiempo. Construir criterio compartido en un equipo sigue llevando tiempo. Aprender de los errores sigue llevando tiempo. La IA puede ayudar en todo eso, pero no lo elimina.\nMe gusta pensarla como un acelerador. Pero un acelerador sin dirección no es una estrategia; es una forma elegante de llegar más rápido al lugar equivocado. Y en desarrollo de software ya conocemos esa película: sistemas que crecieron rápido y después nadie pudo mantener, herramientas adoptadas por moda que duplicaron problemas, métricas que parecían mostrar progreso mientras el equipo se llenaba de deuda, decisiones tomadas con entusiasmo que se transformaron en años de mantenimiento.\nLa IA no nos saca de esa historia. Nos pone una versión más rápida enfrente.\nPor eso, quizás la pregunta que conviene llevarnos no es si estamos usando IA o no. Esa pregunta ya quedó vieja. La pregunta más útil es otra: ¿sabemos distinguir qué parte de nuestro trabajo puede acelerar la IA y qué parte necesita que alguien se siente, piense, decida y se haga cargo? Porque si esa diferencia no está clara, el riesgo no es que la IA no funcione. El riesgo es que funcione lo suficiente como para que tardemos demasiado en darnos cuenta de que dejamos de diseñar.\nFuentes consultadas # Lalit Maganti, “Eight years of wanting, three months of building with AI”, lalitm.com, 5 de abril de 2026. Simon Willison, “Eight years of wanting, three months of building with AI”, Simon Willison’s Weblog, 5 de abril de 2026. Tim Fernholz, “\u0026lsquo;Tokenmaxxing\u0026rsquo; is making developers less productive than they think”, TechCrunch, 17 de abril de 2026. GitClear, “Developer Cohort Analysis: AI Coding Tools Attract Top Performers — But Do They Create Them?”, 4 de enero de 2026. Faros AI, “AI Engineering Report 2026: The Acceleration Whiplash”, marzo de 2026. Jellyfish, “Is Tokenmaxxing Cost-Effective? New Data from Jellyfish Explains”, 15 de abril de 2026. Gergely Orosz, “The Pulse: ‘Tokenmaxxing’ as a weird new trend”, The Pragmatic Engineer, abril de 2026. ","date":"25 de abril de 2026","externalUrl":null,"permalink":"/blog/post-lo-que-la-ia-no-puede-disenar/","section":"Blog","summary":"Un ingeniero de Google contó cómo logró construir en tres meses un proyecto que venía postergando hacía ocho años. La IA fue clave para destrabarlo, pero también lo llevó a tirar un mes entero de trabajo y empezar de nuevo. Al mismo tiempo, varias empresas empiezan a medir productividad por tokens consumidos, como si quemar más IA fuera igual a trabajar mejor. El problema no es la IA: el problema es olvidar que el software necesita criterio, arquitectura, contexto y alguien que se haga cargo de las decisiones difíciles.","title":"Lo que la IA no puede diseñar","type":"blog"},{"content":"","date":"7 de marzo de 2026","externalUrl":null,"permalink":"/tags/criterio/","section":"Tags","summary":"","title":"Criterio","type":"tags"},{"content":"El 26 de febrero, Dario Amodei publicó una declaración formal diciendo que Anthropic no iba a ceder a dos demandas del Departamento de Defensa. El 27, el secretario de Defensa Pete Hegseth le puso un ultimátum con fecha y hora: hasta las 5:01 de la tarde del viernes. El día empezó con un artículo de CNBC titulado \u0026ldquo;Anthropic faces lose-lose scenario\u0026rdquo;. Y el 5 de marzo, el Pentágono hizo efectiva la designación. Anthropic es oficialmente, según el Departamento de Defensa de los Estados Unidos, un riesgo para la cadena de suministro nacional. Nunca antes esa etiqueta se había aplicado a una empresa del propio país. Cuando lo leí, mi reacción inmediata no fue política. Fue de oficio. Me pregunté cuántos equipos habían tomado la decisión de construir sobre los modelos de Anthropic sin haber pensado siquiera una vez en este tipo de escenario.\nQuiero contar esta historia con cuidado, porque tiene varias capas y es fácil quedarse con la más ruidosa. La más ruidosa es la geopolítica: el gobierno de Trump vs. una empresa de IA, derechos civiles vs. capacidad militar, Silicon Valley vs. Washington. Eso es real y es importante, pero no es de lo que quiero hablar. Lo que me interesa de esta historia es lo que revela sobre las dependencias que construimos sin darnos cuenta, y sobre una dimensión de riesgo que casi nunca aparece en los mapas de arquitectura que miramos antes de elegir un proveedor.\nLa historia, tal como pasó # Hay un contexto que la mayoría de los artículos sobre este episodio omite porque hace más incómodo el relato. En julio de 2025, Anthropic firmó un contrato con el Departamento de Defensa por 200 millones de dólares para \u0026ldquo;prototipar capacidades de IA de frontera que avancen la seguridad nacional de EE.UU.\u0026rdquo;. Claude fue el primer modelo de un laboratorio privado en integrarse en redes clasificadas del gobierno. En esas condiciones, Anthropic incluyó salvaguardas: ciertas aplicaciones estarían fuera de los términos del contrato.\nLa tensión escaló cuando, según fuentes consultadas por ethixbase360, el Pentágono apareció utilizando Claude en una operación que Anthropic consideró que excedía sus términos —la operación que derivó en la captura de Nicolás Maduro en Venezuela. Cuando Anthropic objetó ese uso, la administración Trump endureció su postura: quería acceso sin restricciones a Claude para cualquier uso legal, sin excepciones. Y Anthropic se negó.\nEl 26 de febrero, Dario Amodei publicó una declaración que me pareció uno de los documentos más interesantes que leí este mes. Allí explicó los dos límites que Anthropic no estaba dispuesto a cruzar en sus discusiones con el Departamento de Guerra de Estados Unidos: la vigilancia masiva doméstica y las armas completamente autónomas.\nSobre la primera, escribió que una IA poderosa permite ensamblar datos dispersos, individualmente inocuos, hasta construir un panorama completo de la vida de cualquier persona, de forma automática y a escala masiva. Sobre la segunda, sostuvo que los sistemas actuales de IA de frontera todavía no son lo suficientemente confiables como para impulsar armas completamente autónomas.\nY cerró con una frase que fue recogida por varios medios: “Estas amenazas no cambian nuestra posición: no podemos, en buena conciencia, acceder a su pedido”.\nEl Pentágono respondió a través de su vocero Sean Parnell, en un tono muy distinto: \u0026ldquo;Este es un pedido simple y de sentido común que va a evitar que Anthropic ponga en riesgo operaciones militares críticas y potencialmente ponga en peligro a nuestros combatientes. No vamos a dejar que NINGUNA empresa dicte los términos sobre cómo tomamos decisiones operacionales.\u0026rdquo; Emil Michael, el subsecretario de defensa para investigación e ingeniería, fue más directo aún: en X, llamó a Amodei \u0026ldquo;un mentiroso con complejo de Dios\u0026rdquo;.\nLa analista Lauren Kahn, del Centro de Seguridad y Tecnología Emergente de Georgetown, resumió lo que muchos en la industria pensaban pero no querían decir: \u0026ldquo;No hay ganadores acá. Le deja un gusto amargo a todos.\u0026rdquo; Sam Altman, el CEO de OpenAI —competidor directo de Anthropic— dijo públicamente que no creía \u0026ldquo;que el Pentágono debería estar amenazando con la Ley de Producción de Defensa contra estas empresas\u0026rdquo;.\nMás de 330 empleados de Google y OpenAI firmaron una carta abierta titulada \u0026ldquo;We Will Not Be Divided\u0026rdquo;, pidiendo a sus líderes que \u0026ldquo;se unieran para seguir rechazando las demandas actuales del Departamento de Guerra de obtener permiso para usar nuestros modelos para vigilancia doméstica masiva y matar personas de forma autónoma sin supervisión humana\u0026rdquo;.\nel 5 de marzo, con la designación formal, se cierra el primer capítulo de una disputa que probablemente tenga muchos más.\nLas dos líneas que Anthropic no cruzó # Quiero detenerme un momento en el contenido del desacuerdo, porque es importante para entender la dimensión técnica del problema.\nLas dos excepciones que Anthropic mantuvo —vigilancia masiva doméstica y armas completamente autónomas— no son caprichosas. Son exactamente los dos casos donde la IA generativa de última generación amplifica de forma cualitativa, no solo cuantitativa, lo que ya era posible antes. Para la vigilancia: la capacidad de ensamblar datos dispersos en un perfil integro ya existía, pero requería esfuerzo humano o sistemas especializados. Un modelo de lenguaje poderoso lo hace a escala industrial, en tiempo real, sobre cualquier persona. Para las armas autónomas: la capacidad de tomar decisiones complejas en contextos de incertidumbre alta existe desde hace tiempo en software especializado, pero los modelos de frontera introducen una capa de razonamiento y adaptación que hace el problema cualitativamente diferente.\nLo que esto revela es una tensión que va a estar presente durante mucho tiempo: quién controla los límites de uso de una capacidad tecnológica que está integrada en sistemas críticos. El Pentágono sostiene que, si firmaron un contrato para usar una herramienta en misiones de defensa nacional, la empresa no debería poder dictar qué misiones están dentro o fuera del contrato. Anthropic sostiene que, si su tecnología puede ser usada para cosas que consideran incompatibles con valores democráticos, tienen tanto derecho como obligación de poner condiciones.\nNinguna de las dos posiciones es absurda. Y esa es, precisamente, la incomodidad. No es una disputa entre bueno y malo; es una disputa entre dos principios legítimos —la soberanía operacional de un Estado y la responsabilidad ética de quien construye la herramienta— que en este caso concreto colisionaron.\nLa pregunta que me queda de esto no es quién tiene razón. Es: ¿queremos un mundo donde los proveedores de modelos de IA que usamos tienen condiciones de uso que pueden entrar en conflicto con los intereses del gobierno del que dependemos, o de otros gobiernos? Y si la respuesta es \u0026ldquo;depende\u0026rdquo;, ¿cómo mapeamos ese riesgo?\nYa lo habíamos visto antes, aunque no lo llamábamos igual # Esta historia no es completamente nueva. La lógica de fondo —un proveedor que en un momento puede cambiar sus términos por razones completamente fuera de nuestro control— ya la discutimos antes, aunque con otros nombres y otros mecanismos.\nCuando escribí sobre las dependencias invisibles, el disparador era técnico: un paquete que cambiaba de licencia, una biblioteca que dejaba de mantenerse. El patrón era el mismo: construimos sobre algo que funciona, dejamos de mirarlo, y cuando cambia el costo llega junto.\nCuando escribí sobre la confianza como vulnerabilidad, el escenario era de seguridad: un atacante que usaba en su favor la confianza implícita que depositamos en software que nunca revisamos. La lección era que la confianza es a la vez nuestra fortaleza y nuestra fragilidad.\nCuando analicé los grandes apagones, el patrón era el mismo en los tres casos: una dependencia asumida sólida que colapsó de formas que nadie anticipó, y cuyo fallo se propagó mucho más lejos de lo que el diseño original preveía.\nLo que agrega esta saga es una dimensión que en todos esos casos estaba ausente: el riesgo no técnico, no de seguridad, sino político e institucional. Y esa dimensión siempre existió en la infraestructura tecnológica, pero en el ecosistema de los modelos de IA era prácticamente invisible. Porque los proveedores de modelos no son como los proveedores de nube: están en un campo que está siendo regulado y disputado geopolíticamente con una intensidad que los proveedores de infraestructura tradicional no enfrentaron, al menos no con esta velocidad.\nEl precedente que no queremos recordar # No llegamos a este momento sin historia previa. La idea de que los gobiernos puedan presionar o influir sobre el acceso a tecnología crítica no es nueva —lo nuevo es que la tecnología en cuestión son los modelos de IA que usamos en producción.\nA lo largo de las últimas décadas, varios episodios mostraron que cuando una empresa tecnológica alcanza posición dominante en infraestructura crítica, su relación con los gobiernos se complica de formas que nadie anticipó cuando la empresa era pequeña. Las revelaciones de 2013 sobre el programa PRISM —que documentó cómo la NSA accedía a datos de usuarios de las principales plataformas tecnológicas de EE.UU., en algunos casos con colaboración activa de las empresas y en otros a través de acceso compulsivo— mostraron que el Estado puede operar dentro de la infraestructura tecnológica de formas que ningún usuario o cliente corporativo había asumido. No hace falta tener certeza sobre los detalles de cada caso particular para reconocer el patrón general: cuando algo se vuelve infraestructura crítica, los gobiernos quieren tener algo que decir sobre cómo funciona.\nEl caso Huawei es otro ángulo del mismo problema, desde el lado opuesto: un proveedor de infraestructura de telecomunicaciones que fue bloqueado en múltiples mercados occidentales por razones de seguridad nacional, independientemente de la evidencia técnica específica sobre cada producto. Lo que importa aquí no es si el bloqueo fue justificado o no —eso es un debate para el que no tengo la información ni la especialidad— sino que mostró claramente que los mercados de infraestructura crítica pueden cerrarse por razones políticas con una velocidad que nadie que haya construido dependencias sobre ese proveedor anticipaba.\nLos modelos de IA están entrando en esa misma categoría, y lo están haciendo mucho más rápido de lo que les llevó a las plataformas de datos o a las empresas de telecomunicaciones. Y como casi siempre pasa, el problema se hace visible justo cuando la dependencia ya está construida y sería costoso deshacerla.\nLa nueva capa que falta en nuestros mapas de dependencias # Cuando mapeamos las dependencias de un sistema tecnológico, pensamos en capas: la base de datos, el proveedor de nube, las bibliotecas de software, las APIs externas. Cada capa puede fallar de formas técnicas conocidas: un bug, una caída de servicio, un cambio en la API.\nLo que la IA agrega —y que casi no aparece en esos mapas— es una capa nueva: el proveedor del modelo. Y ese proveedor tiene tres características que lo distinguen de cualquier capa de dependencia anterior.\nPrimero, el modelo no es intercambiable a costo bajo. Cambiar de Claude a GPT, o a un modelo abierto local, no es como cambiar de un servicio de almacenamiento a otro. Los comportamientos son distintos, los prompts hay que ajustarlos, los flujos que se construyeron asumiendo cierto estilo de respuesta pueden no funcionar igual. El costo de cambio es real, acumulativo, y casi nunca se mide antes de que sea necesario pagarlo.\nSegundo, el proveedor del modelo está sujeto a riesgos que los proveedores de infraestructura tradicional no enfrentan con la misma intensidad: regulación específica de IA que está cambiando en tiempo real, presión de múltiples gobiernos con intereses distintos, y posiciones éticas o comerciales que pueden hacerlos objeto de restricciones sin precedente. Esta semana lo vimos con Anthropic, pero OpenAI, Google y Microsoft no son inmunes al mismo tipo de presión —desde EE.UU., desde Europa con el AI Act, desde China para sus propias empresas.\nTercero, la dependencia de un modelo de IA no es solo técnica: es epistémica. Si construimos flujos de trabajo donde el modelo toma decisiones, genera contenido, analiza datos, y ese modelo deja de estar disponible o cambia de manera significativa, no solo perdemos un servicio: perdemos la capacidad de operar de la manera que aprendimos durante meses a operar. Esa pérdida no se recupera en un fin de semana.\nLa designación de Anthropic como supply chain risk tiene una consecuencia práctica inmediata que vale la pena entender: las empresas que fabrican productos o prestan servicios al Departamento de Defensa —que son muchas más de lo que parece en un primer vistazo— ahora deben certificar que no usan modelos de Anthropic. Esto no afecta directamente a quien no trabaja con el gobierno estadounidense, pero es la primera vez que el Estado puede, por decisión política, sacar a un proveedor de modelos del mercado de toda una categoría de clientes. Y si puede hacerlo con Anthropic en EE.UU., otros gobiernos pueden hacerlo con otros proveedores en otros mercados, por otras razones.\nEn los equipos donde me toca trabajar este tema, esta conversación aparece cada vez más seguido. No alcanza con preguntarnos qué modelo responde mejor, cuál es más barato o cuál tiene la ventana de contexto más grande. También tenemos que preguntarnos qué tan atados estamos a ese proveedor si mañana cambia sus condiciones, su disponibilidad, sus políticas de uso o queda alcanzado por una restricción externa.\nPor eso intento pensar las implementaciones de IA menos como una integración directa contra un modelo específico y más como una capa de agentes, procesos y memoria propia que pueda conectarse a distintos LLM según la necesidad. El objetivo no es abstraer la IA como si todos los modelos fueran iguales, porque no lo son. El objetivo es no construir procesos críticos alrededor de una dependencia que después no podamos reemplazar sin romper la forma en que trabajamos.\nLa objeción honesta # Antes de seguir, quiero nombrar el argumento en contra de todo lo que dije hasta acá, porque existe y es legítimo.\nLa saga Anthropic-Pentágono involucra a una empresa que tiene contratos directos con el Departamento de Defensa de los Estados Unidos por 200 millones de dólares. La mayoría de los equipos que usan Claude en producción no tienen ni remotamente esa exposición: usan la API para tareas internas, para asistentes de código, para análisis de datos. La probabilidad de que una restricción gubernamental afecte ese uso cotidiano en el corto plazo es baja.\nEso es verdad. Y sin embargo, hay dos razones por las que la historia importa más allá del caso específico.\nLa primera es que la designación de supply chain risk afecta a toda la cadena de proveedores del gobierno, no solo a los contratistas directos. Una empresa que hace software para una empresa que hace software para el Departamento de Defensa también puede verse afectada. Las cadenas de proveedores son largas y las dependencias son opacas, exactamente como veíamos con el post sobre las dependencias invisibles.\nLa segunda es más amplia: lo que importa de este episodio no es el resultado final de esta disputa específica —que puede resolverse en semanas o escalar durante meses— sino lo que revela sobre una categoría de riesgo que casi nadie había mapeado. El riesgo de que el proveedor de un modelo que usamos en producción sea restringido, presionado, o cambie sus términos por razones ajenas a la calidad del producto es real, existe independientemente de que involucre al Pentágono, y es un riesgo que la industria todavía no sabe bien cómo pensar.\nEl riesgo de sobrediversificar los proveedores de modelos también es real: mantener integraciones paralelas con múltiples modelos es costoso y puede introducir inconsistencias peores que la dependencia original. No es una receta para correr tres modelos en paralelo por las dudas. Es una invitación a hacerse la pregunta antes de construir la dependencia, no después.\nQué conviene hacerse antes de que el hipotético se vuelva concreto # Para los apagones de AWS y Cloudflare, escribí que la resiliencia no está en pretender que las caídas no van a pasar, sino en diseñar asumiendo que van a pasar. La lección análoga para este episodio es más incómoda porque el diseño tiene que anticipar no solo fallas técnicas sino también decisiones políticas.\nEl ejercicio que vale la pena hacer —y que la mayoría de los equipos no hace, igual que no mapeaba sus dependencias técnicas antes de que alguna se cayera— es simple: para los modelos que usamos en producción, ¿sabemos qué pasaría si mañana ese modelo deja de estar disponible? No hace falta tener un plan de contingencia detallado. Hace falta, al menos, haber pensado la respuesta una vez en frío. ¿El impacto es bajo, hay sustitutos razonables, el costo de cambio es manejable? Bien. ¿O la respuesta honesta es que no sabemos, que nunca lo pensamos, y que si eso pasara estaríamos a ciegas? Eso conviene saberlo antes de que alguien nos obligue a averiguarlo a las apuradas.\nHay un segundo plano de la pregunta que es más difícil. La dependencia de un modelo de IA no es solo \u0026ldquo;¿puedo cambiar de proveedor?\u0026rdquo;. Es también \u0026ldquo;¿sobre qué condiciones de uso construimos nuestros flujos de trabajo?\u0026rdquo;. Si los prompts, las integraciones, los comportamientos que asumimos están afinados para un modelo con un determinado perfil ético y de seguridad, y ese perfil cambia —porque el proveedor cedió ante una presión que nosotros no veíamos venir— ¿sabemos qué cambia en el sistema que construimos encima? Esa pregunta casi nunca aparece en las evaluaciones que hacemos antes de integrar un modelo.\nLo más honesto que puedo decir es que no tengo una respuesta práctica clara para esto. La industria está aprendiendo a pensar estas dependencias en tiempo real, al mismo tiempo que las construye. Lo que sí me parece claro es que el mapa de riesgos que usamos para evaluar proveedores de IA va a tener que crecer para incluir una dimensión que hoy casi no existe en él: no solo la calidad técnica, no solo el precio, no solo la disponibilidad, sino también la estabilidad institucional y el perfil de riesgo político del proveedor. No porque eso sea fácil de medir, sino porque esta semana quedó claro que ignorarlo no es gratis.\nLo que me queda de esta semana # Me resulta llamativo que la designación formal de hoy haya llegado casi sin sorpresa. El sector tecnológico venía siguiendo esta historia desde el 26 de febrero como si fuera inevitable, resignado a que el desenlace iba a ser este aunque nadie lo quisiera. Esa sensación de inevitabilidad me dice algo sobre cómo percibimos estas tensiones: las vemos venir, pero no tenemos todavía las herramientas conceptuales ni los procesos para responder antes de que escalen.\nLa paradoja que más me pesa de todo esto es la que subrayó el propio Amodei en su declaración: el Pentágono las dos cosas al mismo tiempo, que Anthropic es un riesgo para la cadena de suministro Y que Claude es esencial para la seguridad nacional. Una designación los pone afuera del mercado de contratistas del gobierno; la otra reconoce que sin Claude hay operaciones que se complican. Esa contradicción no es solo burocrática: es la contradicción de fondo de la IA como infraestructura crítica. Necesitamos estas capacidades; y precisamente porque las necesitamos, su control se vuelve objeto de disputa.\nEso va a seguir pasando, con Anthropic y con otros. Y cada vez que pase, la pregunta va a rebotar sobre todos los que construyeron dependencias sin haberla pensado antes.\n¿En sus equipos alguna vez evaluaron un proveedor de modelos de IA con la misma pregunta que harían sobre un servicio de nube crítico: qué pasa si mañana deja de estar disponible, o cambia los términos de forma que no controlamos? ¿Y si la respuesta es no, cuándo sería el mejor momento para hacerse esa pregunta: ahora, o cuando ya sea urgente?\nFuentes consultadas # Dario Amodei, \u0026ldquo;Statement from Dario Amodei on our discussions with the Department of War\u0026rdquo;, Anthropic, 26 de febrero de 2026. CNBC, \u0026ldquo;Anthropic faces lose-lose scenario in Pentagon conflict as deadline for policy change looms\u0026rdquo;, 27 de febrero de 2026. (Fuente de las citas de Amodei, Parnell, Michael, Kahn y Altman.) Politico, \u0026ldquo;Pentagon formally designates Anthropic a supply-chain risk\u0026rdquo;, 5 de marzo de 2026. WVIA / NPR, \u0026ldquo;Pentagon labels AI company Anthropic a supply chain risk\u0026rdquo;, 5 de marzo de 2026. ethixbase360, \u0026ldquo;Compliance Implications of Anthropic\u0026rsquo;s Dispute with the Pentagon\u0026rdquo;. (Contexto de la operación Venezuela/Maduro como detonante del conflicto.) ","date":"7 de marzo de 2026","externalUrl":null,"permalink":"/blog/post-cuando-el-proveedor-es-el-riesgo/","section":"Blog","summary":"Hoy el Pentágono formalizó lo que venía amenazando desde la semana pasada: designó a Anthropic como ‘supply chain risk’, una etiqueta que históricamente se reservaba para empresas de países adversarios, nunca para una empresa estadounidense. Lo que en apariencia es una disputa político-militar sobre IA tiene una dimensión más cercana y más incómoda: muchos equipos técnicos construyeron dependencias sobre modelos de Anthropic sin haber pensado siquiera una vez en este tipo de escenario. Y el problema no es Anthropic en particular: es que empezamos a mapear una categoría de riesgo que casi no existía hace tres años.","title":"Cuando el proveedor es el riesgo: lo que la saga Anthropic-Pentágono nos dice sobre dependencias que no veíamos","type":"blog"},{"content":"","date":"7 de marzo de 2026","externalUrl":null,"permalink":"/tags/dependencias/","section":"Tags","summary":"","title":"Dependencias","type":"tags"},{"content":"","date":"7 de marzo de 2026","externalUrl":null,"permalink":"/tags/geopolitica/","section":"Tags","summary":"","title":"Geopolitica","type":"tags"},{"content":"","date":"7 de marzo de 2026","externalUrl":null,"permalink":"/tags/resiliencia/","section":"Tags","summary":"","title":"Resiliencia","type":"tags"},{"content":"","date":"14 de febrero de 2026","externalUrl":null,"permalink":"/tags/cultura-de-equipo/","section":"Tags","summary":"","title":"Cultura-De-Equipo","type":"tags"},{"content":"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ó: \u0026ldquo;¿cuál arrancamos a evaluar primero?\u0026rdquo;. Y me di cuenta de que la pregunta que yo tenía en la cabeza era otra: ¿cuál no evaluamos todavía?\nHay 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 \u0026ldquo;eso no lo evaluamos todavía\u0026rdquo; 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.\nPero 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.\nLa 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.\nLa 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 \u0026ldquo;novedad\u0026rdquo; y \u0026ldquo;práctica estándar\u0026rdquo; se cerró a meses lo que antes llevaba años. El que espera demasiado llega tarde. El que no espera nada se ahoga.\nPero 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.\nHay 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.\nLo 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.\nQué significa, en concreto, decir que no # Quiero ser preciso aquí, porque \u0026ldquo;decir que no\u0026rdquo; 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.\nEn términos concretos, toma tres formas que se solapan pero que conviene separar.\nLa 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 \u0026ldquo;¿esto es interesante?\u0026rdquo; —casi todo lo que circula en el campo lo es— sino \u0026ldquo;¿el problema que resuelve esta herramienta es el problema que tenemos nosotros, hoy?\u0026rdquo;. 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.\nLa 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 \u0026ldquo;es difícil decirle que no al negocio\u0026rdquo; o porque \u0026ldquo;no quiero que piensen que el equipo no puede\u0026rdquo; 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.\nLa 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.\nEl 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.\nEsa 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é.\nLo 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.\nLa objeción honesta # Antes de seguir, quiero nombrar el riesgo del argumento contrario, porque existe y es legítimo. Hay una versión de \u0026ldquo;decir que no\u0026rdquo; que no es sabiduría táctica sino miedo disfrazado de criterio. Un equipo que rechaza evaluar todo lo nuevo porque \u0026ldquo;ya tenemos lo que necesitamos\u0026rdquo; o porque \u0026ldquo;esto también va a pasar\u0026rdquo; 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.\nLa 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 \u0026ldquo;no evaluamos esto ahora porque estamos priorizando X, y cuando terminemos X lo revisamos\u0026rdquo; está tomando una decisión activa. Un equipo que dice \u0026ldquo;no evaluamos esto porque no nos parece\u0026rdquo; —o peor, porque nadie tiene tiempo de discutirlo— está siendo pasivo aunque suene a decisión.\nDecir 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.\nCó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.\nPrimero, 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.\nSegundo, 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.\nTercero, hacer explícito el criterio de evaluación. No \u0026ldquo;¿es buena esta herramienta?\u0026rdquo; sino \u0026ldquo;¿resuelve el problema que tenemos, en el contexto en que estamos, con los recursos disponibles?\u0026rdquo;. La diferencia es entre una evaluación abstracta y una evaluación situada. Y solo las evaluaciones situadas terminan en decisiones reales.\nEl 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.\nLo 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.\n¿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?\nFuentes consultadas # OpenAI, \u0026ldquo;Introducing the Codex app\u0026rdquo;, 2 de febrero de 2026. También cubierto por Reuters y CNBC. Simon Willison, \u0026ldquo;Tom Dale on AI and developer wellbeing\u0026rdquo;, 6 de febrero de 2026. Con referencia al tweet original de Tom Dale. Margaret-Anne Storey, \u0026ldquo;How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt\u0026rdquo;, Universidad de Victoria, 9 de febrero de 2026. Martin Fowler, fragmento sobre deuda cognitiva, martinfowler.com, 13 de febrero de 2026. ","date":"14 de febrero de 2026","externalUrl":null,"permalink":"/blog/post-decir-que-no-habilidad-tecnica/","section":"Blog","summary":"Febrero de 2026 llegó con otra explosión de herramientas: agentes de coding, un nuevo cliente para trabajar con IA, actualizaciones que en otro año hubieran sido la noticia del trimestre. Pero debajo del ruido hay una habilidad que casi nunca se enseña y que pocas veces se nombra: la de decir que no. No por miedo a lo nuevo, sino porque elegir qué entra en nuestra atención y en la de nuestro equipo es, quizás, uno de los actos de liderazgo técnico más difíciles y más valiosos que existe.","title":"Decir que no como habilidad técnica","type":"blog"},{"content":"","date":"14 de febrero de 2026","externalUrl":null,"permalink":"/tags/liderazgo/","section":"Tags","summary":"","title":"Liderazgo","type":"tags"},{"content":"","date":"27 de enero de 2026","externalUrl":null,"permalink":"/tags/adopcion-tecnologica/","section":"Tags","summary":"","title":"Adopcion-Tecnologica","type":"tags"},{"content":"Empieza 2026 y la conversación sobre los agentes de IA cambió de tono. Durante un par de años fue pura promesa y entusiasmo; ahora llegaron los primeros números en serio, y son crudos. Los informes que se publicaron este mes coinciden en algo incómodo: la enorme mayoría de los proyectos de IA agéntica no está llegando a producción. Muchos pilotos, poca realidad. Y lo que más me llamó la atención no es el dato en sí, que era esperable, sino la explicación unánime que dan los analistas: el problema no es la tecnología. Los modelos funcionan, y funcionan muy bien. Lo que falla es todo lo demás —el contexto, la integración, el rediseño de los procesos, el criterio para gobernar lo que se delega—. Y al leer eso sentí algo raro, una mezcla de validación y de desconcierto, porque es casi exactamente lo que escribí en este blog hace más de un año, cuando los agentes eran apenas una promesa. No lo traigo para sacar pecho, que sería de mal gusto y además poco interesante. Lo traigo porque me parece que, si el camino se veía venir desde un simple blog de reflexión, vale la pena preguntarse cómo lo torcemos para que los agentes de verdad funcionen. De eso quiero hablar.\nLos números que abrieron el año # Pongamos sobre la mesa lo que dicen los informes, sin dramatizar, porque los datos hablan solos. Gartner proyectó este mes que más del 60% de las primeras implementaciones de orquestación de agentes no van a cumplir las expectativas de costo o rendimiento hacia 2030, porque las empresas están subestimando lo que hace falta para que funcionen: integración, gobernanza, talento. La misma consultora venía anticipando que cerca del 40% de los proyectos agénticos se cancelarían para 2027. Deloitte reportó que, si bien casi cuatro de cada diez organizaciones están haciendo pruebas piloto con IA agéntica, apenas algo más de una de cada diez logró llevarla a producción de verdad. Y un estudio del MIT que dio que hablar mostró que la abrumadora mayoría de estas pruebas pilotos de IA generativa no entrega ningún retorno medible.\nSon números grandes, y conviene leerlos con cuidado para no caer ni en el pánico ni en la negación. No dicen que la IA agéntica sea humo; dicen que hay un abismo enorme entre la prueba de concepto que impresiona en una demo y el sistema que funciona, confiable, en producción, día tras día. Es la distancia entre \u0026ldquo;miren lo que puede hacer\u0026rdquo; y \u0026ldquo;esto sostiene una parte del negocio sin romperse\u0026rdquo;. Y esa distancia, lejos de ser un problema nuevo, es la más vieja de nuestra industria. Lo nuevo es la velocidad con la que el entusiasmo nos hizo olvidar que existía.\nPero el dato más revelador, el que de verdad importa, es el del diagnóstico. Cuando los analistas se preguntan por qué fallan estos proyectos, la respuesta es sorprendentemente unánime y sorprendentemente poco técnica. McKinsey señaló que cerca del 80% de las organizaciones simplemente está apilando IA encima de procesos viejos, diseñados por humanos para humanos, en lugar de repensar cómo debería fluir el trabajo. Es decir: tomamos un proceso pensado para personas, le pegamos un agente arriba, y nos sorprendemos cuando no anda. El problema no está en el modelo. Está en que le pedimos que opere en un mundo que nadie rediseñó para él.\nLo que escribíamos acá, hace más de un año # Y acá viene la parte que me dejó pensando, y por la que quería escribir este post. Porque todo esto —que el problema no sería la inteligencia del modelo sino el contexto, que automatizar no es lo mismo que delegar, que el agente no entiende la empresa por defecto— no es una revelación de 2026. Es, casi palabra por palabra, lo que escribí en noviembre de 2024, cuando los agentes recién empezaban a dejar de responder y empezaban a hacer cosas, y lo que retomé a mediados de 2025, cuando ya trabajaban de verdad.\nEn aquel primer post sobre agentes titulé una sección con una frase que hoy me resulta casi profética, y lo digo con más perplejidad que orgullo: \u0026ldquo;el agente no entiende tu empresa por defecto\u0026rdquo;. Escribía que un agente puede ser capaz de usar herramientas sin que eso signifique que entiende el contexto de una organización: no sabe qué cliente es crítico, qué proceso tiene excepciones históricas, qué parte del sistema está en migración, qué deuda técnica el equipo decidió tolerar a propósito. Puede saberlo si se lo damos, puede respetarlo si lo definimos, pero no lo adivina. Decía también que automatizar no es delegar responsabilidad, que actuar rápido no siempre es actuar bien, y que los agentes necesitan barandas: permisos, límites, trazabilidad, revisión, reversibilidad. Y a mediados de 2025, cuando los agentes empezaron a trabajar en serio, insistí en que cuanto más capaz se volvía el agente, más fino tenía que ser el arnés con que lo conducimos, no menos.\nReleo todo eso hoy, a la luz de los informes de este mes, y la correspondencia es casi exacta. Los proyectos están fallando justamente por donde decíamos que iban a tensionarse: falta de contexto, ausencia de rediseño, confusión entre automatizar y delegar, expectativa de que el agente entienda solo un mundo que nadie le explicó. Lo que en 2024 era una intuición razonada, en 2026 es un dato de consultora con porcentajes.\nLo raro no es que pasara; es que no lo vieran venir # Y acá está lo que de verdad me inquieta, y que digo con toda la humildad del caso. Si yo, desde un blog personal de reflexión, sin acceso a estudios de mercado ni a datos privilegiados, escribiendo en mis ratos para pensar en voz alta, podía anticipar más o menos por dónde iban a venir los problemas\u0026hellip; ¿cómo es que los monstruos de la industria, las empresas con miles de ingenieros y presupuestos enormes, parecen no haberlo visto venir? ¿Cómo se invirtieron fortunas en proyectos agénticos sin haber resuelto primero las preguntas básicas que cualquiera que haya estado en producción se hace casi por reflejo?\nNo lo digo desde la soberbia, porque no tiene ningún mérito especial: las cosas que escribí no eran genialidades, eran sentido común de oficio, lo que sabe cualquiera que haya visto fracasar automatizaciones por falta de contexto. Y justamente por eso me desconcierta. La respuesta, creo, no es que la industria sea tonta —no lo es— sino que el entusiasmo colectivo tiene una capacidad asombrosa de hacernos olvidar lo que ya sabíamos. Cuando una tecnología deslumbra, baja la guardia crítica. La presión por no quedarse atrás empuja a lanzarse sin hacerse las preguntas incómodas. El FOMO, ese miedo a perderse la ola, es un pésimo consejero técnico. Y así, empresas que tienen de sobra el conocimiento para anticipar estos problemas igual se lanzaron de cabeza, porque el costo de parecer lento se sentía, en el momento, más caro que el costo de fallar.\nHay algo casi tranquilizador, y a la vez aleccionador, en darse cuenta de esto. Tranquilizador, porque confirma que el criterio de oficio —pensar despacio, hacerse las preguntas básicas, no dejarse arrastrar por el ruido— tiene un valor real, incluso frente a recursos enormes. Y aleccionador, porque muestra lo fácil que es, para cualquiera, perder ese criterio cuando la corriente del entusiasmo aprieta. No es un problema de inteligencia ni de recursos. Es un problema de no dejar que la prisa nos haga saltear lo que ya sabíamos.\nPero no vine a decir \u0026ldquo;te lo dije\u0026rdquo; # Sería muy fácil, y muy estéril, quedarme acá, en el \u0026ldquo;lo veíamos venir\u0026rdquo;. El \u0026ldquo;te lo dije\u0026rdquo; es cómodo y no construye nada. Lo que me interesa de verdad es lo otro: si el camino se veía venir, entonces también se ve venir cómo cambiarlo. Si sabemos por qué fallan, sabemos —al menos en parte— cómo hacer que funcionen. Y esa es una noticia profundamente optimista, no pesimista, porque significa que el problema está a nuestro alcance. No dependemos de que los modelos mejoren todavía más; los modelos ya son extraordinarios. Dependemos de cosas que sí controlamos: cómo los integramos, qué contexto les damos, cómo rediseñamos el trabajo alrededor de ellos.\nPorque eso es lo que estos informes, leídos con optimismo, en realidad están diciendo. Si el 80% de los fracasos viene de apilar IA sobre procesos viejos sin rediseñarlos, entonces el camino al éxito no es un misterio tecnológico: es rediseñar los procesos. Si el problema es la falta de contexto, la solución es darle contexto. Si el problema es confundir automatizar con delegar, la solución es no confundirlos. Ninguna de esas cosas requiere esperar al próximo modelo. Todas están en la cancha de quienes lideramos tecnología, hoy, con lo que ya existe. El reality check de los agentes no es el fin de la promesa; es la hoja de ruta de cómo cumplirla, escrita en negativo.\nCómo torcer el rumbo: rediseñar, no apilar # Si tuviera que quedarme con una sola idea de todo este aprendizaje colectivo, sería esta: los agentes no funcionan apilados sobre lo viejo; funcionan cuando rediseñamos el trabajo para ellos. Y rediseñar no significa tirar todo, sino preguntarse de nuevo, con honestidad, cómo debería fluir un proceso si parte del trabajo lo va a hacer un agente. Un proceso pensado para que lo ejecute una persona tiene pasos, controles, supuestos y atajos que solo tienen sentido para una persona. Pegarle un agente arriba, esperando que se acomode a un molde que no es el suyo, es pedirle que fracase con elegancia.\nEsto conecta con algo que vengo diciendo desde hace rato y que cada vuelta confirma: la calidad de lo que obtenemos de la IA depende, sobre todo, de la calidad del contexto y de la estructura que le damos. Un agente potente en un proceso bien rediseñado, con contexto claro, límites definidos y puntos de control humanos donde importan, puede ser transformador. El mismo agente, sobre un proceso heredado, mal documentado, lleno de excepciones que viven en la cabeza de alguien, va a tropezar una y otra vez. La diferencia entre el proyecto que llega a producción y el que muere en piloto rara vez está en el modelo elegido. Está en cuánto trabajo de oficio —rediseño, contexto, gobernanza— hicimos alrededor de él antes de soltarlo.\nY acá vuelven, intactas, las barandas y el arnés de los que escribí antes, pero con un sentido nuevo. Antes las planteaba sobre todo como protección, para que el agente no hiciera daño. Ahora veo que son también condición de éxito, no solo de seguridad. Un agente con permisos claros, contexto rico, puntos de revisión bien puestos y trazabilidad no es solo un agente más seguro: es un agente que efectivamente funciona, que llega a producción, que entrega valor sostenido. La disciplina que parecía un freno resulta ser, en realidad, el motor. Los proyectos que se saltearon esa disciplina por ir rápido son, justamente, los que hoy engrosan las estadísticas de fracaso.\nEl modelo mental equivocado: el \u0026ldquo;empleado digital\u0026rdquo; # Quiero detenerme en algo más profundo que creo que está en la raíz de muchos de estos fracasos, y que tiene que ver con cómo pensamos a los agentes antes incluso de implementarlos. Buena parte del entusiasmo agéntico se vendió con una metáfora seductora: el agente como \u0026ldquo;empleado digital\u0026rdquo;, una especie de trabajador incansable al que le delegás una tarea y la hace de punta a punta, como lo haría una persona pero más rápido y más barato. Esa metáfora es atractiva y, creo, parte del problema, porque nos lleva a esperar de los agentes algo que todavía no son y a diseñar para ellos como si fueran lo que no son.\nUn empleado humano, incluso uno nuevo, trae consigo algo que un agente no tiene: sentido común, capacidad de detectar cuándo algo está raro, el reflejo de preguntar antes de hacer una macana, una comprensión implícita del contexto de la organización que absorbió sin que nadie se la explicara del todo. Cuando le pedimos a un agente que sea un \u0026ldquo;empleado digital\u0026rdquo; y lo soltamos a operar como si tuviera todo eso, descubrimos rápido que no lo tiene. No es menos inteligente que un humano en lo suyo; es inteligente de otra manera, y esa diferencia importa muchísimo a la hora de diseñar. El agente ejecuta brillantemente dentro de lo que entiende, y se equivoca con seguridad y a gran velocidad fuera de eso, sin el reflejo humano de frenar ante la duda.\nPor eso me parece más útil pensar a los agentes no como empleados digitales que reemplazan personas, sino como una capa nueva y poderosa que amplifica el trabajo de un equipo que sabe lo que hace. El agente no viene a reemplazar el criterio; viene a ejecutar a escala las decisiones de quien sí lo tiene. Las organizaciones que lo entienden así —que ponen al agente a potenciar a su gente en vez de a sustituirla— son las que están sacando valor real. Las que compraron la fantasía del trabajador autónomo que se las arregla solo son, en buena medida, las que hoy figuran en las estadísticas de casos pilotos que nunca llegaron a producción. La metáfora con la que pensamos una tecnología condiciona cómo la implementamos, y \u0026ldquo;empleado digital\u0026rdquo; fue, creo, una metáfora que prometió de más y preparó el terreno para la desilusión.\nHay una recomendación que di en 2024 y que el reality check de 2026 vuelve a validar: conviene empezar por lo acotado y de bajo riesgo, no por lo crítico. Mucho del fracaso que muestran los informes viene de organizaciones que, deslumbradas, apuntaron sus agentes directamente a procesos centrales y complejos, y se estrellaron contra toda la complejidad de golpe. El que en cambio empezó por tareas delimitadas, reversibles, donde un error no era catastrófico, pudo aprender cómo se comporta el agente, calibrar el contexto, ajustar los límites, ganar confianza de a poco, y recién entonces escalar hacia lo importante.\nNo es una estrategia tímida; es una estrategia inteligente. La madurez con los agentes, igual que con cualquier tecnología poderosa, no está en automatizar lo más posible lo más rápido posible, sino en saber qué delegar, con qué arnés, en qué momento. Las organizaciones que entendieron esto —ese 11% que llegó a producción, ese puñado que la está sacando barata— casi siempre son las que fueron pacientes, las que hicieron el trabajo poco glamoroso de rediseñar y dar contexto, las que resistieron la tentación de soltar un agente potente sobre lo crítico solo porque la demo impresionaba. La paciencia con criterio, que nunca consigue aplausos en el momento del hype, es la que aparece en las estadísticas de éxito un par de años después.\nLo que me deja este arranque de año # Termino donde quería llegar desde el principio. El reality check de los agentes no me deja una sensación de derrota ni de \u0026ldquo;se los dije\u0026rdquo;; me deja, sobre todo, una confirmación esperanzadora. Confirmación de que el criterio de oficio —pensar despacio, hacerse las preguntas básicas, no dejarse arrastrar por el ruido— sigue valiendo, y mucho, incluso frente a recursos enormes. Y esperanzadora porque el diagnóstico, lejos de ser una condena, es una hoja de ruta: sabemos por qué fallan los proyectos agénticos, y eso significa que sabemos, en buena medida, cómo hacerlos funcionar. No hace falta esperar magia tecnológica; hace falta hacer el trabajo que ya sabíamos que había que hacer.\nEra posible un camino como este. Era posible anticipar, desde la reflexión y el oficio, que los agentes iban a fallar no por falta de inteligencia sino por falta de contexto y rediseño. Y si era posible verlo venir, también es posible dar el volantazo. Los agentes no son una promesa incumplida; son una promesa que recién ahora, después del primer golpe de realidad, empezamos a saber cómo cumplir. Los que entiendan que el trabajo está en el rediseño y el contexto, no en el próximo modelo, van a ser los que en un par de años miren para atrás y vean que valió la pena la paciencia.\nLes dejo, para arrancar el año, una pregunta para llevarse al propio equipo. Si los proyectos agénticos fracasan sobre todo por apilarse encima de procesos que nadie rediseñó, la próxima vez que vayamos a sumar un agente a nuestro trabajo, ¿vamos a preguntarnos primero cómo debería fluir ese proceso si parte del trabajo lo hace una máquina, o vamos a pegarle el agente arriba a lo que ya teníamos y esperar que la magia ocurra sola? Porque a esta altura ya lo sabemos, y lo sabíamos desde antes: la magia, cuando ocurre, casi siempre es el nombre que le ponemos al trabajo que alguien se tomó en serio.\nFuentes consultadas # Gartner, predicciones sobre IA agéntica, enero de 2026 (más del 60% de las implementaciones de orquestación agéntica no cumplirán expectativas hacia 2030; ~40% de proyectos cancelados para 2027). Deloitte, State of AI in the Enterprise (datos sobre brecha entre pilotos y producción), 2026. MIT NANDA Initiative, The GenAI Divide (95% de los pilotos de IA generativa sin ROI medible), 2025. McKinsey, State of AI (organizaciones que apilan IA sobre procesos legacy sin rediseñar), 2025-2026. ","date":"27 de enero de 2026","externalUrl":null,"permalink":"/blog/post-2026-agentic-reality-check/","section":"Blog","summary":"Arranca 2026 y los números son contundentes: la mayoría de los proyectos agénticos no llega a producción, y los analistas coinciden en que el problema no es la tecnología sino la forma en que la usamos. Lo curioso es que esto ya lo habíamos pensado acá, en un blog de reflexión, hace más de un año. No para decir ’te lo dije’, sino para preguntarnos algo más útil: si el camino se veía venir, ¿cómo lo torcemos para aprovechar de verdad lo que estos agentes pueden dar?","title":"El agente que sí funciona: lo que veníamos diciendo se está materializando","type":"blog"},{"content":"","date":"27 de enero de 2026","externalUrl":null,"permalink":"/tags/gestion-de-equipos/","section":"Tags","summary":"","title":"Gestion-De-Equipos","type":"tags"},{"content":"Hace un año cerraba 2024 diciendo que la IA había dejado de ser una novedad para empezar a pedir madurez. Lo escribí con cierta esperanza, sin saber bien qué iba a traer el año siguiente. Ahora, mirando 2025 desde el final, creo que puedo ponerle nombre a lo que pasó: fue el año en que la IA se volvió plural. Dejó de ser un puñado de modelos caros, hechos por unos pocos laboratorios occidentales, a los que accedíamos casi como suplicantes. Se multiplicó. Muchos modelos, de muchos orígenes, en muchas geografías, a muchos precios, con muchas filosofías detrás. Y esa abundancia, que es una noticia extraordinaria, trajo un efecto que no siempre se nota en medio del entusiasmo: cuando hay tanto para elegir, lo escaso deja de ser la tecnología y pasa a ser el criterio para elegirla. El año empezó, en enero, con un modelo que nos gritó \u0026ldquo;tus certezas eran supuestos\u0026rdquo;, y termina con un mundo tan lleno de opciones que el verdadero diferencial ya no es a qué herramienta accedés, sino con qué juicio la usás. De ese hilo quiero tirar para hacer el balance, porque creo que ata casi todo lo que vivimos este año.\nEl año en que dejamos de poder seguirles el ritmo # Lo primero que define a 2025, para cualquiera que trabaje cerca de esto, es una sensación física de vértigo. La cantidad de modelos, versiones, mejoras y lanzamientos fue, sencillamente, imposible de seguir. Arrancó en enero con la irrupción que ya comenté en su momento, y a partir de ahí no paró: familias enteras de modelos saliendo y actualizándose, capacidades que escalaban mes a mes, anuncios que hace dos años habrían sido la noticia del año y que en 2025 duraban un titular de una semana. Hubo un momento, en algún punto del año, en que dejé de intentar probar todo lo que salía. No por desinterés, sino por imposibilidad. Y esa rendición, lejos de angustiarme, me resultó clarificadora.\nPorque cuando uno ya no puede probar todo, se ve forzado a hacer algo que en realidad siempre debió hacer: elegir con criterio en lugar de perseguir la novedad. La abundancia mata la estrategia de \u0026ldquo;estar al día con todo\u0026rdquo;, que nunca fue una estrategia sino una ansiedad disfrazada. Y la reemplaza por una pregunta más madura: dado todo esto que existe, ¿qué necesito yo, para qué, y cómo elijo bien? Es la misma idea que desarrollé a mitad de año cuando hablé de elegir el modelo correcto y no el más grande, pero llevada a una escala nueva. Ya no se trata solo de no usar el cañón para matar una mosca; se trata de que ahora hay cien cañones de distintos tamaños, orígenes y precios, y la habilidad que importa es saber cuál levantar para cada cosa. La tecnología se volvió abundante; el criterio para navegarla, escaso. Y lo escaso, como sabe cualquiera, es lo que vale.\nNo solo más modelos: también más baratos # Hay una cara de la pluralización que se comenta menos que la cantidad de modelos, y que para quien lidera tecnología en una empresa es tal vez la más importante: el precio. A medida que se multiplicaron las opciones, el costo de usar IA se desplomó. Lo que hace dos años era un lujo reservado a quien podía pagar tarifas altas, este año se volvió, en muchos casos, casi una commodity. Modelos capaces a una fracción del precio de hace un año, alternativas abiertas que corren sobre infraestructura propia sin pagarle a nadie por consulta, competencia feroz empujando los precios hacia abajo en todos los segmentos.\nEsto cambia la conversación de una manera concreta. Cuando la IA era cara, la pregunta era \u0026ldquo;¿nos lo podemos permitir?\u0026rdquo;. Ahora que se abarató tanto, la pregunta pasó a ser otra, más interesante y más exigente: \u0026ldquo;¿lo estamos usando bien?\u0026rdquo;. Porque cuando algo es barato, la tentación es usarlo de cualquier manera, sin pensar, tirándole modelos a todos los problemas porque total sale poco. Y ahí vuelve, una vez más, la idea que sostuve todo el año: que el costo bajo no es una excusa para abandonar el criterio, sino justamente lo contrario. Cuando elegir mal ya no se castiga con una factura alta, es más fácil elegir mal sin darse cuenta. La abundancia barata es cómoda y, por eso mismo, un poco peligrosa: nos invita a dejar de pensar. El abaratamiento es una bendición para quien tiene criterio y una trampa para quien no lo tiene, porque le saca el único freno que lo obligaba a elegir con cuidado.\nOriente cambió el mapa, y lo hizo abriendo # El cambio geopolítico más grande del año, y el que menos se vio venir, fue el peso que ganó Oriente, y la forma en que lo ganó: abriendo. Empezó en enero, con un modelo chino que no solo se acercó al rendimiento de los mejores, sino que se publicó con una licencia permisiva, descargable, modificable. Esa decisión, que en su momento analicé como una sacudida a nuestras certezas, terminó siendo algo más grande: inspiró a una cantidad de laboratorios, sobre todo chinos, a abrir sus propios modelos. Lo que era una rareza pasó a ser una corriente.\nEl dato que mejor resume el giro es uno que me dejó pensando: durante este año, las descargas de modelos abiertos pasaron de estar dominadas por Estados Unidos a estar dominadas por China. No hablo de uso de productos cerrados ni de quién tiene el modelo más potente del mundo —esa sigue siendo una discusión abierta— sino de algo más concreto y más revelador: dónde se está construyendo, sobre qué base, con qué herramientas. Y la respuesta, cada vez más, apunta al este. El open source dejó de ser, como era hace apenas un par de años, \u0026ldquo;la opción para quien necesita privacidad o quiere afinar un modelo para su caso\u0026rdquo;. Se volvió competitivo de verdad, una elección legítima para equipos que necesitan control de costos, despliegues sobre su propia infraestructura, o simplemente no depender de un proveedor que puede cambiar las reglas cuando quiera.\nPara alguien que lidera tecnología, esto es más que una curiosidad geopolítica. Es una pregunta práctica sobre dependencia, que es un tema que vengo masticando todo el año. Cuando los modelos abiertos y capaces se multiplican, la decisión de atarse a un proveedor cerrado deja de ser la única opción razonable y pasa a ser, justamente, una decisión: con sus ventajas, sus comodidades y sus riesgos. No digo que lo abierto sea mejor que lo cerrado en abstracto; digo que 2025 nos devolvió la posibilidad real de elegir, y con ella, la responsabilidad de elegir con conciencia en lugar de por inercia.\nEuropa jugó otro partido # Mientras Oriente abría y Estados Unidos, tras un giro político, empujaba hacia la desregulación y la velocidad, Europa eligió jugar un partido distinto, y vale la pena mirarlo sin el desdén con que a veces se la trata. La apuesta europea del año tuvo dos patas. Por un lado, la soberanía: la idea de no depender de infraestructura ni de modelos ajenos, encarnada sobre todo en una empresa francesa que apostó a modelos más eficientes y a pesos abiertos, y en una iniciativa de inversión pública grande para construir capacidad de cómputo propia. Por el otro, la regulación: el AI Act siguió su curso, con las primeras prohibiciones entrando en vigor a principios de año, las reglas para los modelos de propósito general aplicándose desde agosto, y hacia fin de año un movimiento para simplificar la implementación, reconociendo que regular sin asfixiar la innovación es un equilibrio difícil.\nEs fácil, desde la lógica de la velocidad, ver a Europa como la que llega tarde, la que regula de más, la que se queda mirando mientras otros corren. Pero creo que esa lectura es perezosa. Europa está haciendo una apuesta legítima y profunda: que la forma en que se construye la tecnología importa tanto como la tecnología misma, que la soberanía sobre la infraestructura crítica es un valor estratégico, y que la velocidad sin reglas tiene un costo que se paga después. No sé si va a funcionar; las apuestas a la soberanía tecnológica son caras, lentas y políticamente frágiles. Pero la pregunta que plantea Europa es la correcta, y es una que cualquiera que lidere tecnología debería hacerse en su escala: ¿de quién dependo, qué control conservo, y qué estoy dispuesto a sacrificar en velocidad a cambio de no quedar atado? Es, otra vez, el mismo dilema de las dependencias, ahora a escala continental.\nY desde el sur, hola! # Llego al bloque que más me cuesta escribir, porque es el que más me toca, aunque no este fisicamente en la actualidad, por tiempo y vivencias es al que pertenezco culturalmente: dónde está parada América Latina en todo esto. Y voy a ser honesto, porque la honestidad es lo único que hace útil a un balance. El año dejó un retrato de la región tan entusiasta como incómodo, y los números lo cuentan mejor que cualquier opinión mía.\nSegún el índice latinoamericano de IA que se presentó este año, la región produce alrededor del 6,6% del PIB mundial pero atrae apenas algo más del 1% de la inversión global en inteligencia artificial. Y al mismo tiempo —acá está la paradoja que no me puedo sacar de la cabeza— concentramos cerca del 14% de las visitas globales a herramientas de IA, siendo solo el 11% de los usuarios de internet del mundo. Leído junto, el retrato es nítido: usamos la IA con muchísimo entusiasmo, más que el promedio, y la producimos muy poco. Somos consumidores ávidos de una tecnología que se construye, casi toda, en otro lado. El director del centro que elaboró el índice lo resumió con una frase que me quedó grabada: \u0026ldquo;hay interés pero poca urgencia\u0026rdquo;. Y creo que captura algo profundo de cómo nos paramos frente a casi todo lo tecnológico en la región.\nNo quiero caer en el lamento, que es cómodo y estéril, ni tampoco en el optimismo de folleto. La región tiene focos reales de talento y de investigación, sobre todo en algunos países que vienen invirtiendo en serio, y un entusiasmo de base que no es poca cosa. Pero la estructura es la que es: investigación concentrada en dos o tres países, inversión muy por debajo del promedio mundial en relación a nuestro tamaño, infraestructura de cómputo escasa y desigual, estrategias nacionales que muchas veces son declaraciones sin presupuesto ni ejecución. Somos, en buena medida, una región que adopta lo que otros crean, y eso tiene una consecuencia que conecta directo con todo lo que escribí este año: nos vuelve profundamente dependientes. Dependientes de modelos que no controlamos, de infraestructura que está en otro hemisferio, de decisiones que se toman sin pensar en nosotros.\nPero hay algo en esa misma posición que, mirado con honestidad, no es solo debilidad. Si la IA se volvió plural y abierta, si hay modelos capaces que se pueden descargar y adaptar, si lo escaso ya no es el acceso a la tecnología sino el criterio para usarla, entonces la distancia entre crear y aprovechar se acortó. Una región que no puede construir los modelos de frontera sí puede, en cambio, ser muy buena eligiéndolos, adaptándolos, aplicándolos a sus problemas reales, formando gente que sepa usarlos con juicio. No es lo mismo que liderar la creación, no me hago ilusiones. Pero en un mundo donde el criterio es lo escaso, ser bueno en criterio es una forma de jugar el partido, no de mirarlo desde afuera. La pregunta para quienes lideramos tecnología desde el sur no es \u0026ldquo;¿cómo competimos creando modelos de frontera?\u0026rdquo;, porque esa carrera la tenemos perdida por ahora. Es \u0026ldquo;¿cómo nos volvemos extraordinariamente buenos eligiendo y aplicando lo que el mundo está abriendo?\u0026rdquo;. Esa carrera sí la podemos correr.\nEl año también pasó por las personas # Hasta acá hablé de modelos, geografías y precios, pero sería un balance incompleto si no mirara lo que pasó del lado humano, porque buena parte de lo que escribí este año terminó siendo, en el fondo, sobre personas y no sobre máquinas. Fue el año en que la conversación sobre qué le pasa a los equipos con todo esto dejó de ser teórica. La pregunta de qué significa para alguien que recién empieza aprender a programar en un mundo donde la IA le resuelve medio trabajo. La pregunta de cómo cambia el valor de la experiencia cuando la herramienta acelera tanto al que ya sabe como al que todavía no. La pregunta, incómoda, de qué pasa con el criterio de un equipo cuando la velocidad de producir se multiplica y la de entender no.\nLo que vi, y lo que escribí en varios momentos del año, es que la IA no aplanó la diferencia entre la gente con criterio y la gente sin él; la amplificó. El que tiene experiencia le saca un provecho enorme, porque sabe pedirle lo correcto, elegir el tamaño correcto, revisar lo que devuelve, descartar lo que no sirve. El que todavía no la tiene corre el riesgo de una falsa autonomía que se derrumba en el primer problema serio. Eso le pone una responsabilidad nueva a quienes lideramos equipos: ya no alcanza con incorporar la herramienta, hay que cuidar que la herramienta no se coma el aprendizaje, que la velocidad no tape la comprensión, que el equipo siga entendiendo lo que construye en lugar de volverse un intermediario entre el cliente y una IA que nadie supervisa.\nY hay algo que este año me confirmó y que me parece el verdadero corazón del balance: en un mundo donde la tecnología es cada vez más capaz y más barata, lo que distingue a un buen equipo no es el acceso a las mejores herramientas, que ahora tiene casi cualquiera, sino cómo trabaja, cómo comparte lo que sabe, cómo decide, cómo cuida su propia comprensión. Lo escribí pensando en el mito del programador estrella, pero vale para todo el año: el diferencial nunca estuvo en la herramienta más potente, sino en las personas que saben qué hacer con ella. Y eso, en 2025, se volvió más cierto que nunca.\nLo que no cambió, y por eso importa más # Después de todo este recorrido —la explosión de modelos, el giro hacia Oriente, la apuesta europea, nuestra posición de consumidores ávidos— quiero terminar donde termino siempre, con lo que no cambió. Porque si algo aprendí en un año de escribir sobre todo esto, es que debajo del ruido de las novedades hay un puñado de cosas que se mantuvieron firmes, y que justamente por mantenerse firmes son las que más conviene mirar.\nNo cambió que el criterio importa más que la herramienta. Al contrario: cuanto más se multiplicaron las herramientas, más se notó la diferencia entre quien elige con juicio y quien persigue la novedad. No cambió que los agentes, por más capaces que sean, necesitan un arnés, y que cuanto más fuertes se vuelven, más fino tiene que ser ese arnés. No cambió que la deuda técnica se gestiona, no se elimina, y que ahora la fabricamos más rápido que nunca. No cambió que dependemos de muchísimo más de lo que controlamos, ni que los sistemas siguen cayéndose por cambios chicos que se propagan demasiado lejos mientras seguimos sin aprender entre un apagón y el siguiente. No cambió que la confianza, esa sobre la que construimos todo, sigue siendo a la vez nuestra fortaleza y nuestra fragilidad. Y no cambió, sobre todo, que la tecnología por sí sola nunca alcanza: necesita personas, criterio, cultura, decisiones conscientes.\nHay algo casi tranquilizador en esa permanencia. Vivimos un año de cambios vertiginosos, y sin embargo las preguntas de fondo siguieron siendo las mismas que vengo haciéndome hace años. Eso me confirma que el trabajo de quien lidera tecnología no es correr detrás de cada modelo nuevo, sino sostener el criterio mientras todo lo demás se acelera. La novedad es el ruido; el criterio es la señal. Y 2025, con toda su abundancia, no hizo más que volver esa distinción más nítida.\nLo que me llevo del año # Si tuviera que quedarme con una sola idea de 2025, sería esta: la IA se democratizó en el acceso y se concentró en otra cosa. Hoy cualquiera puede descargar un modelo capaz, correrlo, adaptarlo. Lo que no se descarga, lo que sigue siendo escaso y desigual, es el criterio para usarlo bien, la madurez para elegir, la disciplina para gobernar lo que se construye con eso. La tecnología se abrió; el juicio sigue cerrado en quien se tomó el trabajo de construirlo, a los tropezones, con experiencia. Y eso, para alguien que lleva años en esto y que cree que el oficio importa, es una noticia esperanzadora, no amenazante.\nMirando hacia 2026 hay, como siempre, más incertidumbre que certezas. No sé qué modelos van a salir, qué geografía va a pesar más, cómo se va a resolver la tensión entre regular y acelerar, si la región va a pasar del entusiasmo a la urgencia o se va a quedar, otra vez, en la promesa. Pero hay algo que sí sé, y que es lo que me deja tranquilo para cerrar el año: pase lo que pase con las herramientas, las preguntas que de verdad importan van a seguir necesitando criterio humano para responderse. Mientras eso sea cierto, los que nos dedicamos a esto desde el lado del juicio y no de la moda vamos a tener trabajo, y vamos a tener algo que aportar, incluso desde el sur, incluso sin construir los modelos de frontera.\nLes dejo, para terminar el año, una pregunta para que la lleven a su propio terreno, sea cual sea el rincón del mundo desde el que lean esto. En un año en que la tecnología se volvió tan abundante que es imposible seguirla toda, ¿en qué estuvimos invirtiendo más: en correr detrás de cada novedad, o en construir el criterio para elegir bien entre tantas opciones? Porque sospecho que 2026 va a premiar, todavía más que este año, a quienes hayan entendido que lo escaso ya no es la herramienta. Lo escaso, lo que de verdad vale, es saber qué hacer con ella.\n","date":"20 de diciembre de 2025","externalUrl":null,"permalink":"/blog/post-2025-cierre-ia-plural-criterio-escaso/","section":"Blog","summary":"Si 2024 fue el año en que la IA dejó de ser novedad y empezó a pedir madurez, 2025 fue el año en que se volvió plural: muchos modelos, muchos orígenes, muchas geografías, muchos precios. Y esa abundancia cambió el problema. Cuando hay tanto para elegir, el diferencial deja de ser el acceso a la mejor herramienta y pasa a ser el criterio para usarla. Un balance del año mirando el mundo, y mirándonos a nosotros desde el sur.","title":"2025: el año en que la IA se volvió plural y el criterio se volvió escaso","type":"blog"},{"content":"","date":"20 de diciembre de 2025","externalUrl":null,"permalink":"/tags/balance-anual/","section":"Tags","summary":"","title":"Balance-Anual","type":"tags"},{"content":"","date":"20 de diciembre de 2025","externalUrl":null,"permalink":"/tags/europa/","section":"Tags","summary":"","title":"Europa","type":"tags"},{"content":"","date":"20 de diciembre de 2025","externalUrl":null,"permalink":"/tags/latam/","section":"Tags","summary":"","title":"Latam","type":"tags"},{"content":"","date":"20 de diciembre de 2025","externalUrl":null,"permalink":"/tags/open-source/","section":"Tags","summary":"","title":"Open-Source","type":"tags"},{"content":"","date":"25 de noviembre de 2025","externalUrl":null,"permalink":"/tags/cloud/","section":"Tags","summary":"","title":"Cloud","type":"tags"},{"content":"","date":"25 de noviembre de 2025","externalUrl":null,"permalink":"/tags/continuidad-operativa/","section":"Tags","summary":"","title":"Continuidad-Operativa","type":"tags"},{"content":"","date":"25 de noviembre de 2025","externalUrl":null,"permalink":"/tags/outages/","section":"Tags","summary":"","title":"Outages","type":"tags"},{"content":"","date":"25 de noviembre de 2025","externalUrl":null,"permalink":"/tags/resiliencia-tecnologica/","section":"Tags","summary":"","title":"Resiliencia-Tecnologica","type":"tags"},{"content":"Tengo que empezar con una aclaración honesta, porque hace a cómo escribí este post. Cuando se cayó medio internet dos veces en pocas semanas, sentí lo que seguramente sintieron muchos: una mezcla de fascinación y de \u0026ldquo;¿otra vez?\u0026rdquo;. Pero también sentí algo más incómodo: que no terminaba de entender, en detalle, qué había fallado. Los informes técnicos que publicaron AWS y Cloudflare son excelentes, pero también densos, llenos de detalles de infraestructura que no son mi especialidad. Así que hice algo que cada vez hago más: me apoyé en la IA para masticarlos. Le pasé los postmortems, le pedí que me explicara los mecanismos de falla en términos que pudiera discutir, que me ayudara a separar el detalle técnico del patrón de fondo. Para poder llegar yo a una opinión sin pretender hacer una pericia en infraestructura para la cual no tengo el conocimiento suficiente. Lo que sigue son mis conclusiones, pero el camino para entender lo técnico lo recorrí acompañado. Y, mirándolo bien, eso también es parte de lo que vengo diciendo todo el año sobre cómo usar estas herramientas con criterio.\nLo que pasó, sin pretender ser experto # Repaso los dos episodios en términos simples, que es como los entendí. El 20 de octubre, AWS sufrió una caída enorme en su región de Virginia, US-EAST-1, que es una de las más importantes del mundo y de la que cuelgan, de forma directa o indirecta, una cantidad asombrosa de servicios. Según el informe que publicó la propia empresa, el origen fue una condición de carrera —una situación en la que dos procesos automáticos que debían coordinarse pisaron uno el trabajo del otro— dentro del sistema que gestiona el DNS de su base de datos DynamoDB. El resultado, contado en criollo, fue que quedó vacío un registro que sirve para que los sistemas encuentren ese servicio. Como tantas otras cosas dependían de él, la falla se propagó en cascada durante unas quince horas y se llevó puesta a media internet: aplicaciones, juegos, billeteras, hasta pedidos de comida rápida.\nEl 18 de noviembre, apenas unas semanas después, le tocó a Cloudflare, que es esa capa invisible por la que pasa una porción gigantesca del tráfico web del mundo. Acá el origen fue distinto en los detalles pero, como veremos, sospechosamente parecido en su forma. Un cambio de permisos en una base de datos hizo que una consulta empezara a devolver filas duplicadas. Eso, a su vez, hizo que un archivo de configuración que usa su sistema de detección de bots —el que decide si quien visita un sitio es una persona o un robot— duplicara su tamaño. Y ese archivo, más grande de lo previsto, superó un límite fijo que estaba grabado en el software que enruta el tráfico. Al pasar ese límite, el sistema entró en pánico y empezó a fallar. Como ese archivo se propaga a toda la red cada pocos minutos, el problema se replicó por todos lados casi simultáneamente, y durante varias horas una parte enorme de la web devolvió errores.\nNo voy a fingir que entiendo cada matiz técnico de estos mecanismos; no es lo mío, y para eso están los ingenieros de esas empresas, que además escribieron informes muy buenos. Pero no hace falta ser experto en infraestructura para ver lo que tienen en común. Y es ahí, en lo que comparten, donde está lo que de verdad me interesa.\nEl patrón que se repite # Cuando puse los dos casos uno al lado del otro —con ayuda, lo dije, de un análisis que hice con IA para no perderme en la maleza técnica— el patrón saltó a la vista, y resultó ser exactamente el mismo que ya había descrito hace más de un año hablando de la caída asociada a CrowdStrike. Tres incidentes enormes, de tres empresas distintas, separados en el tiempo, y los tres responden a la misma estructura profunda.\nPrimero: ninguno fue un ataque. No hubo hackers, no hubo malicia, no hubo enemigo. Los tres fueron errores internos, cambios propios que salieron mal. Esto ya lo había señalado con CrowdStrike y lo vuelvo a subrayar porque va contra la intuición: cuando pensamos en que internet se cae, imaginamos villanos, y la realidad es que el villano más frecuente somos nosotros mismos, con un cambio mal calculado.\nSegundo, y esto es lo más revelador: en los tres casos, un cambio pequeño se propagó demasiado lejos. Una actualización de contenido en CrowdStrike. Un registro DNS que quedó vacío en AWS. Un archivo de configuración que creció de más en Cloudflare. Ninguna de esas cosas, en sí misma, es catastrófica. Lo catastrófico fue que no había nada que frenara su propagación. El error chiquito viajó, sin diques, hasta convertirse en un apagón global. La fragilidad no estuvo en el tamaño del error, sino en la ausencia de límites a su propagación.\nY tercero: en los tres, el detalle que falló era algo que todos asumían correcto y que nadie estaba mirando. Un registro DNS que siempre había estado bien. Un límite de tamaño que parecía holgado. Una actualización que siempre se había aplicado sin problema. Piezas invisibles, dadas por sentadas, hasta el día que dejaron de comportarse como esperábamos. Es, otra vez, la historia de las dependencias invisibles sobre la que escribí en abril: no se rompe lo que vigilamos, se rompe lo que dejamos de mirar porque nunca nos había fallado.\n\u0026ldquo;Radio de explosión\u0026rdquo;: una idea que conviene incorporar # Hay un concepto que aparece en estos análisis y que vale oro para cualquiera que diseñe sistemas: el radio de explosión. La idea es simple y visual. Cuando algo falla, ¿hasta dónde llega el daño? ¿Queda contenido en una pieza, o se expande y arrastra todo lo que toca? Un buen diseño no es uno donde nada falla nunca —eso no existe— sino uno donde, cuando algo falla, el daño queda acotado, con paredes que impiden que el fuego de una habitación queme la casa entera.\nLo que tienen en común los tres apagones es que el radio de explosión fue inmenso. Un problema en una región de AWS no debería poder afectar al mundo entero, pero lo hizo, porque demasiadas cosas dependían de esa región específica para funciones críticas. Un archivo de configuración mal generado en Cloudflare no debería poder tumbar la red completa, pero lo hizo, porque se propagaba a todos lados a la vez sin etapas ni frenos. En los dos casos, faltaron las paredes. Faltó el diseño que dice \u0026ldquo;si esto falla, que falle solo, no que se lleve todo puesto\u0026rdquo;. Y esto conecta con algo que vengo repitiendo: la resiliencia no consiste en evitar el fallo, sino en diseñar para que el fallo no se propague. Cuando hablé de CrowdStrike lo dije con otras palabras; ver el mismo principio violado dos veces más, en pocas semanas, lo vuelve casi una ley.\nLa paradoja de la página que también se cae # Hay un detalle de estos episodios que me llamó la atención y que toca un tema muy de mi mundo: la comunicación durante la crisis. Cuando un proveedor gigante se cae, miles de equipos como el mío quedan a ciegas, mirando un sistema que no responde y tratando de entender si el problema es nuestro o de afuera. Y lo primero que hacemos es correr a la página de estado del proveedor, esa que debería decirnos \u0026ldquo;sí, somos nosotros, estamos en eso\u0026rdquo;. El problema es que, en incidentes de esta magnitud, a veces esa misma página o los canales para comunicarla dependen de la infraestructura que se cayó. Te quedás sin servicio y, además, sin la información para saber qué está pasando con el servicio.\nEs una paradoja que me parece profundamente instructiva, más allá de los gigantes: nuestros sistemas de observación y comunicación de incidentes no pueden depender de la misma capa que están vigilando. Si el tablero que me avisa que algo se rompió se rompe junto con todo lo demás, no tengo tablero, tengo un adorno. Lo mismo vale para la comunicación hacia adentro y hacia afuera: si para avisarle al equipo o a mis clientes que hay un incidente dependo de una herramienta que también está caída, me quedé mudo en el peor momento. Esto lo había mencionado de pasada cuando escribí sobre CrowdStrike, pero verlo repetirse a esta escala lo vuelve una lección dura: la resiliencia no es solo que el sistema aguante, es también que mi capacidad de entender y comunicar lo que pasa sobreviva a la propia caída.\nY acá hay algo que sí está a mi alcance, aunque no sea AWS. Puedo asegurarme de que mi monitoreo no viva enteramente sobre la infraestructura que monitorea. Puedo tener un canal de comunicación de emergencia que no dependa de las mismas herramientas de todos los días. Puedo decidir de antemano quién comunica qué, a quién, y por qué medio cuando todo lo habitual no está disponible. Nada de eso evita el apagón, pero cambia por completo cómo lo transito: la diferencia entre un equipo que durante el incidente sabe qué pasa y puede avisar, y uno que está tan a oscuras como sus usuarios, esperando que la página de estado de un tercero vuelva a la vida para enterarse de su propia situación.\nAlgo que noté al analizar estos casos, y que me reconcilia con varios de los temas que toqué este año, es el rol de la velocidad. Estos sistemas están diseñados para desplegar cambios rápido, propagar configuraciones en minutos, actualizarse constantemente. Esa velocidad es lo que los hace potentes y modernos. Pero es también, exactamente, lo que amplificó las fallas. El archivo malo de Cloudflare se propagó a toda la red en minutos justamente porque el sistema está optimizado para propagar rápido. La velocidad que es una virtud en el día a día se transformó, el día del incidente, en el acelerador del desastre.\nVi a algunos analistas conectar esto con la cultura actual de shipear features a toda velocidad, e incluso con el espíritu del vibe coding del que hablé en marzo y en julio: priorizar la rapidez de entrega por encima de la robustez. No quiero forzar la analogía, porque estas son empresas con ingeniería de primerísimo nivel y procesos serios, no proyectos vibe-codeados un fin de semana. Pero el principio de fondo resuena con todo lo que vengo pensando: la velocidad sin frenos tiene un costo, y ese costo no aparece en el día a día, aparece de golpe el día que algo sale mal. Es la misma idea que planteé con el código generado por IA y con la elección de modelos: ir rápido no es gratis, simplemente la cuenta llega más tarde y toda junta.\nLo que de verdad me preocupa: no aprendemos entre apagón y apagón # Acá está, creo, la reflexión más incómoda, y la que justifica juntar los dos casos en un solo post en vez de comentarlos por separado. Hace más de un año escribí sobre CrowdStrike y dije, con cierta esperanza, que ojalá nos dejara conciencia. Bueno: pasó CrowdStrike, pasó AWS, pasó Cloudflare, y el patrón es idéntico. No es que no sepamos qué falla; lo sabemos, está escrito en cada postmortem. Es que, como industria, no terminamos de cambiar las condiciones que lo hacen posible. Seguimos concentrando enormes cantidades de servicios críticos en unos pocos proveedores. Seguimos asumiendo que esas piezas gigantes no se van a caer. Seguimos sin diseñar para contener el radio de explosión.\nY no lo digo desde la superioridad, porque caigo en lo mismo. Cuando elijo dónde alojar un sistema, voy a los proveedores grandes, como todos, porque son confiables, baratos y cómodos. La concentración no es un capricho; es una consecuencia racional de que esos proveedores son, casi siempre, la mejor opción. El problema es colectivo: cada decisión individual de concentrarse es razonable, pero la suma de todas nos deja un internet donde la falla de una empresa puede apagar medio mundo. Es una tragedia de los comunes, pero con servidores. Nadie decide construir un sistema frágil; lo construimos entre todos, una decisión cómoda a la vez.\n\u0026ldquo;Entonces diversifiquemos todo\u0026rdquo;, y por qué no es tan simple # La respuesta refleja a todo esto suele ser: bueno, no pongamos todos los huevos en la misma canasta, repartamos entre varios proveedores. Y suena impecable hasta que uno lo piensa en serio. Diversificar la infraestructura —correr en dos nubes, tener proveedores alternativos para todo— es muchísimo más caro, más complejo y más lento de operar. Cada proveedor tiene sus particularidades, y mantener un sistema que funcione idéntico en dos lugares a la vez suele duplicar el trabajo y multiplicar los puntos donde algo puede salir mal. A veces, la complejidad que agregás para protegerte de una caída introduce más fallas de las que evita. La cura puede ser peor que la enfermedad.\nPor eso desconfío de la receta fácil del \u0026ldquo;diversificá todo\u0026rdquo;. Me parece más honesto pensarlo como una decisión de criterio, caso por caso, igual que cuando hablé de elegir el modelo de IA adecuado en vez del más grande por defecto. La pregunta no es \u0026ldquo;¿multi-cloud sí o no?\u0026rdquo; como dogma, sino \u0026ldquo;¿qué partes de mi sistema son tan críticas que justifican el costo de tener una alternativa, y cuáles pueden tolerar unas horas de caída sin que el mundo se termine?\u0026rdquo;. No todo merece el mismo nivel de protección, porque protegerlo todo por igual es la forma más segura de no poder pagar la protección de nada. La diversificación tiene sentido como la opción de poder fallar hacia otro lado para lo que de verdad no puede parar, no como un mandamiento de correr todo en paralelo por las dudas.\nY hay una trampa adicional que conviene nombrar: muchas veces creemos que diversificamos y no es cierto. Usamos dos proveedores distintos que, sin que lo sepamos, dependen por debajo de la misma pieza de infraestructura, del mismo DNS, del mismo punto de concentración. La diversificación de la superficie no garantiza la diversificación del fondo. Volvemos, otra vez, a las dependencias invisibles: no se puede diversificar de verdad lo que no se conoce, y para saber de qué dependemos realmente hay que haber hecho antes el trabajo incómodo de mapearlo.\nUna objeción honesta a todo esto: yo no opero la infraestructura de medio internet. ¿Qué me llevo, como alguien que conduce un equipo de tamaño normal, de una falla en una de las empresas más grandes del planeta? Bastante, en realidad, si traduzco las lecciones a mi escala.\nMe llevo, primero, la pregunta por mis propias dependencias críticas, que es la misma que me hice en abril pero ahora con más urgencia: si mi proveedor principal se cae quince horas, como le pasó a los clientes de AWS, ¿qué hago? ¿Tengo siquiera pensada esa respuesta, o asumo que no va a pasar? Me llevo, segundo, la idea del radio de explosión aplicada a lo mío: cuando algo en mi sistema falla, ¿queda contenido o se propaga? ¿Tengo paredes, o un error chico puede llevarse todo? Y me llevo, tercero, una dosis de humildad: si a empresas con los mejores ingenieros del mundo y recursos infinitos les pasa esto, mi sistema no es inmune por ser más chico. Al contrario, probablemente tengo menos defensas. La diferencia es que mi apagón no sale en las noticias, pero a mis usuarios les duele igual.\nNo tengo una solución mágica, y desconfío de quien la ofrezca. La resiliencia total es imposible y carísima. Pero hay un punto intermedio entre la paranoia paralizante y la negación cómoda, y vive en preguntas que conviene hacerse en frío, antes del incidente: qué pasa si esto se cae, hasta dónde llega el daño, cómo me entero, cómo me recupero, qué puedo contener. No hace falta resolverlas todas. Hace falta, al menos, habérselas hecho.\nLo que me queda, después de tres apagones # Si junto los tres episodios —CrowdStrike el año pasado, AWS y Cloudflare este— la conclusión que me queda no es técnica, porque lo técnico no es mi fuerte y además cambia con cada caso. Es casi filosófica, y tiene que ver con cómo nos paramos frente a los sistemas que construimos. Vivimos sobre una infraestructura cada vez más potente, más rápida y más concentrada, y esa misma potencia que tanto nos sirve es la que, cuando falla, falla en grande. No es un defecto que se pueda eliminar con más tecnología; es una característica del tipo de mundo que construimos, donde la eficiencia y la concentración van de la mano de la fragilidad.\nLa madurez, entonces, no está en pretender que estos apagones no van a pasar —van a seguir pasando, es matemático— sino en dejar de sorprendernos cada vez como si fuera la primera, y empezar a diseñar, en nuestra escala, asumiendo que el fallo es parte del paisaje. Diseñar para contener, no solo para funcionar. Y, sobre todo, tener la honestidad de mirar nuestras propias dependencias antes de que un martes cualquiera nos obliguen a mirarlas a las apuradas.\nLes dejo una pregunta para llevarse, que es casi la misma que dejé hace un año pero que ahora pesa más, porque ya van tres. Cuando lean la noticia del próximo gran apagón —y va a haber uno, seguro— ¿lo van a vivir como una sorpresa indignante, \u0026ldquo;cómo puede ser que se caigan\u0026rdquo;, o como lo que en realidad es: el recordatorio previsible de una fragilidad que conocemos, que está documentada, y que seguimos eligiendo no enfrentar mientras todo, casi siempre, funcione? Porque la diferencia entre indignarse y prepararse es, al final, la única que está bajo nuestro control.\nFuentes consultadas # Amazon Web Services, \u0026ldquo;Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region\u0026rdquo;, postmortem publicado el 23 de octubre de 2025. Cloudflare, \u0026ldquo;Cloudflare outage on November 18, 2025\u0026rdquo;, 18 de noviembre de 2025. The Register, \u0026ldquo;A single DNS race condition brought AWS to its knees\u0026rdquo;, 23 de octubre de 2025. ","date":"25 de noviembre de 2025","externalUrl":null,"permalink":"/blog/post-tres-caidas-un-solo-patron/","section":"Blog","summary":"En cuestión de semanas, AWS y Cloudflare se cayeron y arrastraron con ellos a buena parte de internet. Me apoyé en un análisis con IA para entender de verdad qué falló en cada caso, y debajo de los detalles técnicos encontré el mismo patrón que ya había visto con CrowdStrike: no fueron ataques, fueron cambios pequeños que se propagaron sin freno por sistemas que asumíamos sólidos. La lección no es sobre DNS ni sobre archivos de configuración. Es sobre cuánto dependemos de cuán poco, y sobre lo poco que aprendemos entre un apagón y el siguiente.","title":"Tres caídas, un solo patrón: lo que nos enseñan los grandes apagones de 2025","type":"blog"},{"content":"Hay una frase que se dice mucho y que, cada vez que la escucho, me dan ganas de discutirla: \u0026ldquo;tenemos que eliminar la deuda técnica\u0026rdquo;. Suena bien, suena responsable, suena a equipo maduro. El problema es que parte de una idea equivocada: que la deuda técnica es algo malo que hay que erradicar, como una plaga. Después de muchos años conviviendo con sistemas reales —los que funcionan, los que dan plata, los que tienen clientes que dependen de ellos— llegué a una conclusión distinta y bastante más incómoda: la deuda técnica no se elimina, se administra. No es un error a corregir, es una condición permanente del oficio, como la fricción para un mecánico o el costo para un contador. Y como toda condición permanente, lo que importa no es soñar con hacerla desaparecer, sino aprender a gestionarla con criterio. La vengo mencionando al pasar en casi todo lo que escribí este año, así que me debía a mí mismo un post entero. Acá está.\nDeuda no es lo mismo que desprolijidad # Lo primero que conviene aclarar, porque se confunde todo el tiempo, es que deuda técnica no es sinónimo de código mal hecho. El nombre lo eligió bien quien lo inventó, porque la metáfora financiera es exacta: una deuda es algo que tomás a propósito, conscientemente, para conseguir algo ahora a cambio de pagar más después. Pedís prestado tiempo del futuro para entregar valor en el presente. Y eso, lejos de ser siempre malo, a veces es la decisión correcta.\nPensémoslo con un ejemplo cualquiera. Una empresa tiene una oportunidad de mercado que dura tres semanas. Puede construir la solución perfecta, bien diseñada, mantenible, en tres meses, y perder la oportunidad. O puede construir algo que funcione en dos semanas, con atajos conscientes, y capturar el negocio, sabiendo que después tendrá que volver a poner las cosas en orden. Tomar deuda ahí no es irresponsable; es estratégico. El problema no es tomar deuda. El problema es tomarla sin saber que la estás tomando, no registrarla, y descubrir años después que el sistema entero está hipotecado y nadie firmó nada.\nPor eso me gusta separar la deuda deliberada de la desprolijidad. La deuda deliberada es una decisión: \u0026ldquo;sabemos que esto no es lo ideal, lo hacemos así por esta razón, y vamos a tener que volver\u0026rdquo;. La desprolijidad es otra cosa: es no saber hacerlo mejor, o no haberse tomado el trabajo de pensar. La primera es una herramienta legítima del oficio. La segunda es, simplemente, trabajo mal hecho disfrazado con un nombre elegante. Cuando alguien dice \u0026ldquo;es deuda técnica\u0026rdquo; para justificar algo que en realidad es chapucería, está usando mal el término, y conviene no dejarlo pasar.\nLa que se ve # La deuda más fácil de manejar es la que se ve. El código que sabemos que está feo, la función que todos evitan tocar, el módulo que da vergüenza, la parte del sistema sobre la que el equipo bromea en los pasillos. Esa deuda, al menos, tiene la cortesía de ser visible. Sabemos que está, sabemos más o menos dónde, y podemos decidir qué hacer con ella.\nLo interesante de la deuda visible es que el problema rara vez es técnico: es de priorización. Casi siempre sabemos qué habría que arreglar; lo que no tenemos es el permiso, el tiempo o la decisión de hacerlo. Y ahí entra una de las habilidades centrales de quien lidera: elegir qué deuda visible vale la pena pagar y cuál conviene dejar tranquila. Porque —y esto va contra el instinto del perfeccionista— no toda deuda visible hay que pagarla. Hay código feo que funciona perfecto, que casi no se toca, que no está en el camino crítico de nada. Refactorizarlo sería gastar esfuerzo en mejorar algo que nadie iba a sentir. La deuda visible que no molesta puede quedarse fea y en paz. El criterio no está en arreglar todo lo que se ve mal, sino en distinguir lo que duele de lo que solo es feo.\nLa que se esconde # Mucho más peligrosa es la deuda que no se ve. Y acá conecto con algo que escribí hace unos meses sobre las dependencias invisibles, porque es la misma familia de problemas: lo que no conocemos no lo podemos gestionar. La deuda escondida no es código feo que evitamos; es deuda que ni siquiera sabemos que tenemos.\nTiene muchas formas, y casi ninguna parece deuda a primera vista. El conocimiento que vive en la cabeza de una sola persona y que se va a ir caminando el día que esa persona renuncie. La decisión de arquitectura que se tomó hace cinco años por una razón que ya nadie recuerda, y que sigue condicionando todo sin que sepamos por qué. La dependencia que funciona tan bien que dejamos de mirarla. El supuesto que era verdad cuando se diseñó el sistema y dejó de serlo sin que nadie lo notara. La falta de tests que no se siente como deuda hasta el día que hay que cambiar algo y nadie está seguro de qué va a romper. Como dije una vez, la deuda técnica no es solo código viejo: es conocimiento perdido, decisión no documentada, miedo a tocar una parte del sistema. Todo eso es deuda, y toda esa deuda es invisible justamente hasta el peor momento.\nLo que vuelve tan traicionera a la deuda escondida es que no aparece en ninguna métrica, en ningún tablero, en ninguna reunión de planificación. No genera alertas. No molesta en el día a día. Crece en silencio, y solo se cobra cuando intentamos cambiar algo y descubrimos que el sistema es mucho más frágil de lo que creíamos. Por eso el mejor trabajo que puede hacer un equipo sobre su deuda escondida es, antes que nada, hacerla visible: documentar lo que vive en cabezas, registrar las decisiones y sus porqués, mapear de qué depende lo crítico. No se puede pagar una deuda que no figura en ningún lado, igual que no se puede proteger lo que no se conoce. Hacer visible la deuda escondida no la elimina, pero la convierte en algo gestionable, que ya es muchísimo.\nLa que heredamos # Y después está la deuda que no creamos nosotros: la que heredamos. Casi cualquiera que llega a un sistema con algunos años de vida se encuentra con esto, y merece una mirada propia porque tiene una dinámica distinta a las otras dos. Heredar deuda es recibir un sistema construido por gente que ya no está, con decisiones que no tomamos, atajos que no elegimos, y una historia que muchas veces nadie nos puede contar entera.\nLa deuda heredada tiene una trampa emocional que conviene nombrar. Cuando uno recibe un sistema lleno de deuda, la reacción fácil es el desprecio: \u0026ldquo;qué desastre hicieron acá, esto está todo mal, hay que tirar todo y rehacerlo\u0026rdquo;. Es una reacción comprensible y casi siempre equivocada. Equivocada por dos razones. La primera es de humildad: ese sistema que nos parece un desastre probablemente se construyó con restricciones que no conocemos —plazos imposibles, presupuestos ajustados, requisitos que cambiaban, gente que aprendía sobre la marcha—. La gente que lo hizo no era necesariamente peor que nosotros; estaba en otra situación. Juzgar el pasado con la comodidad del presente es injusto y, peor, no ayuda en nada. La segunda razón es práctica: ese sistema \u0026ldquo;desastroso\u0026rdquo;, con toda su deuda, es el que está funcionando, el que sostiene el negocio, el que tiene clientes encima. No es un borrador que podemos descartar; es algo vivo que hay que mantener andando mientras lo mejoramos.\nLa tentación más peligrosa frente a la deuda heredada es la reescritura total: tirar todo y empezar de cero, hacerlo \u0026ldquo;bien\u0026rdquo; esta vez. La historia de nuestra industria está llena de reescrituras que terminaron mal, que tardaron el triple de lo previsto, que reintrodujeron los mismos problemas con ropa nueva, o que nunca llegaron a reemplazar al viejo sistema que, mientras tanto, seguía funcionando. Modernizar un sistema heredado casi nunca es tirar todo y empezar de nuevo; es convivir con lo existente, entenderlo con humildad, reducir riesgos, mejorar de a poco, migrar gradualmente sin romper el negocio. Es menos heroico que la reescritura épica, pero funciona muchísimo más seguido. La deuda heredada no se salda con un gran gesto; se va pagando, de a cuotas, mientras el sistema sigue dando servicio.\nLa conversación más difícil: explicarle al negocio # Hasta acá hablé de la deuda desde el lado técnico, pero hay una mitad del problema que es, en realidad, una conversación con quienes no son técnicos. Porque la deuda técnica se paga con tiempo, y ese tiempo casi siempre compite con features nuevas, con pedidos del negocio, con cosas que sí se ven y que generan valor visible. Y acá está una de las habilidades más subestimadas de quien lidera tecnología: saber explicarle a alguien que no es técnico por qué a veces hay que frenar para arreglar algo que, desde afuera, parece que ya funciona.\nEs una conversación difícil porque la deuda técnica es invisible para el negocio. Quien mira desde el lado comercial ve que el sistema anda, que los clientes lo usan, que todo parece bien. Pedir tiempo para \u0026ldquo;mejorar algo que ya funciona\u0026rdquo; suena, desde esa perspectiva, a un capricho de ingenieros perfeccionistas. Y a veces lo es, seamos honestos. Pero muchas otras veces es la diferencia entre un sistema que va a poder crecer y uno que va a empezar a frenar todo dentro de seis meses. El problema es que ese costo futuro no se ve hoy, y lo que no se ve es difícil de vender.\nLo que aprendí es que no sirve explicarlo en términos técnicos. Al negocio no le importa, ni tiene por qué importarle, qué tan elegante es nuestro código. Le importa el impacto: cuánto más lento vamos a entregar features si no pagamos esta deuda, qué riesgo de caída estamos corriendo, cuánto nos va a costar contratar gente nueva si nadie entiende el sistema, qué oportunidad vamos a perder cuando no podamos movernos rápido. La deuda técnica hay que traducirla al idioma del negocio, que es el del riesgo y el de la oportunidad, no el de la prolijidad. \u0026ldquo;El código está feo\u0026rdquo; no convence a nadie. \u0026ldquo;Si no arreglamos esto, el próximo cambio importante nos va a llevar el triple y con riesgo de romper producción\u0026rdquo; es una conversación que el negocio entiende, porque habla de tiempo y de plata, que es su idioma. Traducir es parte del trabajo.\nCómo decidir qué pagar y cuándo # Una cosa es decir \u0026ldquo;la deuda que duele se paga y la que es solo fea se deja\u0026rdquo;, y otra es bajarlo a una decisión concreta el lunes a la mañana, con una lista de cosas para arreglar y un tiempo limitado. Acá es donde la gestión de la deuda deja de ser filosofía y se vuelve oficio. Lo que trato de mirar, ante cada pieza de deuda, son tres cosas distintas que conviene no mezclar.\nLa primera es cuánto duele hoy: si esa deuda está frenando al equipo ahora mismo, si cada cambio en esa zona cuesta el triple, si es la causa de bugs recurrentes. La segunda es cuánto va a doler mañana: si está en una parte del sistema que vamos a tener que tocar mucho en los próximos meses, o en un rincón que nadie va a visitar. Una deuda en código que vamos a reescribir igual el mes que viene no vale la pena pagarla; una deuda chica en el corazón de algo que vamos a extender sin parar, sí. Y la tercera es cuánto cuesta pagarla: porque hay deuda dolorosa pero carísima de saldar, y deuda menor que se arregla en una tarde. La combinación de esas tres —duele, va a doler, cuesta poco— es la que marca la prioridad real, y casi nunca coincide con \u0026ldquo;lo que más nos molesta a la vista\u0026rdquo;.\nEsto importa porque el error más común no es ignorar la deuda; es pagarla en el orden equivocado. Equipos que dedican esfuerzo a embellecer una parte del sistema que nadie toca, mientras la deuda que de verdad los frena sigue ahí porque es menos visible o menos satisfactoria de arreglar. Pagar deuda también es una decisión de priorización, y como toda priorización, se hace bien con cabeza y mal por impulso. Lo satisfactorio de arreglar y lo importante de arreglar son dos cosas distintas, y conviene no confundirlas. El refactor que nos deja contentos no siempre es el que el sistema necesitaba.\nLa deuda también es una conversación de equipo # Hay una dimensión de todo esto que es puramente humana y que aprendí a no descuidar: cómo el equipo se relaciona con su propia deuda. Un equipo que carga deuda en silencio, que no la nombra, que cada uno conoce sus rincones feos pero nadie los comparte, está peor que uno que la tiene mapeada y discutida, aunque la cantidad de deuda sea la misma. Porque la deuda que se habla se puede priorizar; la que cada uno se guarda, no.\nPor eso trato de que hablar de deuda sea normal en el equipo, sin culpa ni vergüenza. Que alguien pueda decir \u0026ldquo;esto lo resolví con un atajo, lo dejo anotado para volver\u0026rdquo; sin sentir que confiesa un pecado. Que tomar deuda deliberada sea una decisión que se comparte, no algo que se esconde. Que la deuda heredada se cuente sin despreciar a quien la dejó. Cuando la deuda se vuelve un tema conversable, deja de crecer en la oscuridad y pasa a ser algo que el equipo gestiona junto. Y esto conecta con algo que escribí sobre cómo funciona un equipo de verdad: lo que sostiene a un grupo no es que cada uno sea brillante por separado, sino cómo comparten lo que saben. La deuda escondida prospera, justamente, donde no se comparte. Hacerla conversable es, en el fondo, un acto de salud del equipo antes que un acto técnico.\nComo en casi todo, los extremos son malos consejeros, y la deuda técnica tiene dos. El extremo del perfeccionista, que no tolera nada que no esté impecable, que quiere refactorizar todo, que frena la entrega de valor por una pulcritud que el negocio no necesita. Y el extremo opuesto, el del abandono, que toma deuda sin parar, nunca paga nada, y deja que el sistema se pudra hasta que un día deja de poder cambiarse. Los dos terminan mal. El perfeccionista no entrega; el que abandona, entrega hasta que ya no puede.\nEl criterio, como casi siempre, vive en el medio incómodo. Tomar deuda cuando tiene sentido estratégico, y registrarla cuando la tomamos. Pagar la deuda que duele, la que está en el camino crítico, la que frena al equipo, y dejar en paz la que es solo fea. Hacer visible la que está escondida. Convivir con la heredada sin despreciarla ni idolatrar la reescritura. Y, todo el tiempo, traducirle al negocio por qué estas decisiones importan. No hay una fórmula; hay criterio, que es esa palabra que vengo repitiendo todo el año porque es, en el fondo, de lo único que se trata el oficio cuando las herramientas dejan de ser el problema.\nPor qué esto importa más ahora # Hay una razón por la que este tema, que es viejo como el software, se volvió más urgente justo ahora. Lo toqué cuando escribí sobre programar con IA y sobre los agentes: estas herramientas bajaron drásticamente el costo de generar código. Y cuando generar código es barato y rápido, es facilísimo acumular deuda a una velocidad que antes era impensable. Más código, más rápido, sin necesariamente más comprensión. Código que funciona pero que nadie diseñó del todo, que nadie entiende del todo, generado en conversaciones que ya no existen.\nEso no hace que la deuda técnica sea un tema del pasado; la vuelve más relevante que nunca. La capacidad de generar creció muchísimo; la capacidad de entender, mantener y pagar lo generado, no. Y esa brecha es, exactamente, deuda técnica esperando a hacerse visible. Por eso administrar la deuda con criterio, que siempre fue parte del oficio, se vuelve una de las habilidades más valiosas del momento. No porque la deuda sea nueva, sino porque ahora podemos fabricarla más rápido que nunca, y la disciplina de gestionarla no escaló a la misma velocidad que la facilidad de crearla.\nLes dejo una pregunta para que la lleven a su propio sistema. Si tuvieran que separar la deuda de su sistema en esas tres pilas —la que ven, la que sospechan que está escondida, y la que heredaron sin haberla creado— ¿cuál de las tres les da más miedo, y cuál es la que menos están mirando? Porque casi siempre la que más nos va a costar no es la que tenemos a la vista quejándonos de ella, sino la que ni sabíamos que estábamos cargando. Y con la deuda, como con casi todo en tecnología, el primer paso para gestionarla no es pagarla: es animarse a mirarla de frente.\n","date":"20 de octubre de 2025","externalUrl":null,"permalink":"/blog/post-deuda-tecnica-la-que-se-ve-la-que-se-esconde-y-la-que-heredamos/","section":"Blog","summary":"La deuda técnica no se elimina, se administra. Y administrarla bien es parte del oficio de cualquiera que lidere tecnología. Quiero pensarla en sus tres formas —la que se ve, la que se esconde y la que heredamos— y en la conversación más difícil de todas: explicarle al negocio por qué a veces hay que frenar para pagar algo que no se ve.","title":"Deuda técnica: la que se ve, la que se esconde y la que heredamos","type":"blog"},{"content":"","date":"20 de octubre de 2025","externalUrl":null,"permalink":"/tags/deuda-tecnica/","section":"Tags","summary":"","title":"Deuda-Tecnica","type":"tags"},{"content":"","date":"20 de octubre de 2025","externalUrl":null,"permalink":"/tags/mantenimiento/","section":"Tags","summary":"","title":"Mantenimiento","type":"tags"},{"content":"","date":"20 de octubre de 2025","externalUrl":null,"permalink":"/tags/negocio/","section":"Tags","summary":"","title":"Negocio","type":"tags"},{"content":"","date":"25 de septiembre de 2025","externalUrl":null,"permalink":"/tags/cadena-de-suministro/","section":"Tags","summary":"","title":"Cadena-De-Suministro","type":"tags"},{"content":"","date":"25 de septiembre de 2025","externalUrl":null,"permalink":"/tags/codigo-abierto/","section":"Tags","summary":"","title":"Codigo-Abierto","type":"tags"},{"content":"","date":"25 de septiembre de 2025","externalUrl":null,"permalink":"/tags/confianza/","section":"Tags","summary":"","title":"Confianza","type":"tags"},{"content":"Quiero arrancar con una confesión que probablemente compartan muchos de los que lean esto: no tengo la menor idea de qué hay, exactamente, dentro de la mayoría del software que uso para construir software. Cuando arranco un proyecto y corro ese comando que instala dependencias, en segundos se descargan decenas, a veces cientos de paquetes, escritos por gente que no conozco, que a su vez dependen de otros paquetes escritos por otra gente que tampoco conozco, en una cadena que se hunde varios niveles más abajo de lo que jamás voy a inspeccionar. Y lo acepto. Todos lo aceptamos. Es la única forma de trabajar a la velocidad que el mundo nos exige. Confiamos, sin pensarlo demasiado, en una cantidad asombrosa de código ajeno. Este mes, un ataque al ecosistema de paquetes de JavaScript me hizo volver a mirar esa confianza de frente, y entender, una vez más, que lo que nos permite avanzar rápido es exactamente lo mismo que nos vuelve frágiles. Quiero pensar en voz alta sobre eso, no desde la seguridad técnica —que no es mi especialidad— sino desde algo que sí me ocupa todos los días: las dependencias que aceptamos sin mirar, y la confianza sobre la que está construido todo.\nLo que pasó, en términos simples # A mediados de septiembre, el ecosistema de npm —el gigantesco repositorio de paquetes sobre el que se construye buena parte del software JavaScript del mundo— sufrió un ataque que llamó mucho la atención, y no tanto por su tamaño como por su forma. Apareció un código malicioso, que los investigadores bautizaron con un nombre sacado de la ciencia ficción, Shai-Hulud, con una característica novedosa: se replicaba solo. No era un único paquete envenenado, esperando que alguien lo descargara. Era algo que, una vez dentro de un entorno, buscaba credenciales, las robaba, y las usaba para infectar otros paquetes y seguir propagándose por su cuenta, como un gusano. El primero de su tipo en ese ecosistema.\nLa puerta de entrada, y este es el detalle más revelador de todos, no fue una vulnerabilidad técnica sofisticada. Fue un engaño. Los atacantes montaron una campaña de correos falsos, imitando al sitio oficial de npm con un dominio que se le parecía mucho, y le pidieron a los mantenedores de paquetes que \u0026ldquo;actualizaran\u0026rdquo; su segundo factor de autenticación. Algunos cayeron, entregaron sus credenciales, y con eso los atacantes pudieron publicar versiones maliciosas de paquetes legítimos, populares, en los que miles de proyectos confían. Entre los afectados hubo bibliotecas muy usadas. No hizo falta romper ninguna cerradura sofisticada: alcanzó con convencer a alguien de que entregara la llave.\nNo me interesa entrar en los detalles técnicos del ataque —hay gente que sabe muchísimo más que yo sobre eso, y ya escribió análisis excelentes—. Me interesa el patrón, porque el patrón es el que perdura cuando este incidente puntual quede olvidado. Y el patrón es viejo, mucho más viejo que npm: atacar el eslabón de confianza en lugar de atacar la fortaleza.\nLa montaña de confianza sobre la que estamos parados # Damos por sentado, sin pensarlo nunca, que el software moderno se construye sobre una base de confianza descomunal. Cada vez que sumamos una dependencia a un proyecto, estamos confiando en mucha gente a la vez: en quien escribió ese paquete, en que no metió nada malicioso, en que lo mantiene con cuidado, en que su cuenta no fue comprometida, en que las dependencias de su paquete son igual de confiables, y así hacia abajo, niveles y niveles de confianza encadenada que nadie verifica en su totalidad porque sería, literalmente, imposible.\nEsto no es un defecto del sistema; es el sistema. La razón por la que hoy podemos construir en semanas cosas que antes llevaban años es justamente que no tenemos que escribir todo desde cero. Nos paramos sobre el trabajo de miles de personas que resolvieron, antes que nosotros, problemas que ya no necesitamos volver a resolver. El código abierto, el ecosistema de paquetes compartidos, esa enorme biblioteca común de la humanidad técnica, es una de las cosas más extraordinarias que produjo nuestra industria. Y funciona, fundamentalmente, porque confiamos. La confianza es el combustible que hace que todo esto ande.\nPero acá está el filo de la navaja, y es lo que el ataque de este mes vuelve a poner sobre la mesa: esa misma confianza, que es nuestra mayor fortaleza, es también nuestra mayor vulnerabilidad. Cada relación de confianza es un camino. Y un camino que sirve para que nos llegue valor sirve, exactamente igual, para que nos llegue daño. No se puede tener uno sin el otro. La apertura que nos permite recibir lo bueno es la misma apertura por la que puede entrar lo malo. No hay una versión del sistema que conserve toda la velocidad y elimine todo el riesgo, porque la velocidad y el riesgo vienen, en buena medida, de la misma fuente.\nAtacar la confianza, no la fortaleza # Lo que más me quedó dando vueltas de este incidente es que el ataque no fue contra la tecnología, sino contra la confianza. Los atacantes no encontraron una falla brillante en el código de npm; encontraron a una persona y la engañaron. Y eso conecta con algo que escribí hace más de un año, cuando hablé de la caída asociada a CrowdStrike: que el riesgo tecnológico no siempre tiene un atacante del otro lado, y que muchas veces el problema no es la fortaleza de nuestros muros sino la cantidad de puertas que ni sabíamos que teníamos abiertas.\nAcá hay un atacante, sí, pero la lógica es parecida. El eslabón más débil de una cadena de confianza casi nunca es el más técnico; es el más humano, el más descuidado, el que confiábamos tanto que dejamos de mirar. Una cuenta de un mantenedor que reutilizó una contraseña. Una persona apurada que hizo clic en un correo que parecía legítimo. Un paquete que usábamos hace años y que nunca nos dio problemas, y que por eso mismo dejamos de vigilar. El atacante inteligente no va contra lo que está bien protegido; va contra lo que damos por seguro justamente porque nunca falló. La confianza acumulada, no cuestionada, es la superficie de ataque más grande y la peor mapeada que tenemos.\nLa paradoja del paquete que nunca falló # Hay una idea que vengo repitiendo en varios posts y que este ataque vuelve a confirmar desde otro ángulo: las dependencias más confiables son, por eso mismo, las que peor vigilamos. Cuanto mejor funciona un paquete, más invisible se vuelve. Lo instalamos una vez, anduvo, y a partir de ahí dejó de existir en nuestra cabeza. Pasó a ser parte del paisaje, como el aire. Y cuando algo se vuelve invisible, deja de ser objeto de atención, de revisión, de sospecha sana.\nEl ataque de este mes explotó exactamente eso. Las versiones maliciosas se publicaron sobre paquetes legítimos y populares, paquetes en los que la gente confiaba precisamente porque tenían un largo historial de comportarse bien. Nadie revisa con lupa la nueva versión de una biblioteca que viene funcionando impecablemente desde hace años; la actualizamos casi por reflejo, porque siempre estuvo todo bien. Esa actualización automática, ese reflejo de confiar en lo que nunca falló, fue el vector. La confiabilidad histórica se convirtió en la herramienta del ataque. Y esto debería darnos que pensar más allá de npm, porque el patrón es universal: en toda organización hay piezas, internas y externas, que dejamos de mirar precisamente porque nunca nos dieron un problema. Su buen comportamiento se transformó, sin que lo decidiéramos, en una excusa para la complacencia.\nNo se trata de desconfiar de todo # Ahora bien, sería fácil sacar de todo esto la conclusión equivocada: desconfiemos de todo, revisemos cada línea de cada dependencia, volvamos a escribir todo desde cero. Eso sería absurdo, además de imposible. Nadie puede auditar las cientos de dependencias de un proyecto moderno, y una organización que intentara hacerlo se paralizaría y perdería frente a las que siguen avanzando. La desconfianza total no es una estrategia; es una forma de suicidio competitivo. El valor de apoyarnos en el trabajo de otros es demasiado grande como para renunciar a él por miedo.\nLa respuesta madura, creo, no está en desconfiar de todo ni en confiar ciegamente, sino en un lugar incómodo del medio: confiar, pero de manera consciente y gestionada. Saber de qué dependemos, aunque no podamos auditarlo todo. Tener idea de cuáles de nuestras dependencias son críticas y cuáles son accesorias, porque no todas merecen el mismo nivel de cuidado. Entender que actualizar no es un acto neutro y gratuito, sino una decisión que introduce algo nuevo en lo que confiamos. Tener mecanismos para reaccionar rápido cuando algo se descubre comprometido, porque algo, tarde o temprano, se va a descubrir comprometido. No es eliminar la confianza; es dejar de tratarla como si fuera gratis e infinita.\nLa velocidad tiene un costo que no figura en la factura # Hay algo que conecta este tema con cosas que vengo pensando hace meses sobre la velocidad. Todo el ecosistema de paquetes está optimizado para ir rápido: instalar en segundos, actualizar sin fricción, sumar una dependencia con un solo comando. Esa velocidad es maravillosa, y nadie quiere renunciar a ella. Pero tiene un costo que no aparece en ningún lado en el momento, igual que el costo energético de un modelo de IA no aparece en el dashboard: el costo de la superficie de confianza que vamos acumulando sin darnos cuenta.\nCada dependencia que sumamos por comodidad, cada actualización que aceptamos sin mirar, cada herramienta que conectamos \u0026ldquo;porque es más rápido\u0026rdquo;, agranda un poquito la cantidad de cosas en las que confiamos sin verificar. Individualmente, cada decisión parece inofensiva, casi trivial. Acumuladas, construyen una exposición que solo se vuelve visible el día que algo falla. Es la misma lógica de la deuda: cada atajo es chiquito, pero la suma de atajos, con el tiempo, se vuelve una cuenta que alguien tiene que pagar. Y como en toda deuda, el problema no es tomarla —a veces tiene todo el sentido del mundo— sino tomarla sin saber que la estamos tomando, sin registrarla, sin tener idea de cuánto debemos.\nY ahora le sumamos agentes a la ecuación # Hay un giro que no quiero dejar pasar, porque conecta este tema con algo que vengo siguiendo todo el año. Hasta acá hablé de la confianza que extendemos como personas: nosotros sumamos una dependencia, nosotros aceptamos una actualización, nosotros hacemos clic en el correo. Pero estamos entrando en una etapa en la que cada vez más de esas decisiones las toman agentes de IA que trabajan por nosotros. Un agente que explora un repositorio, instala dependencias, corre comandos y resuelve una tarea de punta a punta está, sin que lo pensemos demasiado, extendiendo confianza en nuestro nombre, a una velocidad y una escala que ninguna persona podría igualar.\nCuando escribí sobre los agentes que empiezan a trabajar de verdad, insistí en que la capacidad había crecido y que por eso las barandas importaban más, no menos. Este ataque le agrega una dimensión concreta a esa idea. Si un agente instala paquetes por su cuenta, ¿qué pasa cuando uno de esos paquetes está comprometido? Si un agente tiene acceso a credenciales para hacer su trabajo, ¿qué superficie nueva estamos abriendo? La confianza implícita de la cadena de suministro, que ya era enorme cuando la gestionábamos nosotros a mano, se multiplica cuando le sumamos automatización que decide rápido y a escala. No es que los agentes inventen el problema; es que lo amplifican, porque hacen más rápido y más seguido exactamente eso que ya era riesgoso: confiar sin verificar.\nNo traigo esto para asustar, sino porque me parece el lugar exacto donde dos hilos del año se cruzan. Por un lado, los agentes que ejecutan acciones reales en nuestros sistemas. Por el otro, una cadena de suministro que se sostiene sobre confianza y que acaba de demostrar lo frágil que puede ser esa confianza. Juntar las dos cosas sin pensarlo —darle a un agente autónomo las llaves para sumar dependencias, instalar, ejecutar, sin límites ni registro— es combinar dos formas de confiar de más en un mismo movimiento. Y la respuesta, otra vez, no es prohibir ninguna de las dos, sino la misma de siempre: conciencia, límites, trazabilidad. Saber qué le permitimos a un agente, qué puede tocar, qué confianza está extendiendo por nosotros mientras nosotros miramos para otro lado. El arnés del que hablé en mayo y la confianza gestionada de la que hablo hoy son, en el fondo, la misma idea aplicada a dos caras del mismo problema.\nNo soy un experto en seguridad, y este post no pretende serlo. Pero sí soy alguien que decide, todos los días, sobre qué construir y sobre qué apoyarse, y desde ese lugar el ataque de este mes me deja algunas cosas. La primera es un recordatorio de humildad: dependemos de muchísimo más de lo que controlamos, y fingir lo contrario no nos hace más seguros, solo más ciegos. Reconocer la magnitud de nuestra confianza es el primer paso para gestionarla con algo de criterio.\nLa segunda es que la conversación sobre dependencias y confianza no debería ser solo un tema de los equipos de seguridad, relegado a un rincón especializado. Es una conversación de cultura técnica, de criterio, de cómo decidimos qué incorporar y qué no, de cuándo vale la pena la comodidad de sumar algo y cuándo no. Esas decisiones las tomamos todos, todo el tiempo, muchas veces sin pensarlas como decisiones. Hacerlas un poco más conscientes —preguntarnos, aunque sea un segundo, qué confianza nueva estamos extendiendo cada vez que sumamos algo— ya es un avance enorme respecto de la inercia de sumar por sumar.\nY la tercera, la que más me importa, es una idea que excede al software y que me parece el verdadero residuo perdurable de todo esto. En cualquier sistema complejo —técnico, humano, organizacional— la confianza es lo que lo hace funcionar y, al mismo tiempo, su punto más delicado. No podemos vivir sin confiar; sería paralizante e inhumano. Pero la confianza que dejamos de cuidar, que damos por sentada, que tratamos como si fuera infinita y gratuita, es exactamente la que algún día nos va a costar caro. No porque confiar esté mal, sino porque confiar sin conciencia es, en el fondo, no haber pensado en quién tiene las llaves de nuestra casa.\nLes dejo una pregunta para que la lleven a su propio terreno, porque seguro tienen su propia montaña de dependencias sin mirar. Si tuvieran que nombrar las piezas de software, los proveedores o los servicios en los que su sistema confía ciegamente —esos que nunca revisan justamente porque nunca fallaron—, ¿cuántos podrían nombrar, y cuántos descubrirían recién el día en que uno de ellos deje de merecer esa confianza? Porque la confianza que no se mira no desaparece. Solo espera, en silencio, el día en que alguien decida aprovecharla.\nFuentes consultadas # Wiz Research, \u0026ldquo;Shai-Hulud: npm supply chain attack\u0026rdquo;, 16 de septiembre de 2025. The Hacker News, \u0026ldquo;Self-Replicating Worm Hits 180+ npm Packages to Steal Credentials\u0026rdquo;, 22 de septiembre de 2025. CISA, \u0026ldquo;Widespread Supply Chain Compromise Impacting npm Ecosystem\u0026rdquo;, 23 de septiembre de 2025. ","date":"25 de septiembre de 2025","externalUrl":null,"permalink":"/blog/post-cuando-la-confianza-es-la-vulnerabilidad/","section":"Blog","summary":"El software moderno se construye sobre una montaña de confianza implícita: confiamos en miles de paquetes que nunca leímos, escritos por gente que no conocemos. Esa confianza es lo que nos permite avanzar rápido, y también lo que un atacante puede convertir en arma. Lo que pasó en npm este mes no es solo un problema de seguridad: es un recordatorio incómodo sobre las dependencias que aceptamos sin pensar.","title":"Cuando la confianza es la vulnerabilidad","type":"blog"},{"content":"","date":"25 de septiembre de 2025","externalUrl":null,"permalink":"/tags/riesgo/","section":"Tags","summary":"","title":"Riesgo","type":"tags"},{"content":"Hay una figura que la industria del software venera desde hace décadas: el programador 10x. Esa persona casi mítica que, dicen, produce diez veces más que un desarrollador promedio, que resuelve en una tarde lo que a otros les lleva una semana, que parece tener un cable directo entre el cerebro y el teclado. La buscamos al contratar, la premiamos cuando creemos haberla encontrado, organizamos equipos enteros alrededor de ella. Y yo mismo, en mis primeros años, caí en ese encantamiento: pensaba que un buen equipo era, sobre todo, una colección de personas muy buenas individualmente. Con el tiempo, y con bastantes cicatrices de por medio, fui cambiando de opinión. Vi equipos llenos de talento individual rendir mal, y vi equipos de gente \u0026ldquo;normal\u0026rdquo; lograr cosas extraordinarias. Y entendí algo que ahora me parece obvio pero que me costó años aceptar: el rendimiento de un equipo no es la suma de los rendimientos individuales. Hace poco, leyendo un libro sobre liderazgo que no tiene nada que ver con programación, me encontré con esa misma idea formulada con una claridad que me dieron ganas de discutirla acá.\nEl encanto y la trampa del 10x # Empecemos por ser justos con la idea, porque tiene su parte de verdad. Sí existen personas extraordinariamente productivas. Hay desarrolladores que, por talento, experiencia o forma de pensar, resuelven problemas con una velocidad y una elegancia que asombran. Negar eso sería ridículo. El problema no es reconocer que esa gente existe; el problema es lo que construimos alrededor de esa creencia, y las conclusiones equivocadas que sacamos de ella.\nLa primera trampa es de medición. Cuando decimos que alguien \u0026ldquo;produce diez veces más\u0026rdquo;, ¿qué estamos midiendo exactamente? Casi siempre, sin darnos cuenta, medimos lo más fácil de contar: líneas de código, features cerradas, tickets resueltos, velocidad visible. Pero esas métricas capturan una parte chiquita de lo que hace valioso a alguien en un equipo, y dejan afuera lo más importante. No miden si ese código se puede mantener, si otros lo entienden, si esa persona dejó al equipo mejor o peor que como lo encontró. Un desarrollador puede cerrar el doble de tickets que sus compañeros y, al mismo tiempo, generar el triple de trabajo futuro para todos los demás. Eso no es ser 10x; es trasladar el costo hacia adelante y hacia los costados, donde nadie lo está contando.\nLa segunda trampa es más sutil y más cara: organizar un equipo alrededor de sus estrellas suele debilitarlo. Cuando todo gira en torno a una o dos personas brillantes, el equipo se vuelve frágil. El conocimiento se concentra, las decisiones dependen de pocos, y el día que esa persona se va de vacaciones, se enferma o renuncia, descubrimos cuánto dependíamos de ella. Lo escribí hace unos meses hablando de las dependencias invisibles, y vale igual para las personas: una dependencia crítica que vive en la cabeza de un solo individuo es un riesgo, no una fortaleza, por más brillante que sea ese individuo.\nDe dónde salió ese número, y por qué importa # Vale la pena detenerse un segundo en el propio número, porque dice algo sobre cómo construimos nuestras certezas. La idea del 10x viene de un estudio de fines de los años sesenta que encontró grandes diferencias de productividad entre programadores. Lo curioso es que ese estudio ni siquiera había sido diseñado para medir eso: buscaba comparar dos formas de programar de la época, y la variabilidad entre personas apareció casi como un hallazgo lateral. Sobre esa base, y sobre un puñado de mediciones igual de viejas, se edificó toda una mitología: el ingeniero diez veces mejor, casi una categoría de ser humano aparte. El problema es que esas mediciones se hicieron sobre tareas individuales y aisladas, con lenguajes y condiciones que no se parecen en nada a cómo se construye software hoy, en equipo, sobre sistemas que viven años. Tomar una medición de laboratorio sobre tareas chicas y convertirla en una teoría sobre el valor de las personas en una organización es un salto enorme, y lo dimos casi sin pensarlo.\nNo traigo esto para negar que haya diferencias de talento —las hay, evidentes— sino para señalar lo fácil que es que un dato descontextualizado se vuelva dogma. El 10x dejó de ser una observación acotada sobre rendimiento individual y pasó a ser una forma de mirar el mundo: contratamos buscando a esa persona, diseñamos procesos de selección para detectarla, estructuramos incentivos para premiarla. Construimos prácticas enteras sobre una métrica que mide lo más fácil de medir y que ignora casi todo lo que de verdad pasa en un equipo. Es, en el fondo, el mismo error que critiqué cuando hablé de elegir modelos de IA por su potencia: confundir lo que es fácil de cuantificar con lo que es importante. Lo medible nos seduce justamente porque es medible, y terminamos optimizando para el número en lugar de para el resultado.\nY hay una ironía linda en todo esto, que conviene no perder de vista. Muchas de las personas que de verdad merecerían el rótulo de 10x —si insistiéramos en usarlo— no lo son por la cantidad de código que escriben, sino por cuánto elevan a quienes los rodean. El multiplicador real, cuando existe, casi nunca está en el output propio; está en el efecto sobre los demás. Pero ese efecto es justamente lo que las métricas individuales no ven, y por eso esas personas suelen pasar más desapercibidas que el que cierra muchos tickets ruidosamente. Premiamos el brillo visible y nos perdemos el multiplicador silencioso.\nDespués de años de mirar equipos por dentro, llegué a una conclusión que va a contramano de buena parte de la mitología técnica: las personas más valiosas de un equipo no son siempre las que más producen, sino las que hacen que el equipo entero produzca mejor. Y casi nunca son las mismas.\nPienso en esa persona que no es la más rápida escribiendo código, pero que desbloquea a tres compañeros por día respondiendo dudas, explicando una parte del sistema, evitando que alguien se meta en un pozo. En esa que documenta lo que nadie quiere documentar, que deja el camino allanado para el que venga después. En la que hace buenas revisiones, no para lucirse encontrando errores, sino para que el código que entra sea mejor y para que los demás aprendan en el proceso. En la que tiene la honestidad de decir \u0026ldquo;esto no lo entiendo\u0026rdquo; en una reunión, y al hacerlo le da permiso a otros cuatro que tampoco entendían para preguntar. Ninguna de esas contribuciones aparece bien en las métricas de productividad individual. Todas son, en mi experiencia, lo que separa a un equipo que funciona de uno que apenas sobrevive.\nHay una palabra que resume buena parte de esto y que en software solemos subestimar: coordinación. Gran parte de lo que hace o deshace a un equipo no pasa dentro de la cabeza de cada uno, sino en el espacio entre las personas: cómo se comunican, cómo se reparten el trabajo sin pisarse, cómo comparten lo que saben, cómo manejan los desacuerdos. Un equipo de cinco personas excelentes que coordinan mal rinde peor que un equipo de cinco personas buenas que coordinan bien. Lo vi tantas veces que ya dejó de sorprenderme, aunque sigue costándome convencer a otros de que es así, porque va contra la intuición de que basta con juntar a los mejores.\nLo que dice un libro de CEOs, y por qué me interesó # Hace poco leí CEO Excellence, de Carolyn Dewar, Scott Keller y Vikram Malhotra, tres socios de McKinsey que entrevistaron a decenas de los CEOs más exitosos del mundo para entender qué los distinguía del resto. No es un libro sobre programación ni sobre equipos técnicos; es un libro sobre liderazgo al más alto nivel. Y sin embargo, varias de sus ideas me resultaron sorprendentemente aplicables a lo que veo todos los días conduciendo equipos de desarrollo, mucho más que muchos libros escritos específicamente sobre gestión técnica.\nUna de las autoras lo resume en una frase que, cuando la leí, sentí que describía exactamente lo que me costó años entender. Dice, hablando de los grandes CEOs: \u0026ldquo;Muchos directores ejecutivos se concentran en conseguir líderes individuales que sean excelentes en sus roles. Los CEOs excelentes se concentran más en la dinámica entre ellos, en la psicología del equipo y en cómo trabajan juntos.\u0026rdquo; La traducción es mía, pero la idea está clarísima: el foco de los mejores no está en armar una colección de cracks, sino en cómo esos cracks funcionan como conjunto. Y en el libro hay otra formulación que va en la misma dirección, casi como un lema: los mejores piensan menos en qué hace el equipo en conjunto, y más en cómo trabaja el equipo en conjunto.\nMe detengo en esa distinción —qué hace versus cómo trabaja— porque me parece la clave de todo. La mayoría de nosotros, cuando pensamos en mejorar un equipo, pensamos en el qué: qué tareas, qué tecnologías, qué objetivos, qué entregables. Es lo concreto, lo medible, lo que se pone en un tablero. El cómo —la dinámica, la confianza, la forma de comunicarse y decidir— es más difuso, más difícil de medir, y por eso lo descuidamos. Pero es ahí, según el libro y según mi experiencia, donde se juega la diferencia real. Los mejores líderes invierten en el cómo, aunque sea menos vistoso, porque saben que el qué se resuelve solo cuando el cómo está sano.\nUn dato que me hizo ruido # El libro trae un dato que me quedó dando vueltas, y que conviene mirar con cuidado porque es revelador. Cuentan que apenas alrededor del 6% de los altos ejecutivos de recursos humanos —gente cuyo trabajo, justamente, incluye cuidar que el trabajo en equipo funcione— está de acuerdo con que su propio equipo directivo opera como un equipo bien integrado. Y que cuando se les pide evaluar qué tan bien trabaja su equipo en relación con su potencial, lo puntúan apenas un cinco sobre diez. Estamos hablando de los equipos del tope de las organizaciones más grandes del mundo, gente con todos los recursos a disposición, y aun así la mitad del potencial de trabajo conjunto se está quedando sobre la mesa.\nLos autores sacan una conclusión que para mí es el corazón del asunto: la razón de esas dificultades no suele estar en los miembros individuales del equipo, sino en la dinámica de cómo el equipo trabaja en conjunto. O sea, no es un problema de gente; es un problema de cómo esa gente funciona junta. Y si esto pasa en los equipos directivos de las empresas más poderosas, donde sobra talento individual, ¿por qué supondríamos que en nuestros equipos de desarrollo el talento individual alcanza? Si juntar gente brillante fuera suficiente, esos equipos del tope rendirían diez sobre diez, no cinco. Algo más está en juego, y ese algo es el cómo.\nLlevarlo a nuestro terreno: del CEO al líder técnico # Acá quiero hacer el ejercicio de traducir esto al mundo concreto en el que me muevo, porque una cosa es la idea elegante de un libro y otra es qué significa el lunes a la mañana frente a un equipo de desarrollo. Si los mejores líderes se enfocan en el cómo más que en el qué, ¿qué implica eso para alguien que conduce gente que escribe software?\nImplica, para empezar, dejar de obsesionarse con encontrar y retener estrellas, y empezar a obsesionarse con cómo funciona el conjunto. No significa que el talento individual no importe —importa, y mucho— sino que no alcanza, y que muchas veces ni siquiera es el factor decisivo. Implica prestarle atención a cosas que el reflejo técnico tiende a ignorar: si la gente comparte lo que sabe o lo acapara, si hay confianza para decir \u0026ldquo;no sé\u0026rdquo; o todos disimulan, si las decisiones se discuten sano o se imponen, si el conocimiento está distribuido o concentrado en pocas cabezas. Implica valorar y hacer visible al que desbloquea a otros, al que documenta, al que enseña, aunque su nombre no aparezca primero en las métricas de output. Y, sobre todo, implica entender que mi trabajo como líder no es maximizar la producción de cada individuo por separado, sino diseñar las condiciones para que el equipo entero trabaje mejor en conjunto. Son dos trabajos distintos, y confundirlos lleva a optimizar lo que se ve a costa de lo que importa.\nCómo cambia esto a quién sumamos y a quién premiamos # Esta forma de mirar tiene consecuencias muy concretas en dos momentos donde un líder técnico deja su huella más profunda: a quién suma al equipo y a quién reconoce una vez que está adentro. Si uno cree en el mito del 10x, contrata buscando al individuo más brillante posible, y evalúa después premiando al que más produce. Si uno entiende que el rendimiento es del conjunto, las dos cosas cambian.\nEn la contratación, dejé de preguntarme solamente \u0026ldquo;¿qué tan bueno es esta persona?\u0026rdquo; y empecé a preguntarme también \u0026ldquo;¿qué le va a hacer a la dinámica de este equipo?\u0026rdquo;. Hay gente técnicamente excelente que, sumada a un equipo, lo empeora: acapara conocimiento, desprecia a los demás, convierte cada discusión en una competencia. Y hay gente de habilidad más modesta que eleva todo lo que toca, porque genera confianza, comparte, destraba. Durante años contraté mirando casi solo la primera dimensión, la del talento puro, y aprendí a los golpes que un crack tóxico puede costar más caro que lo que aporta, porque el daño que hace al cómo del equipo se paga en todos los demás. Hoy le doy tanto peso a cómo alguien va a funcionar con otros como a qué tan bueno es a solas. No más, pero tampoco menos.\nEn la evaluación pasa algo parecido y, si se quiere, más delicado, porque es donde más fácil es equivocarse sin darse cuenta. Si solo premio output visible, le estoy mandando al equipo un mensaje clarísimo: lo que importa es tu producción individual, no lo que hacés por los demás. Y la gente, razonablemente, responde a los incentivos: si ayudar al otro no se reconoce, ayudar al otro se vuelve tiempo perdido. Así, sin querer, un sistema de evaluación mal pensado puede destruir exactamente el cómo que tanto nos cuesta construir. Por eso trato de hacer visible y de valorar explícitamente lo que no aparece en las métricas: la mentoría, la documentación, las buenas revisiones, el desbloqueo silencioso. No porque sea simpático reconocerlo, sino porque si no lo reconozco, lo estoy desincentivando. Lo que un líder premia es lo que el equipo va a hacer más, y conviene tener mucho cuidado con qué estamos premiando sin darnos cuenta.\nSería deshonesto presentar todo esto sin reconocer sus matices, porque la idea, llevada al extremo, también tiene riesgos, y no me gustan los posts que defienden una tesis sin mirarle las costuras. Hay un peligro real en sobrecorregir: en nombre del \u0026ldquo;trabajo en equipo\u0026rdquo;, se puede caer en el exceso de reuniones, en la dilución de responsabilidades, en el consenso permanente que no decide nada, en castigar implícitamente al que rinde mucho para no \u0026ldquo;romper la armonía\u0026rdquo;. El equipo como excusa para la mediocridad es tan dañino como la estrella como excusa para la fragilidad. No estoy proponiendo eso, ni cerca.\nEl propio libro, de hecho, no plantea que el cómo reemplace al qué, sino que lo potencia. Un equipo que trabaja bien en conjunto pero no tiene gente capaz no llega a ningún lado; la dinámica sana no compensa la falta de competencia. La idea no es elegir entre talento individual y trabajo en equipo, sino entender que el segundo es lo que permite que el primero rinda de verdad. Una estrella en un equipo disfuncional brilla poco y dura menos; la misma estrella en un equipo que coordina bien multiplica su impacto y, de paso, eleva a los demás. El talento individual es el combustible; el cómo trabaja el equipo es el motor. Sin combustible no andás, pero el combustible sin motor tampoco te lleva a ningún lado. El error histórico de nuestra industria fue enamorarse del combustible y descuidar el motor.\nLo que cambió en mí # Si miro hacia atrás, el cambio más grande en mi forma de liderar no fue aprender una metodología nueva ni dominar una herramienta. Fue correr el foco. Pasé de preguntarme \u0026ldquo;¿cómo consigo y retengo a los mejores individuos?\u0026rdquo; a preguntarme \u0026ldquo;¿cómo hago para que este grupo de personas, con sus virtudes y sus límites, trabaje mejor en conjunto?\u0026rdquo;. Parece un cambio chico, casi semántico, pero en la práctica reordena todo: qué mirás, qué premiás, en qué invertís tu tiempo, qué considerás un problema y qué considerás un éxito.\nY descubrí algo que no esperaba: cuando el cómo está sano, el talento individual florece más, no menos. La gente buena rinde mejor en un equipo que funciona, porque no tiene que pelear contra la fricción, porque confía, porque puede concentrarse en lo suyo sabiendo que el resto está cubierto. Cuidar el cómo no es bajar la vara del talento; es crear el suelo donde el talento puede crecer. Por eso me resulta tan valioso que un libro sobre los CEOs más exitosos del mundo termine, después de cientos de entrevistas, en la misma conclusión a la que llegué yo a los tropezones desde un lugar mucho más humilde: que lo que distingue a los grandes no es rodearse de individuos brillantes, sino lograr que trabajen brillantemente juntos.\nLes dejo una pregunta para que la lleven a su propio equipo, porque creo que el reflejo del 10x está más metido en todos nosotros de lo que admitimos. La próxima vez que evalúen quién es la persona más valiosa de su equipo, ¿van a mirar quién produce más, o quién hace que todos los demás produzcan mejor? Porque casi nunca son la misma persona, y la diferencia entre reconocer a una o a la otra dice más sobre la madurez de quien lidera que sobre el talento de quien es reconocido.\nFuentes consultadas # Carolyn Dewar, Scott Keller y Vikram Malhotra, CEO Excellence: The Six Mindsets That Distinguish the Best Leaders from the Rest, Simon \u0026amp; Schuster, marzo de 2022. McKinsey \u0026amp; Company, \u0026ldquo;Quote of the Day — Carolyn Dewar on CEO Excellence\u0026rdquo;, 1 de marzo de 2022. Extracto de CEO Excellence publicado en \u0026ldquo;CEO Excellence: Make Your Team the Star\u0026rdquo;, StartupNation, marzo de 2022. ","date":"20 de agosto de 2025","externalUrl":null,"permalink":"/blog/post-el-mito-del-10x/","section":"Blog","summary":"Vivimos enamorados del programador 10x, esa figura que produce como diez. Pero después de muchos años liderando equipos, aprendí que el rendimiento de un equipo no es la suma de los rendimientos individuales, y que muchas veces la persona más valiosa no es la que más código escribe. Apoyándome en algunas ideas de CEO Excellence, quiero discutir por qué el foco debería correrse de qué hace cada uno hacia cómo trabajamos juntos.","title":"El mito del 10x: por qué el mejor del equipo no siempre es el que más produce","type":"blog"},{"content":"","date":"20 de agosto de 2025","externalUrl":null,"permalink":"/tags/equipos/","section":"Tags","summary":"","title":"Equipos","type":"tags"},{"content":"","date":"20 de agosto de 2025","externalUrl":null,"permalink":"/tags/productividad/","section":"Tags","summary":"","title":"Productividad","type":"tags"},{"content":"En marzo escribí sobre el vibe coding en pleno auge, cuando el término estaba en todos lados y costaba pensar con la cabeza fría en medio de tanto entusiasmo. Decía entonces que me había deslumbrado y asustado el mismo día, y dejaba varias preguntas abiertas, porque me parecía apresurado sacar conclusiones a tres semanas de que el concepto existiera. Pasaron cuatro meses. No es mucho tiempo, lo sé, pero en un campo que se mueve a esta velocidad, cuatro meses alcanzan para que baje un poco la espuma y empiece a verse qué hay debajo. Y eso es lo que quiero hacer acá: un balance honesto, a mitad de año, de un fenómeno que parecía que iba a cambiarlo todo. No para declararlo muerto ni para coronarlo como la revolución definitiva —las dos cosas me parecen igual de perezosas— sino para preguntarme algo más útil: cuando se apaga el ruido, ¿qué queda? Porque creo que ahí, en el residuo que sobrevive al hype, está siempre la parte que de verdad importa.\nEl ciclo de siempre, otra vez # Si uno lleva suficientes años en tecnología, aprende a reconocer un patrón que se repite con cada novedad que llega prometiendo cambiarlo todo. Primero está la euforia: la herramienta nueva lo va a resolver todo, va a hacer obsoleto lo anterior, quien no la adopte ya se quedó atrás. Después llega el momento en que la realidad empieza a poner las cosas en su lugar, aparecen los problemas que el entusiasmo no dejaba ver, y el péndulo se va hacia el otro extremo: era todo humo, no servía para nada, otra moda más. Y recién mucho después, cuando ya nadie escribe titulares sobre el tema, se asienta lo razonable: la herramienta sirve para algunas cosas, no para otras, y encontró su lugar.\nEl vibe coding está transitando ese ciclo, y a una velocidad que asusta. En febrero era un término nuevo; en marzo, cuando escribí, estaba en su pico de euforia; y ahora, a mitad de año, empiezo a percibir el principio de la corrección. No el rechazo total todavía, pero sí las primeras señales de que la realidad está cobrando sus cuentas. Lo interesante de haber escrito en pleno auge y volver ahora es que puedo comparar lo que intuía entonces con lo que se está viendo, y revisar honestamente en qué acerté, en qué me quedé corto y en qué el tiempo todavía no dio su veredicto.\nLo que se está cayendo # Empecemos por lo que el entusiasmo prometía y la realidad está desinflando. La promesa más fuerte del vibe coding, la que más circuló, era una versión de \u0026ldquo;cualquiera puede construir software ahora, sin saber programar, solo describiéndole a la IA lo que quiere\u0026rdquo;. Y esa promesa, llevada a su extremo, se está cayendo. No porque la herramienta no funcione —funciona, y sorprende— sino porque construir algo que parece andar y construir algo que se sostiene en producción resultaron ser, como muchos sospechábamos, dos cosas muy distintas.\nLo que empieza a verse, a medida que esos proyectos vibe-codeados maduran o intentan crecer, es exactamente lo que temía en marzo. Aparecen los problemas de seguridad en código que nadie revisó a fondo. Aparece la dificultad de mantener o extender sistemas que nadie entiende del todo, porque nacieron de conversaciones que ya no existen. Aparece el momento incómodo en que algo falla de una manera que la IA sola no puede resolver, y el que tiene que arreglarlo descubre que no entiende lo que está tocando. Hay datos que empiezan a confirmar esto: ya a principios de año, análisis sobre código asistido por IA mostraban que la velocidad de generación venía acompañada de un aumento de los riesgos de seguridad, sobre todo en lo que más cuesta detectar, que son los problemas estructurales y no los errores de sintaxis. La IA arregla las erratas y, si una no presta atención, planta los problemas profundos. Y este mismo mes empezaron a aparecer casos concretos de aplicaciones construidas con estas herramientas que terminaron expuestas por configuraciones de seguridad que nadie miró. No son catástrofes globales, pero son recordatorios.\nLo que se cae, entonces, no es la herramienta. Es la fantasía de que la herramienta eliminaba la necesidad de entender. Esa idea de que el conocimiento técnico se había vuelto opcional, de que el criterio era un lujo del pasado, de que bastaba con describir y aceptar. Eso es lo que la realidad está corrigiendo, y la corrección era previsible, porque esa fantasía no era nueva: es la misma que acompañó a cada herramienta que prometió hacer innecesario el oficio, y que cada vez terminó demostrando que lo desplazaba, no lo eliminaba.\nLo que quedó # Pero sería injusto y, peor, poco útil quedarme solo en lo que se cayó. Porque debajo del hype había algo real, y eso es lo que me interesa rescatar. El vibe coding, despojado de la promesa exagerada, dejó un puñado de cosas que llegaron para quedarse, y que ya cambiaron cómo trabajamos muchos de nosotros.\nLo primero que quedó es la velocidad de exploración. La capacidad de ir de una idea a un prototipo que funciona en minutos, sin la fricción de antes, es real y es valiosísima. No reemplaza la construcción seria de software, pero transformó la fase de explorar y validar ideas. Hoy puedo probar un enfoque, descartarlo, probar otro, todo en el tiempo que antes me llevaba configurar el entorno. Eso no se va a ir; al contrario, se va a profundizar. Lo que aprendimos no es que el vibe coding sirva para todo, sino que para prototipar y explorar es extraordinario, y que conviene tenerlo en la caja de herramientas para exactamente eso.\nLo segundo que quedó, y es quizás lo más interesante, es una revalorización inesperada de cosas que la industria había empezado a despreciar. El vibe coding, al fallar donde falla, nos recordó por qué importan la revisión, la documentación, la arquitectura clara, el versionado de las decisiones, la comprensión real de lo que construimos. Paradójicamente, la herramienta que prometía hacer innecesaria la disciplina terminó siendo el mejor argumento a favor de la disciplina. Cuando ves de cerca lo que pasa sin ella, entendés por qué estaba ahí. Es como esas reglas que parecen burocráticas hasta que alguien las saca y todo se rompe.\nY lo tercero, más sutil: quedó una conversación honesta sobre los límites. En marzo, hablar de los riesgos del vibe coding sonaba a aguafiestas en medio de la fiesta. Cuatro meses después, esa conversación se volvió normal, casi obvia. Mucha gente que se lanzó con entusiasmo ciego aprendió, a veces a los golpes, dónde están las fronteras. Y ese aprendizaje colectivo —saber para qué sí y para qué no— es un residuo valioso que no teníamos antes de toda esta experiencia. Las modas, cuando pasan, nos dejan más sabios sobre sus propios límites, siempre que hayamos prestado atención.\nEl residuo útil de las modas # Esto me lleva a una idea que excede al vibe coding y que es, en el fondo, de lo que más me interesa hablar. Las modas técnicas tienen mala fama, y en parte se la ganan, porque vienen envueltas en exageración, en promesas que no se cumplen, en ese ruido que empuja a adoptar cosas por miedo a quedarse afuera más que por necesidad real. Pero descartarlas en bloque, como hace el cínico que ya vio todo y de todo desconfía, es tan ingenuo como creerles todo. Porque casi siempre, debajo de la espuma, hay algo. Un grano de señal dentro del ruido.\nEl trabajo —y acá entra el criterio, que es lo que más valoro en alguien técnico con experiencia— es justamente separar ese grano del resto. No tragarse el hype entero ni rechazarlo entero, sino tener la paciencia de esperar a que baje la espuma y quedarse con lo que sobrevive. Lo vi pasar muchas veces a lo largo de los años, con tecnologías que prometieron revoluciones y dejaron, eso sí, una o dos prácticas que incorporamos para siempre. Casi ninguna moda cumple lo que promete; casi ninguna es completamente inútil. La verdad, como casi siempre, vive en ese territorio incómodo del medio, que es justo el que no genera titulares.\nY por eso me resisto, cada vez más, a opinar sobre las novedades en caliente. No porque no tenga opiniones, sino porque las opiniones en caliente casi siempre erran, para un lado o para el otro. El que en marzo declaraba que el vibe coding era la muerte de la programación tradicional se equivocó. El que lo declaraba un fraude sin valor también. Los dos opinaron rápido, sobre el ruido, antes de que hubiera con qué juzgar. El valor de esperar, de digerir, de volver cuatro meses después con la cabeza más fría, es que uno puede empezar a distinguir lo durable de lo efímero. No siempre, no con certeza, pero mejor que en el fragor del momento.\nEn qué acerté y en qué me quedé corto # Una de las ventajas de haber escrito en pleno auge y volver ahora es que puedo revisar mi propio texto sin piedad, que es un ejercicio que recomiendo y que poca gente hace. Releyendo lo que escribí en marzo, creo que acerté en lo central: que el problema no era la herramienta sino el criterio que abandonábamos, que el punto de quiebre estaba en el trabajo en equipo y en producción, que faltaba versionar la intención y no solo el código. Esas intuiciones se sostienen, y algunas se confirmaron antes de lo que esperaba.\nPero también me quedé corto en un par de cosas, y vale la pena decirlo. Subestimé la velocidad a la que el fenómeno se iba a profesionalizar, para bien y para mal: pensé que el vibe coding quedaría más confinado a prototipos y experimentos, y en estos meses vi que mucha gente lo empujó directo a producción con una audacia que no anticipé del todo. También fui, quizás, demasiado prudente con lo positivo: en marzo, rodeado de tanto entusiasmo, puse el acento en las advertencias, y hoy diría con más fuerza que la capacidad de prototipar a esta velocidad es una de las mejores cosas que le pasaron al desarrollo en años. El miedo a sonar ingenuo me hizo medir de más el elogio.\nReconocer esto no me incomoda; al contrario, lo siento parte del oficio. Quien escribe sobre tecnología en movimiento se va a equivocar seguido, porque está opinando sobre algo que todavía está pasando. Lo que distingue a una mirada seria no es no equivocarse nunca —imposible— sino tener la honestidad de volver, revisar lo dicho y ajustar. El que nunca revisa lo que afirmó tiempo atrás no es que acierte siempre; es que no se anima a mirar. Y en un campo donde todos opinamos constantemente sobre lo que recién está naciendo, esa disposición a corregirse vale más que cualquier predicción acertada por casualidad.\nProbarlo una vez no es haberlo adoptado # Hay una distinción que en marzo no estaba tan clara y que estos meses ayudaron a afilar: una cosa es probar una herramienta y otra muy distinta es haberla incorporado al flujo de trabajo. En el pico del entusiasmo, mucha gente probó el vibe coding una tarde, quedó deslumbrada, escribió sobre la experiencia y sumó al coro del \u0026ldquo;esto lo cambia todo\u0026rdquo;. Pero probar algo en una sesión aislada, sin las restricciones de un proyecto real, sin equipo, sin mantenimiento, sin la presión de que eso tiene que seguir funcionando dentro de seis meses, dice muy poco sobre su valor verdadero. La demo siempre brilla. El uso sostenido es el que revela.\nLo que se ve ahora, con un poco más de recorrido, es esa diferencia entre el deslumbramiento inicial y la adopción real. Algunos equipos integraron el vibe coding a su trabajo de manera sensata: lo usan para lo que sirve, lo evitan para lo que no, le pusieron reglas, lo combinaron con revisión. Otros lo probaron, se entusiasmaron, lo empujaron a donde no debían y ahora están lidiando con las consecuencias. Y muchos, simplemente, lo probaron un rato y volvieron a sus herramientas de siempre cuando la novedad se desgastó. Esa decantación —quién lo adoptó de verdad y para qué— es información que en marzo no existía y que hoy empieza a estar disponible. Y es muchísimo más reveladora que cualquier opinión escrita en la euforia, porque está hecha de uso real y no de primeras impresiones.\nMe parece que esta distinción, entre probar y adoptar, es una de las que más conviene tener presente con cualquier novedad. El ruido lo generan los que prueban y opinan rápido; la señal la dan, mucho más callados, los que incorporaron algo a su trabajo durante meses y pueden contar qué pasó de verdad. Cuando quiero entender si una herramienta nueva vale la pena, cada vez escucho menos a los que la probaron una vez y más a los que conviven con ella hace rato. Los primeros tienen entusiasmo; los segundos, experiencia. Y para juzgar, ya lo dije otras veces, la experiencia pesa más.\nLo que yo me llevo, a mitad de camino # Si tuviera que hacer mi balance personal, diría que el vibe coding me confirmó algo que ya sospechaba y que cada nueva herramienta vuelve a poner sobre la mesa: la tecnología cambia las herramientas, pero no elimina la necesidad de criterio. Al contrario, la desplaza. Antes el criterio estaba en escribir bien el código; ahora está en saber cuándo confiar en lo que la IA genera y cuándo no, en saber qué tarea conviene vibe-codear y cuál no, en saber leer lo que se produjo aunque no lo hayamos tipeado nosotros. El lugar del criterio se movió; su importancia, no.\nTambién me llevo una confirmación sobre cómo conviene incorporar lo nuevo en un equipo. No con prohibiciones, que no funcionan y además espantan el talento curioso. Tampoco con adopción ciega, que termina en sistemas que nadie entiende. Sino con esa actitud de exploración disciplinada: probar lo nuevo en territorio seguro, aprender sus límites de primera mano, separar dónde suma de dónde es peligroso, y recién entonces dejarlo entrar a lo que importa. El equipo que en marzo se lanzó sin red probablemente ya pagó algunas cuentas; el que esperó y observó, hoy puede adoptar lo bueno del vibe coding sabiendo dónde están las fronteras. Esa diferencia, la de la paciencia con criterio, no se nota en la euforia. Se nota unos meses después, que es justamente donde estamos.\nY me llevo, sobre todo, una manera de pararme frente a lo que viene. Porque va a venir otra cosa, seguro, otra herramienta deslumbrante que va a prometer cambiarlo todo y va a generar la misma euforia, el mismo péndulo, el mismo ruido. Y cuando llegue, voy a intentar hacer lo mismo que con el vibe coding: entusiasmarme sin perder la cabeza, probarla con honestidad, no opinar en caliente, y esperar a que baje la espuma para quedarme con el grano. No es la actitud más vistosa, ni la que consigue más aplausos en el momento del hype. Pero es, creo, la que mejor envejece.\nLes dejo una pregunta para que la lleven a su propio terreno, porque seguro tienen su propia moda reciente para examinar. La próxima vez que una herramienta nueva llene de ruido las conversaciones técnicas y sientan la presión de tener una opinión ya, ¿van a opinar sobre la espuma, o van a tener la paciencia, cada vez más difícil de sostener, de esperar a ver qué queda cuando el ruido se apague? Porque casi siempre queda algo. Y casi siempre, ese algo es bastante más chico, y bastante más valioso, que lo que prometía el titular.\nFuentes consultadas # Andrej Karpathy, publicación original sobre \u0026ldquo;vibe coding\u0026rdquo; en X, 2 de febrero de 2025. Apiiro, \u0026ldquo;Faster code, greater risks: The security trade-off of AI-driven development\u0026rdquo;, 26 de febrero de 2025. ","date":"20 de julio de 2025","externalUrl":null,"permalink":"/blog/post-cuatro-meses-despues-del-vibe-coding/","section":"Blog","summary":"En marzo escribí sobre el vibe coding en pleno auge. Cuatro meses después, con el ruido más bajo, se puede empezar a separar lo que era hype de lo que era señal. La idea perdurable: las modas técnicas no son ni la revolución que prometen ni el fraude que denuncian sus críticos; dejan un residuo útil cuando una tiene la paciencia de esperar a que baje la espuma.","title":"Después del vibe coding: qué quedó y qué se cayó","type":"blog"},{"content":"","date":"20 de julio de 2025","externalUrl":null,"permalink":"/tags/modas-tecnologicas/","section":"Tags","summary":"","title":"Modas-Tecnologicas","type":"tags"},{"content":"","date":"15 de junio de 2025","externalUrl":null,"permalink":"/tags/costos/","section":"Tags","summary":"","title":"Costos","type":"tags"},{"content":"","date":"15 de junio de 2025","externalUrl":null,"permalink":"/tags/eficiencia/","section":"Tags","summary":"","title":"Eficiencia","type":"tags"},{"content":"Hay una frase que repito tanto en el trabajo que mi equipo ya debe estar cansado de escucharla: no siempre necesitamos el modelo más grande. La digo cuando alguien propone, casi por reflejo, usar el modelo más potente disponible para una tarea que un modelo más chico resolvería igual de bien, más rápido y por una fracción del costo. La digo porque vi demasiadas veces esa tentación de ir directo a lo más caro y poderoso, como si la potencia fuera siempre una virtud y nunca un desperdicio. Y la vuelvo a pensar ahora, leyendo los informes que empezaron a circular este año sobre cuánta energía y cuánta agua consume todo este entusiasmo por la IA, porque me confirman algo que ya intuía desde el lado del presupuesto y la arquitectura: cada vez que elegimos más potencia de la que la tarea necesita, alguien paga la diferencia. A veces es nuestra factura. A veces es la red eléctrica de una región. A veces es una cuenca de agua que ya estaba bajo estrés. La eficiencia, que durante años tratamos como una optimización opcional para cuando sobra tiempo, se está volviendo una forma de responsabilidad. De eso quiero hablar.\nLa tentación de ir siempre a lo más grande # Hay un reflejo muy extendido en el mundo de la tecnología, y con la IA se volvió casi automático: ante cualquier tarea, elegir lo más potente disponible. Si hay un modelo más grande, más nuevo, con mejores números en los benchmarks, lo usamos, sin preguntarnos demasiado si la tarea lo justifica. Es una decisión que se siente segura —nadie te critica por usar lo mejor— y que además es cómoda, porque evita el trabajo de pensar qué necesita realmente cada caso.\nPero esa comodidad tiene un costo, y no es chico. Usar un modelo enorme para clasificar un texto simple, para extraer un dato de un formulario o para responder una pregunta trivial es como contratar una excavadora para plantar una maceta. Funciona, claro que funciona. Pero pagamos de más, esperamos de más, y consumimos muchísimo más de lo que la tarea pedía. La diferencia entre la excavadora y la pala no se nota cuando hay una sola maceta. Se nota cuando son millones de macetas por día, que es exactamente la escala a la que opera la IA cuando la metemos en producción. Lo que en una prueba aislada parece un detalle insignificante, multiplicado por el volumen real de uso, se transforma en una cuenta que alguien tiene que pagar.\nLo que los informes de este año nos están mostrando # Vale la pena detenerse un momento en por qué este tema dejó de ser una preocupación abstracta. Este año empezaron a publicarse análisis más serios sobre el consumo energético de la inteligencia artificial, y los números, aunque haya que tomarlos con cuidado, son lo bastante grandes como para que no podamos seguir ignorándolos. La Agencia Internacional de la Energía, en su informe sobre energía e IA de este año, estima que el consumo eléctrico de los centros de datos —una porción creciente de ellos dedicada a IA— podría más que duplicarse hacia el final de la década. Y aparece un dato que para mí es el más revelador, porque desarma una idea muy instalada: lo que más pesa en el consumo no es entrenar los modelos, sino usarlos.\nSolemos imaginar que el gran costo ambiental de la IA está en ese momento dramático del entrenamiento, esos meses de cómputo intensivo para crear un modelo. Y es cierto que entrenar consume muchísimo. Pero el entrenamiento se hace una vez; el uso, en cambio, ocurre millones de veces por día, todos los días, para siempre. Cada consulta, cada respuesta, cada tarea que le delegamos a un agente, suma. Y esa suma, sostenida en el tiempo y multiplicada por una cantidad de usuarios que no para de crecer, termina pesando más que el entrenamiento que tanto nos impresiona. A esto se le agrega el costo del agua: los centros de datos necesitan enfriarse, y ese enfriamiento consume agua dulce, a veces en regiones que ya la tienen escasa. Es un costo todavía más invisible que el de la electricidad, porque ni siquiera aparece en la factura que miramos.\nNo traigo estos números para sumarme al coro alarmista, que de eso ya hay bastante y no aporta mucho. Los traigo porque le ponen evidencia a algo que, desde el lado de la ingeniería, ya sabíamos sin necesidad de informes: cada decisión técnica tiene un costo, y cuando ese costo se multiplica por la escala, deja de ser despreciable. La novedad no es que la IA consuma. La novedad es que ahora tenemos dimensión de cuánto, y que ese cuánto depende, en buena parte, de decisiones que tomamos nosotros.\nEl costo que no aparece en el dashboard # Acá está el centro de lo que me interesa. Cuando elegimos un modelo, miramos cosas que son fáciles de ver: si funciona, qué tan bien responde, cuánto sale por consulta. Lo que casi nunca miramos es la cadena de costos que se dispara detrás de esa elección y que no figura en ningún tablero. El costo energético de cada inferencia. El agua del enfriamiento. La carga sobre una red eléctrica. La huella que, sumada a la de todos los demás que tomaron la misma decisión cómoda, se vuelve un problema colectivo.\nEs la misma lógica de las dependencias invisibles de las que escribí hace un par de meses, solo que aplicada al consumo: lo que no medimos, no lo gestionamos, y lo que no vemos, lo damos por gratis. Un equipo mira su dashboard, ve que la latencia está bien y que el costo por consulta es bajo, y concluye que todo está en orden. Pero el dashboard no muestra que ese mismo resultado se podía conseguir con un modelo tres o cinco veces más eficiente, que habría consumido una fracción de la energía. No muestra el costo de la sobrepotencia, porque la sobrepotencia no rompe nada: simplemente desperdicia, silenciosamente, a una escala que solo se vuelve visible cuando alguien se sienta a sumar. Y casi nadie se sienta a sumar, porque mientras funcione, parece que no hay problema.\nElegir el modelo correcto es una decisión de diseño # Quiero ser claro en algo, porque es la idea que más me importa transmitirle a mi equipo: elegir qué modelo usar no es un detalle de configuración, es una decisión de arquitectura. Tan importante como elegir una base de datos, un patrón de diseño o una estrategia de caché. Y como toda decisión de arquitectura, merece criterio, no reflejo.\nLa pregunta correcta nunca es \u0026ldquo;¿cuál es el modelo más potente?\u0026rdquo;, sino \u0026ldquo;¿qué necesita realmente esta tarea?\u0026rdquo;. Hay tareas que requieren razonamiento profundo, varios pasos, manejo de ambigüedad, y ahí un modelo potente se justifica plenamente. Pero hay muchísimas otras —clasificar, extraer, resumir algo corto, responder preguntas acotadas, transformar un formato en otro— que un modelo más chico resuelve con la misma calidad, más rápido y con una fracción del consumo. Tratar a todas las tareas como si necesitaran lo máximo es, en el fondo, no haber pensado el problema. Es delegar en la fuerza bruta lo que debería resolver el criterio. Y la fuerza bruta, ya lo escribí cuando hablé de aquel modelo que sacudió a la industria a principios de año, tiende a adormecer el ingenio: cuando tenemos potencia de sobra, dejamos de preguntarnos si la estamos usando bien.\nLa buena noticia es que pensar esto no solo ahorra recursos; casi siempre mejora el sistema. Un modelo más chico y adecuado suele responder más rápido, lo que mejora la experiencia. Cuesta menos, lo que libera presupuesto para otras cosas. Consume menos, lo que reduce la huella. Rara vez elegir bien el modelo es un sacrificio; lo más común es que sea, simplemente, una mejor decisión en todas las dimensiones a la vez. La sobrepotencia no nos estaba dando nada a cambio de lo que costaba.\nNo es un modelo, son varios según la tarea # Hay una consecuencia práctica de todo esto que conviene hacer explícita, porque cambia cómo diseñamos un sistema. La pregunta \u0026ldquo;¿qué modelo usamos?\u0026rdquo; suele plantearse como si hubiera que elegir uno solo para todo el producto, y esa es justamente la trampa. Un sistema real rara vez hace una sola cosa: clasifica, extrae, resume, razona, conversa, decide. Y cada una de esas cosas tiene exigencias distintas. Pretender que un único modelo, el más grande, atienda todo por igual es cómodo de configurar, pero es casi siempre la peor opción, porque significa pagar el precio del caso más exigente para resolver también los más triviales.\nLo que tiene sentido, y es lo que trato de empujar cuando diseñamos, es pensar en términos de varios modelos conviviendo en el mismo sistema, cada uno en la tarea donde rinde mejor. Un modelo chico y veloz para la clasificación inicial o la extracción simple, que resuelve el grueso del volumen. Un modelo más potente reservado para los casos que de verdad lo necesitan, esos que llegan después de un primer filtro y que justifican el gasto. A veces incluso una cascada: empezar barato, y escalar a algo más caro solo cuando el caso lo amerita. No es una idea exótica ni nueva; es el mismo principio de siempre, el de poner cada recurso donde aporta más, aplicado a una caja de herramientas que ahora incluye modelos de distinto tamaño.\nEsto exige un poco más de trabajo de diseño que elegir un modelo único y olvidarse, no lo voy a negar. Hay que entender el flujo, separar las tareas, decidir los umbrales. Pero ese trabajo se paga solo, y rápido: en costo, en velocidad, en consumo. Y tiene un beneficio extra que me parece el más valioso a largo plazo: obliga al equipo a entender el sistema por partes, a saber qué hace cada pieza y por qué, en lugar de tirarle el modelo más grande encima a un problema que nunca terminamos de mirar de cerca. La pereza de usar uno solo para todo no solo cuesta más; también nos deja entendiendo menos lo que construimos.\nNo usemos un cañón para matar una mosca # Hay un dicho viejo que viene perfecto acá: no hace falta un cañón para matar una mosca. Y sin embargo, en el mundo de la IA, lo vemos todo el tiempo. Alguien tiene que resolver una tarea mínima —clasificar un texto, sacar un dato de un formulario, responder algo acotado— y apunta directo con el modelo más potente, el cañón, contra una mosca que se mataba con la mano. El resultado es el mismo, sí: la mosca muere. Pero gastamos en pólvora, en estruendo y en humo muchísimo más de lo que el problema pedía, y encima nos quedamos con la sensación de haber hecho un buen trabajo porque, total, la mosca está muerta.\nSaber cuándo hace falta el cañón y cuándo alcanza con la mano no es un detalle menor: es, para mí, una de las habilidades que definen a un buen profesional de la IA. Y subrayo lo de habilidad, porque no es algo que venga incluido con la herramienta ni que se aprenda leyendo la documentación. Es criterio, y el criterio se construye con experiencia. Elegir bien la potencia que usamos para cada tarea es exactamente el tipo de decisión donde se nota el oficio de quien la toma. El que recién empieza tiende a ir a lo más grande, por las dudas, porque todavía no tiene la intuición de cuánto necesita cada problema. El que lleva años entiende, casi sin pensarlo, que la mayoría de las tareas no necesitan el tope, y reserva la artillería pesada para cuando de verdad hace falta.\nLa potencia adecuada también es cuestión de experiencia # Esto conecta con algo que ya escribí cuando hablé de quienes recién empiezan a programar con IA, y que vale la pena retomar acá desde otro ángulo. Dije entonces que la IA acelera muchísimo a alguien que ya tiene criterio, pero que a alguien que todavía no lo tiene puede darle una falsa autonomía. Con la elección del modelo pasa algo parecido. No es lo mismo un junior que una persona que hace quince años escribe software. No porque el junior sea menos inteligente —muchas veces es más rápido y más audaz—, sino porque la elección de la herramienta justa se apoya en algo que solo da el tiempo: haber visto muchos problemas, haberse equivocado eligiendo de más y de menos, haber pagado las dos cuentas y haber aprendido a anticiparlas.\nQuien tiene experiencia le saca más provecho a la IA, justamente, porque sabe pedirle lo correcto y elegirle el tamaño correcto. Reconoce de un vistazo cuándo una tarea es trivial y cuándo esconde una complejidad que va a requerir más. Sabe que pagar por una capacidad que la tarea nunca va a usar no es prudencia sino desperdicio, y sabe distinguir los pocos casos donde esa capacidad de más sí se justifica. El junior, en cambio, todavía está construyendo esa intuición, y mientras la construye va a tender a sobredimensionar, porque lo más grande se siente más seguro. Eso no es un defecto a castigar; es una etapa del aprendizaje. Pero sí es algo que, como líderes de equipo, tenemos que acompañar: enseñar a elegir bien la potencia es parte de formar a alguien, igual que enseñarle a elegir bien una estructura de datos o a no resolver con tres servicios lo que se resuelve con uno.\nPor qué esto importa más allá del bolsillo # Ahora bien, alguien podría decirme: si el modelo grande funciona y me lo puedo pagar, ¿cuál es el problema de usar el cañón? Y acá quiero ser cuidadoso, porque no me interesa dar lecciones de moral ni sumarme al discurso de que vamos a destruir el planeta por usar desodorante. Ese tipo de culpa difusa y exagerada me parece tan inútil como contraproducente. No se trata de cargar a cada desarrollador con el peso del cambio climático cada vez que hace una llamada a un modelo; eso sería absurdo y paralizante.\nLo que sí creo es que elegir bien la potencia tiene varias consecuencias buenas que se acumulan, y conviene tenerlas todas en la cabeza, no solo una. Está la económica, la más obvia: gastar lo justo libera presupuesto para otras cosas. Está la operativa: un modelo más chico y adecuado suele responder más rápido, lo que mejora la experiencia de quien usa el producto. Y está, sí, la ambiental, pero en su justa medida: a la escala a la que opera la IA, elegir consistentemente más potencia de la necesaria sí tiene un costo energético e hídrico real, y desperdiciarlo por comodidad cuando podríamos no hacerlo es, simplemente, una mala práctica. No lo planteo como una cruzada, sino como lo que es: una de las varias razones por las que vale la pena elegir con criterio, no la única ni la principal. La principal, para mí, sigue siendo profesional: usar la herramienta justa es, antes que nada, hacer bien nuestro trabajo.\nDurante mucho tiempo, en software, el consumo de recursos fue invisible para quien programaba: alguien más pagaba la factura del servidor, alguien más se ocupaba de la infraestructura, y uno podía darse el lujo de no pensar en eso. La IA, por su escala, nos vuelve a poner esa cuenta delante de los ojos, y nos da la oportunidad de recuperar un hábito que nunca debió perderse: el de elegir con conciencia de lo que cada decisión cuesta. No por culpa, sino por oficio. El buen ingeniero nunca fue el que tira más recursos al problema; fue el que entiende tan bien el problema que la solución resulta justa.\nLo que le digo al equipo # Cuando trabajo este tema con mi equipo, trato de que no quede en un principio abstracto, porque los principios abstractos no cambian decisiones. Lo bajo a preguntas concretas que conviene hacerse antes de elegir un modelo para algo que va a producción. ¿Esta tarea necesita de verdad razonamiento complejo, o es algo acotado y repetitivo? ¿Probamos si un modelo más chico la resuelve con calidad suficiente, o fuimos directo al más grande por las dudas? ¿Sabemos cuánto cuesta esta elección multiplicada por el volumen real que vamos a tener, no por la única consulta de la prueba? ¿Estamos pagando por una capacidad que esta tarea nunca va a usar?\nEsa última pregunta es la que más me gusta, porque desarma de raíz la falsa sensación de seguridad de \u0026ldquo;usemos lo mejor por las dudas\u0026rdquo;. Esa coartada del \u0026ldquo;por las dudas\u0026rdquo; es, casi siempre, una forma elegante de no haber pensado el problema. Cuando un equipo se acostumbra a hacerse estas preguntas antes de elegir, pasa algo más profundo que ahorrar recursos: empieza a entender mejor lo que construye, porque para responderlas hay que mirar cada tarea de cerca en lugar de taparla con potencia. Y un equipo que entiende lo que construye toma mejores decisiones en todo lo demás, no solo en la elección del modelo.\nLa eficiencia no es lo contrario de la ambición # Me importa aclarar algo para no ser malinterpretado, porque este discurso puede sonar a \u0026ldquo;usemos menos IA\u0026rdquo; y no es eso. No estoy en contra de la potencia ni de los modelos grandes; son maravillosos y resuelven problemas que antes eran impensables. Estoy en contra de usarlos por defecto, sin criterio, para todo. La eficiencia bien entendida no es renunciar a la ambición: es ser ambicioso con cabeza. Es querer resolver problemas grandes usando exactamente lo que hace falta, ni más ni menos. Y elegir ese \u0026ldquo;exactamente\u0026rdquo; es, otra vez, una cuestión de oficio: cuanto más sabe quien decide, más fina es la puntería.\nY hay algo lindo en esto, que me reconcilia con el tema más allá de la preocupación por el consumo: pensar en eficiencia nos obliga a entender mejor lo que hacemos. Para elegir el modelo justo hay que entender de verdad la tarea, sus requisitos, sus límites. Esa comprensión, ese trabajo de pensar antes de elegir, es lo que separa a un equipo que opera con criterio de uno que va apilando potencia sobre potencia esperando que la fuerza compense la falta de claridad. La eficiencia, al final, es un subproducto de pensar bien. Y pensar bien nunca pasó de moda.\nMe quedo con una pregunta para dejarles, porque este tema recién empieza a ocupar el lugar que merece en las conversaciones técnicas. La próxima vez que vayamos a elegir, casi por reflejo, el modelo más potente para una tarea nueva, ¿nos vamos a tomar el minuto incómodo de preguntarnos si de verdad lo necesita, o vamos a seguir tratando la potencia como si fuera gratis solo porque su costo no aparece en el dashboard que miramos? Porque el costo está ahí igual, lo veamos o no. Y una parte de madurar como técnicos, creo, es aprender a hacernos cargo justamente de lo que no se ve.\nFuentes consultadas # Agencia Internacional de la Energía (IEA), \u0026ldquo;Energy and AI\u0026rdquo;, abril de 2025. Pengfei Li, Jianyi Yang, Mohammad A. Islam, Shaolei Ren, \u0026ldquo;Making AI Less \u0026lsquo;Thirsty\u0026rsquo;: Uncovering and Addressing the Secret Water Footprint of AI Models\u0026rdquo;, University of California, Riverside, 2023. ","date":"15 de junio de 2025","externalUrl":null,"permalink":"/blog/post-eficiencia-como-responsabilidad-tecnica/","section":"Blog","summary":"En la carrera por usar el modelo de IA más potente, solemos olvidar una pregunta sencilla: ¿lo necesitábamos? Elegir el modelo adecuado para cada tarea, en lugar del más grande por defecto, no es solo ahorrar dinero. Es una forma de responsabilidad técnica que tiene consecuencias económicas, operativas y ambientales. La eficiencia dejó de ser un lujo de optimización para volverse parte del criterio.","title":"Eficiencia como responsabilidad técnica: no siempre necesitamos el modelo más grande","type":"blog"},{"content":"","date":"15 de junio de 2025","externalUrl":null,"permalink":"/tags/sostenibilidad/","section":"Tags","summary":"","title":"Sostenibilidad","type":"tags"},{"content":"","date":"26 de mayo de 2025","externalUrl":null,"permalink":"/tags/automatizacion/","section":"Tags","summary":"","title":"Automatizacion","type":"tags"},{"content":"Hace unos seis meses escribí sobre los agentes de IA con un título que ahora me resulta casi tímido: \u0026ldquo;cuando la IA deja de responder y empieza a hacer cosas\u0026rdquo;. En aquel momento, los agentes eran sobre todo una posibilidad. Algo que se intuía, que se mostraba en demos impactantes, que prometía. Yo los describía con cierta cautela, como una dirección hacia la que íbamos, no como una realidad instalada. Y escribí, entre otras cosas, que los agentes necesitaban barandas. Vuelvo al tema ahora, medio año después, porque algo cambió, y no es menor: los agentes empezaron a trabajar de verdad. Ya no es una demo de laboratorio ni una promesa de roadmap. Hoy hay agentes que toman una tarea, la dividen en pasos, tocan archivos en un repositorio real, corren pruebas, iteran sobre los errores y trabajan durante horas con poca intervención humana. La posibilidad se volvió práctica. Y eso me obliga a revisar lo que dije, no para desdecirme, sino para afinarlo: porque lo que era cierto cuando los agentes solo prometían se volvió mucho más urgente ahora que cumplen.\nLo que cambió en estos meses # No quiero quedarme en el anuncio puntual, porque eso envejece rápido y no es lo que me importa. Pero conviene dar contexto. En estos meses, los principales laboratorios de IA empujaron fuerte en una misma dirección: modelos pensados específicamente para tareas agénticas, capaces de razonar durante más tiempo, de usar herramientas, de sostener un trabajo largo sin perder el hilo. Lo que se anuncia ahora ya no se vende por lo bien que conversa, sino por lo bien que ejecuta tareas complejas de varios pasos, sobre todo en desarrollo de software. Y, de manera reveladora, varias de estas herramientas dejaron de ser experimentos en vista previa para volverse productos disponibles, listos para que cualquier equipo los use en su flujo de trabajo diario.\nEse detalle, que parece administrativo, es en realidad el más importante. Una cosa es que exista una capacidad en un laboratorio; otra muy distinta es que esté disponible, integrada, lista para meter en producción. El paso de \u0026ldquo;vista previa de investigación\u0026rdquo; a \u0026ldquo;producto general\u0026rdquo; es el paso de la curiosidad a la responsabilidad. Cuando algo está en preview, lo prueba un puñado de entusiastas que saben que están jugando con fuego. Cuando algo es un producto general, lo usa todo el mundo, incluido el que no leyó la letra chica, el que no entiende los riesgos, el que asume que si está disponible es porque es seguro usarlo sin pensar. Y ahí es donde la conversación sobre agentes deja de ser teórica.\nDe la posibilidad a la práctica: qué significa \u0026ldquo;trabajar de verdad\u0026rdquo; # Vale la pena detenerse en qué quiere decir, concretamente, que un agente \u0026ldquo;trabaja de verdad\u0026rdquo;, porque la frase puede sonar a marketing y no lo es. Hablo de algo bastante específico. Le damos una tarea descrita en lenguaje natural —arreglá este bug, implementá esta funcionalidad, migrá este módulo— y el agente no nos devuelve una sugerencia para que copiemos y peguemos, como hacía hace un año. En cambio, explora el repositorio para entender el contexto, identifica qué archivos hay que tocar, hace los cambios, corre las pruebas, ve qué falla, corrige, vuelve a probar, y sigue así durante un rato largo, a veces horas, hasta llegar a algo que se le parece a una solución terminada. Después nos deja el resultado para revisar.\nEse ciclo —explorar, decidir, actuar, verificar, corregir— es exactamente lo que distingue a un agente de un asistente. El asistente responde a un pedido puntual y se detiene. El agente persigue un objetivo a lo largo de muchos pasos, tomando decisiones intermedias por su cuenta. Y cuando esos pasos son muchos y se extienden en el tiempo, pasa algo que en noviembre solo podía anticipar: la cantidad de decisiones que el agente toma sin que las veamos crece muchísimo. No es una decisión la que se nos escapa, son docenas, encadenadas, cada una construida sobre la anterior. El resultado puede ser excelente. Pero el camino para llegar a él, esa secuencia de pequeñas elecciones autónomas, se vuelve cada vez más difícil de seguir.\nEl entusiasmo, otra vez, está justificado # Quiero ser claro, porque sería fácil leer todo esto como una advertencia temerosa y no lo es: lo que está pasando es genuinamente bueno y emocionante. Un agente que puede tomar una tarea bien delimitada y trabajarla de punta a punta es una herramienta poderosísima. Libera tiempo humano para los problemas que de verdad lo necesitan. Acelera el trabajo repetitivo y mecánico. Permite que equipos chicos hagan cosas que antes requerían muchas más manos. Destraba tareas que se postergaban por falta de tiempo, esas que todos sabemos que hay que hacer y que nunca llegan a la cima de la lista.\nLo viví en carne propia en estas semanas, probando estas herramientas. Hay un momento, parecido al que sentí con el vibe coding, en que la cosa simplemente funciona, y uno se queda mirando la pantalla con una mezcla de asombro y vértigo. El agente entendió el problema, navegó un código que no había visto nunca, hizo cambios sensatos, corrió las pruebas, se dio cuenta de que algo fallaba y lo corrigió solo. Es difícil no maravillarse. Y descartar esa maravilla por prudencia excesiva sería tan ingenuo como rendirse a ella sin pensar. La capacidad es real, el valor es real. Justamente por eso el resto de la reflexión importa: porque cuando algo es tan útil, la tentación de soltarle las riendas del todo es enorme.\nEl caballo se volvió más fuerte; el arnés importa más # Acá quiero traer una imagen que me ayuda a pensar todo esto. Un agente potente es como un caballo de tiro fuerte. Cuanto más fuerte es el caballo, más trabajo puede hacer, más carga puede mover, más lejos puede llevarnos. Pero también, cuanto más fuerte es, más importa el arnés con que lo conducimos. Un caballo manso y débil se controla con cualquier cosa; si se desvía, no pasa gran cosa. Un caballo poderoso, sin arnés o con un arnés flojo, no es una bendición, es un peligro. Toda su fuerza, que es justamente lo que lo hace valioso, se vuelve la razón por la que necesitamos conducirlo bien.\nEn noviembre escribí que los agentes necesitaban barandas, y lo sostengo. Pero ahora veo que esa metáfora se queda corta, porque una baranda es pasiva: está ahí para que uno no se caiga si se acerca al borde. El arnés es activo: es cómo se dirige la fuerza hacia donde queremos que vaya. Y eso es lo que cambió. Cuando los agentes solo respondían, alcanzaba con contener los desastres. Ahora que ejecutan tareas largas y potentes, necesitamos algo más: conducir esa fuerza, no solo limitarla. El arnés de un agente son los permisos que le damos y los que no, las acciones que puede tomar solo y las que requieren que un humano apruebe, los entornos donde lo dejamos trabajar libremente y los que protegemos, el registro de todo lo que hizo para poder entenderlo después, los puntos donde lo obligamos a detenerse y mostrar antes de seguir. Cuanto más capaz es el agente, más fino tiene que ser ese arnés. La intuición fácil es la contraria —\u0026ldquo;ya es tan bueno que puedo confiar más\u0026rdquo;— y es exactamente al revés. Más capacidad pide más conducción, no menos.\nLas tres piezas del arnés que no cambian: permisos, revisión, trazabilidad # Si tuviera que reducir el arnés a sus piezas esenciales, me quedaría con tres, las mismas que ya importaban antes y que ahora se vuelven críticas. La primera son los permisos: qué puede tocar el agente y qué no. Un agente que trabaja en una rama aislada de un repositorio es una cosa; uno con permiso para hacer merge directo a la rama principal, o para tocar producción, o para ejecutar comandos sin límite, es otra muy distinta. La pregunta no es solo qué queremos que el agente pueda hacer, sino qué no debería poder hacer nunca, por más capaz que sea. La capacidad no debería confundirse con la autorización. Que un agente pueda borrar una base de datos no significa que deba tener permiso para hacerlo.\nLa segunda es la revisión. Y acá hay una trampa sutil que conviene nombrar. Cuando un agente produce poco, revisar es fácil. Cuando un agente produce mucho, rápido, durante horas, revisar se vuelve agotador, y aparece la tentación de aprobar sin mirar de verdad, confiando en que \u0026ldquo;seguro está bien\u0026rdquo;. Ese es el momento peligroso. Un agente que genera más de lo que podemos revisar con atención no nos hace más productivos: nos hace acumular, a gran velocidad, cambios que nadie entendió del todo. La revisión humana no es un trámite que estorba la velocidad; es lo único que separa \u0026ldquo;el agente hizo un montón de cosas\u0026rdquo; de \u0026ldquo;el agente hizo las cosas correctas\u0026rdquo;. Y si el volumen que genera supera nuestra capacidad de revisarlo, el problema no es la revisión: es que le estamos pidiendo al agente más de lo que podemos gobernar.\nLa tercera es la trazabilidad, y es quizás la que más se vuelve a valorar con los agentes que trabajan solos por horas. Si el agente tomó docenas de decisiones que no vimos, lo mínimo que necesitamos es poder reconstruir qué hizo y por qué. Un registro de sus pasos, de sus decisiones, de los comandos que ejecutó. Porque el día que algo salga mal —y va a salir, todo sale mal alguna vez— la diferencia entre un incidente manejable y una pesadilla va a estar en si podemos entender qué hizo el agente o si tenemos que adivinar. Un agente sin trazabilidad es una caja negra que toma decisiones por nosotros, y poner una caja negra en el camino crítico de algo importante es, históricamente, una de las peores ideas de la ingeniería.\nEl riesgo no es que el agente se rebele, es que confiemos de más # Cuando se habla de los riesgos de los agentes, la imaginación tiende a irse a la ciencia ficción: la máquina que se rebela, que toma decisiones malignas, que se sale de control por voluntad propia. Es una distracción. El riesgo real, el que veo todos los días en cómo se usan estas herramientas, es mucho más mundano y mucho más probable: que confiemos de más. Que, deslumbrados por lo bien que funciona el agente la mayoría de las veces, bajemos la guardia justo cuando más la necesitamos.\nEl problema no es que el agente sea malo. Es que es bueno casi siempre, y ese \u0026ldquo;casi\u0026rdquo; es traicionero. Un agente que acierta el noventa y cinco por ciento de las veces nos entrena, sin que nos demos cuenta, a confiar en el cien por ciento. Empezamos revisando todo con cuidado, vemos que casi siempre está bien, y poco a poco aflojamos. Revisamos menos. Aprobamos más rápido. Le damos más permisos. Hasta que llega ese cinco por ciento —o ese uno por ciento— en un momento crítico, y nos encuentra desprevenidos, porque nos habíamos acostumbrado a que todo saliera bien. La confiabilidad alta no elimina la necesidad de vigilancia; paradójicamente, la vuelve más difícil de sostener, porque erosiona nuestra disciplina sin que lo notemos. Es el mismo fenómeno de las dependencias que funcionan tan bien que dejamos de mirarlas, solo que ahora aplicado a algo que toma decisiones por nosotros.\nEl agente sigue sin entender nuestra empresa # Hay algo que dije en noviembre y que el aumento de capacidad no cambió en absoluto: un agente puede ser extraordinariamente bueno ejecutando tareas técnicas y seguir sin entender el contexto de nuestra organización. No sabe qué cliente es crítico, qué decisión de arquitectura responde a una restricción del negocio y no a una preferencia técnica, qué parte del sistema está en medio de una migración delicada, qué deuda técnica decidimos tolerar a propósito y cuál hay que atacar. Puede saberlo si se lo damos, puede respetarlo si se lo explicitamos, pero no lo adivina. Y un agente más capaz, que actúa más y más rápido, puede equivocarse en esa dimensión contextual con mucho más alcance que antes.\nEsto refuerza algo que vengo repitiendo y que cada nueva capacidad vuelve más cierto: cuanto más queremos delegar en una IA, más importa el contexto que le damos. Las reglas, la documentación, las restricciones, los límites explícitos. Si dejamos que un agente potente trabaje sobre un sistema mal documentado, sin reglas claras, con un objetivo vago, va a llenar todos esos huecos con supuestos, y los va a llenar rápido y con seguridad, que es la peor combinación. El agente no es el sustituto de entender nuestro propio sistema; es, si acaso, una razón más para entenderlo bien, porque ahora ese entendimiento es lo que le da al agente las riendas para no perderse.\nEmpezar por lo acotado, no por lo crítico # Si una organización quiere incorporar agentes en serio ahora que de verdad funcionan, sigo creyendo lo mismo que en noviembre, con más convicción todavía: conviene empezar por lo acotado y de bajo riesgo, no por lo crítico. Un agente trabajando en una rama aislada, generando una primera versión que un humano revisa antes de integrar, sobre tareas bien delimitadas y reversibles, es un lugar excelente para aprender. Permite ganar experiencia, descubrir cómo se equivoca, calibrar cuánto revisar, ajustar los permisos, todo sin poner en juego lo que no nos podemos permitir perder.\nLo que no haría —y lo veo como una tentación creciente justamente porque las herramientas se ven tan capaces— es soltar un agente potente directo sobre lo crítico solo porque la demo impresiona. La madurez no está en automatizar lo más posible lo más rápido posible; está en saber qué conviene delegar, con qué arnés, y en qué momento. Un equipo que aprendió a trabajar con agentes en territorio seguro va a estar muchísimo mejor preparado para, eventualmente, darles más responsabilidad, que uno que los puso a correr en producción el primer día y descubrió los límites a fuerza de incidentes. La velocidad de adopción no es una virtud en sí misma. La velocidad con la que aprendemos a gobernar lo que adoptamos, sí.\nEl rol del que lidera, todavía más en el centro # Cada vez que la capacidad de estas herramientas da un salto, el rol de quien conduce equipos de tecnología se vuelve más importante, no menos, y los agentes que trabajan de verdad lo confirman. Porque alguien tiene que tomar las decisiones que el entusiasmo, solo, no toma: qué le permitimos a un agente y qué no, qué requiere aprobación humana, dónde lo dejamos trabajar libre y dónde no, cómo registramos lo que hace, cómo medimos si de verdad mejora el trabajo o solo genera más cosas para revisar. Son decisiones de criterio, y el criterio no viene incluido en la herramienta.\nHay además una responsabilidad más sutil, que tiene que ver con la cultura del equipo. Cuando aparece una herramienta tan seductora, la tendencia natural es que cada uno la use a su manera, soltándole cada vez más las riendas a medida que le toma confianza. El trabajo de liderar, en parte, es sostener la disciplina colectiva justo cuando la herramienta invita a relajarla: mantener la revisión seria aunque el agente casi siempre acierte, mantener la pregunta por los permisos aunque sea más cómodo dar acceso total, mantener viva la trazabilidad aunque parezca que nunca la vamos a necesitar. No por desconfianza hacia la tecnología, sino por respeto a cómo fallan los sistemas complejos. La diferencia entre un equipo que usa agentes con criterio y uno que es arrastrado por ellos se va a notar, y se va a notar en producción.\nLo que me queda, medio año después # Vuelvo al principio, a ese post de noviembre que ahora me parece tímido. No me arrepiento de lo que escribí; al contrario, me sorprende cuánto se sostiene. Lo que dije entonces sobre permisos, revisión, trazabilidad, contexto y humanos en el circuito no solo sigue siendo cierto: se volvió más urgente, porque la distancia entre \u0026ldquo;el agente podría hacer cosas\u0026rdquo; y \u0026ldquo;el agente está haciendo cosas\u0026rdquo; se cerró. Aquello era una advertencia sobre un futuro probable. Esto es una descripción de un presente real.\nY la lección de fondo, esa que quiero que perdure más allá de qué modelo salió este mes o cuál saldrá el que viene, es esta: la capacidad y la responsabilidad de gobernarla tienen que crecer juntas, y nuestra tendencia natural es dejar que crezca solo la primera. Nos entusiasma lo que el agente puede hacer y nos cuesta acompañar ese entusiasmo con la disciplina de conducirlo bien. Cada salto de capacidad nos tienta a soltar un poco más las riendas, justo cuando el caballo se volvió más fuerte y las riendas importan más. Resistir esa tentación, sin caer tampoco en el miedo paralizante, es probablemente la habilidad técnica y de liderazgo más valiosa de este momento.\nLes dejo, para terminar, una pregunta para llevarse al propio equipo. La próxima vez que un agente nos resuelva una tarea de manera impecable y sintamos esa tentación tan humana de darle un poco más de libertad, un permiso más, una revisión menos, ¿vamos a estar afinando el arnés a la altura de su nueva fuerza, o simplemente vamos a estar soltando las riendas porque por ahora, casi siempre, sale bien? Porque ese \u0026ldquo;casi siempre\u0026rdquo; es cómodo hasta el día que deja de serlo, y para ese día, lo único que nos va a proteger es el arnés que hayamos tenido la disciplina de mantener.\nFuentes consultadas # Anthropic, \u0026ldquo;Introducing Claude 4\u0026rdquo;, 22 de mayo de 2025. Anthropic, \u0026ldquo;Claude Code: Deep coding at terminal velocity\u0026rdquo;, disponibilidad general anunciada el 22 de mayo de 2025. Anthropic, \u0026ldquo;Claude 3.7 Sonnet and Claude Code\u0026rdquo;, 24 de febrero de 2025 (Claude Code como research preview). ","date":"26 de mayo de 2025","externalUrl":null,"permalink":"/blog/post-cuando-el-agente-empieza-a-trabajar-de-verdad/","section":"Blog","summary":"Hace medio año los agentes eran una posibilidad técnica prometedora. Hoy empiezan a correr tareas largas y autónomas en repositorios reales. El entusiasmo está justificado, pero la lección no cambió: cuanto más potente es lo que delegamos, más cuidado necesita el arnés con que lo conducimos. La capacidad creció; la responsabilidad de gobernarla, también.","title":"Cuando el agente empieza a trabajar de verdad","type":"blog"},{"content":"","date":"26 de mayo de 2025","externalUrl":null,"permalink":"/tags/seguridad/","section":"Tags","summary":"","title":"Seguridad","type":"tags"},{"content":"Hay un ejercicio incómodo que recomiendo a cualquiera que lidere tecnología, aunque casi nadie lo hace hasta que es tarde: sentarse, en frío, sin la presión de un incidente, y tratar de escribir la lista completa de cosas de las que depende que mi sistema siga funcionando mañana a la mañana. No la lista que está en el diagrama de arquitectura, esa la conocemos todos. La otra. La de verdad. La que incluye ese servicio que nadie recuerda haber configurado, esa cuenta que creó alguien que ya no trabaja acá, ese certificado que se renueva solo —¿se renueva solo?—, esa integración con un proveedor que nunca nos dio problemas y que justamente por eso dejamos de mirar. Cada vez que hice ese ejercicio, o que acompañé a un equipo a hacerlo, aparecieron cosas que nos dejaron incómodos. Y esa incomodidad, créanme, es mucho más barata cuando llega un martes cualquiera por elección propia que cuando llega un sábado a las tres de la mañana, sin avisar, en forma de caída.\nUna idea que dejé picando hace unos meses # Hace unos meses, escribiendo sobre la caída global asociada a CrowdStrike, mencioné al pasar una idea que se me quedó dando vueltas y que merece un post entero: la de las dependencias invisibles. Dije ahí que toda organización tiene dependencias visibles, esas que cualquiera reconoce, y otras invisibles, que son las peligrosas porque solo aparecen cuando fallan. Lo dejé planteado en un párrafo y seguí con otros temas. Pero la idea no me soltó, y con los meses me convencí de que ahí, en esa distinción aparentemente obvia, está una de las claves menos atendidas de la resiliencia tecnológica.\nPorque cuando hablamos de resiliencia solemos saltar directo a las soluciones: redundancia, backups, multi-región, planes de contingencia, monitoreo. Todo eso es importante, no lo discuto. Pero hay un paso anterior, mucho más humilde y mucho menos glamoroso, que casi siempre nos salteamos: saber de qué dependemos. Y resulta que ese paso, que parece trivial, es el más difícil de todos. No porque sea técnicamente complejo, sino porque exige una honestidad que la operación diaria no nos deja tener. Estamos tan ocupados haciendo funcionar las cosas que rara vez nos detenemos a preguntar qué, exactamente, las hace funcionar.\nEl diagrama miente, y no por mala intención # Si le pedimos a casi cualquier equipo el diagrama de arquitectura de su sistema, nos van a mostrar algo razonable: la aplicación, la base de datos, el balanceador, la nube donde corre todo, quizás un par de servicios externos, el sistema de pagos, el de correo. Es un buen punto de partida. El problema es que ese diagrama describe el sistema como nos gustaría que fuera, o como era cuando alguien se sentó a dibujarlo, no como es hoy de verdad.\nPorque los sistemas reales no se quedan quietos. Crecen, se parchan, se integran con cosas nuevas, acumulan workarounds. Cada vez que alguien resolvió un problema rápido un viernes a la tarde, cada vez que se sumó una herramienta para tapar un agujero, cada vez que se conectó un servicio nuevo \u0026ldquo;provisoriamente\u0026rdquo;, se agregó una dependencia que probablemente no llegó al diagrama. Y así, con el tiempo, la distancia entre el diagrama y la realidad se vuelve enorme. El diagrama muestra diez cajas; el sistema real depende de cuarenta cosas, y treinta de ellas no están dibujadas en ningún lado. No es mala intención ni negligencia: es la entropía natural de cualquier sistema que vive y se usa. Pero esa distancia es, precisamente, donde se esconden los problemas.\nAnatomía de lo invisible # Vale la pena detenerse en qué tipo de cosas suelen quedar fuera del radar, porque reconocerlas es el primer paso para hacerlas visibles. Están las dependencias de infraestructura silenciosa: el servicio de DNS que resuelve todos nuestros nombres, los certificados que cifran nuestras comunicaciones, las claves y secretos que permiten que un sistema le hable a otro, las cuentas de servicio que ejecutan tareas en segundo plano. Nada de eso se ve en el día a día, todo eso funciona en silencio, y cualquiera de esas piezas, si falla, puede tumbar cosas que parecían no tener relación con ella.\nDespués están las dependencias humanas y de conocimiento, que son tal vez las más subestimadas. Ese proceso que solo entiende una persona del equipo. Ese script crítico que escribió alguien que ya no está y que nadie se anima a tocar. Esa configuración que \u0026ldquo;siempre estuvo así\u0026rdquo; y que nadie sabe bien por qué. El conocimiento tribal es una dependencia tan real como un servidor, con el agravante de que no figura en ningún inventario y se va caminando el día que esa persona renuncia. He visto sistemas enteros sostenidos por la memoria de una sola persona, y no es una imagen tranquilizadora.\nY están las dependencias de terceros que dimos por sentadas. El proveedor de pagos, claro, ese lo tenemos presente. Pero también el servicio de envío de correos, la herramienta de analytics que cargamos en cada página, el CDN, la librería de código abierto que actualizamos sin leer, la API de un tercero que usamos para una función chiquita pero que está en el camino crítico de algo importante. Cada integración que sumamos por comodidad es una dependencia nueva, y la comodidad tiene la mala costumbre de hacernos olvidar que esa pieza existe hasta que un día deja de responder.\nPor qué lo invisible es lo más peligroso # Acá hay una asimetría cruel que conviene entender. Las dependencias visibles, justamente por ser visibles, suelen estar más cuidadas. Sabemos que la base de datos es crítica, así que le ponemos réplicas, backups, monitoreo, alertas. Sabemos que la nube es central, así que pensamos en regiones, en disponibilidad, en planes. Lo que conocemos, lo protegemos. El peligro real no está casi nunca en lo que sabemos que es crítico; está en lo que no sabíamos que lo era.\nPensémoslo así: un incidente en una dependencia conocida nos encuentra, al menos en parte, preparados. Tenemos un procedimiento, una alternativa, alguien que sabe qué hacer. Un incidente en una dependencia invisible nos encuentra desnudos. No solo falla algo; falla algo que ni siquiera sabíamos que estaba ahí, y entonces el primer tramo del incidente —a veces el más largo— se nos va en entender qué está pasando. Esa fase de \u0026ldquo;¿pero por qué se cayó esto si no tocamos nada?\u0026rdquo; es el costo puro de la invisibilidad. El tiempo que perdemos descubriendo la dependencia es tiempo en que el sistema está caído y nosotros, a ciegas. Lo que no conocemos no nos da la cortesía de avisarnos antes de romperse.\nEl momento en que lo invisible se vuelve visible # Cualquiera que haya estado en el medio de un incidente serio conoce ese momento, y no se olvida. Algo se cayó. Las alertas suenan, o peor, no suenan y nos enteramos porque un cliente avisa. El equipo se junta, físico o virtual, y empieza la cacería. Y en los incidentes que involucran una dependencia invisible, la cacería tiene una textura particular: no es \u0026ldquo;sabemos qué se rompió, vamos a arreglarlo\u0026rdquo;, es \u0026ldquo;no entendemos qué está pasando\u0026rdquo;. Esa diferencia, que parece sutil, es la que estira los incidentes de minutos a horas.\nLo viví más de una vez, y el patrón se repite. Revisamos lo obvio, lo que está en el diagrama, lo que sabemos que es crítico. Todo parece estar bien. La base de datos responde, la aplicación está arriba, la nube no reporta nada. Y sin embargo el sistema no funciona. Pasan los minutos, sube la presión, alguien de negocio pregunta cuánto falta, y nosotros seguimos sin entender. Hasta que en algún momento, casi por casualidad, alguien tira una hipótesis sobre algo que ni figuraba en nuestra cabeza como parte del sistema: un certificado que venció, un servicio de un proveedor que cambió algo sin avisar, una cuenta que perdió permisos, un límite que se alcanzó en silencio. Y ahí está, la dependencia invisible, mostrándose por fin, después de habernos hecho perder un tiempo precioso simplemente porque no sabíamos que existía.\nLo más frustrante de esos incidentes no es el daño técnico, que muchas veces se arregla rápido una vez que entendemos. Lo más frustrante es la sensación de haber estado a ciegas en nuestra propia casa, de no conocer el sistema que se supone que manejamos. Y es una frustración honesta, porque tiene razón: no lo conocíamos del todo. Cada uno de esos incidentes es, en el fondo, una clase magistral, carísima y a destiempo, sobre una dependencia que podríamos haber mapeado tranquilos un mes antes. El incidente no nos enseña nada que no pudiéramos haber descubierto solos. Solo nos cobra mucho más caro la lección, y nos la da en el peor momento. Por eso insisto tanto con el ejercicio en frío: no es teoría de manual, es el intento de adelantarnos a esa madrugada en que el sistema nos enseña, a los golpes, lo que nunca nos sentamos a aprender por las buenas.\nQuiero proponer algo concreto, porque toda esta reflexión corre el riesgo de quedar en la queja si no aterriza en una acción. El ejercicio es simple de enunciar y revelador de hacer: tomar un servicio crítico del negocio —uno solo, el más importante— y preguntarse, con terquedad, qué necesita para funcionar. Y por cada respuesta, volver a preguntar: ¿y eso de qué depende? Es un por qué de niño insistente, aplicado a la infraestructura.\nSupongamos que el servicio crítico es \u0026ldquo;los clientes pueden iniciar sesión y operar\u0026rdquo;. Bien. Eso necesita la aplicación corriendo, que necesita la nube, que está clara. Pero también necesita la base de datos, que necesita su almacenamiento y sus credenciales. Necesita resolver nombres, o sea DNS. Necesita certificados válidos, o el navegador rechaza la conexión. Si el login usa un proveedor externo de identidad, necesita que ese proveedor esté arriba. Si manda un correo o un mensaje de verificación, necesita el servicio de envío. Si hay un balanceador, una cola, un caché, cada uno suma su propia cadena. Y de golpe, eso que en el diagrama eran tres cajas, en la realidad es una telaraña de quince o veinte piezas, varias de las cuales nadie había nombrado nunca en voz alta.\nLo interesante del ejercicio no es la lista final, aunque la lista final ya vale el esfuerzo. Lo interesante es lo que pasa mientras lo hacemos: las discusiones que aparecen, los \u0026ldquo;che, ¿y esto quién lo configuró?\u0026rdquo;, los silencios incómodos cuando nadie sabe responder de qué depende algo. Esos silencios son oro. Cada silencio es una dependencia invisible que acaba de empezar a volverse visible. Y no hace falta una herramienta cara ni un proyecto de seis meses para empezar: alcanza con una pizarra, un par de personas que conozcan distintas partes del sistema, y la disciplina de no conformarse con la primera respuesta.\nNo todas las dependencias pesan igual # Un riesgo de este ejercicio es que, una vez que empezamos a ver dependencias por todos lados, nos abrume. Si todo depende de todo, ¿por dónde empezamos? Acá entra una pregunta que ayuda a ordenar: por cada dependencia que encontramos, ¿qué pasa si falla? No todas las respuestas son iguales. Hay dependencias cuya caída detiene todo el negocio, y hay otras cuya caída apenas degrada una función secundaria que puede esperar. Tratarlas igual sería tan ingenuo como ignorarlas.\nLa pregunta del \u0026ldquo;qué pasa si falla\u0026rdquo; tiene varias capas que conviene separar. Una cosa es cuánto duele que falle —si frena el negocio entero o solo una parte—. Otra es qué tan probable es que falle, que no siempre va de la mano con lo anterior. Y una tercera, que solemos olvidar, es si nos daríamos cuenta de que falló: hay dependencias que cuando se rompen avisan a los gritos, y otras que fallan en silencio y solo descubrimos el problema mucho después, cuando el daño ya se acumuló. Una dependencia que duele mucho, falla seguido y encima falla en silencio es una bomba de tiempo. Una que duele poco, casi nunca falla y avisa cuando lo hace, puede esperar. Entre esos dos extremos está casi todo, y el trabajo de criterio es ubicar cada pieza en ese mapa. La resiliencia no consiste en blindar absolutamente todo —sería carísimo e imposible—, sino en saber qué blindar primero.\nLa dependencia más invisible suele ser la confianza # Quiero detenerme en un tipo particular de dependencia invisible, porque es la que más me preocupa y la que peor mapeamos: la confianza. Cuando usamos un proveedor que nunca nos falló, dejamos de verlo como una dependencia y empezamos a tratarlo como parte del paisaje, como si fuera el aire. Cuanto mejor funciona algo, más invisible se vuelve, y más nos olvidamos de que podría dejar de funcionar. La paradoja es brutal: las dependencias más confiables son, por eso mismo, las que peor monitoreamos, porque su misma confiabilidad nos invita a dejar de prestarles atención.\nEsto vale para proveedores, pero también para piezas internas. Ese servicio que escribió un equipo hace cinco años y que nunca, jamás, dio un problema. Justamente porque nunca falló, nadie lo documentó bien, nadie lo monitorea de cerca, nadie sabría qué hacer si un día se cae. Su historial impecable se convirtió, sin que nadie lo decidiera, en una excusa para ignorarlo. Y el día que falle —porque todo falla alguna vez— vamos a descubrir que no teníamos ni idea de cómo funcionaba por dentro. La confiabilidad histórica no es una garantía futura; es, a lo sumo, una invitación peligrosa a la complacencia. Confiar en un proveedor o en un componente está bien. Dejar de gestionarlo porque confiamos, no.\nMapear no es un proyecto, es una práctica # Si hay algo que aprendí, es que este tipo de mapeo no funciona como un proyecto con principio y fin. No sirve hacer un documento perfecto de dependencias en marzo y archivarlo, porque para junio ya está desactualizado: el sistema siguió creciendo, se sumaron integraciones, se cambió un proveedor, alguien conectó algo nuevo. Un mapa de dependencias congelado es casi tan engañoso como no tener ninguno, porque nos da una falsa sensación de que sabemos, cuando en realidad sabemos cómo eran las cosas hace tres meses.\nLo que sí funciona es convertirlo en una práctica viva, en un hábito. Que cada vez que sumamos una integración nueva, la pregunta \u0026ldquo;¿qué dependencia nueva estamos creando y qué pasa si falla?\u0026rdquo; sea parte natural de la conversación, no un trámite. Que revisar el mapa cada tanto sea una rutina, como revisar los backups. Que cuando alguien se va del equipo, una de las preguntas sea \u0026ldquo;¿qué dependencias vivían en su cabeza?\u0026rdquo;. No es glamoroso, lo sé. No hay una herramienta que lo resuelva con un clic, aunque varias ayudan. Es, sobre todo, una cuestión de cultura: la diferencia entre un equipo que sabe de qué depende y uno que lo va a descubrir de la peor manera está mucho menos en las herramientas que en el hábito de preguntárselo.\nLo que el mapa nos devuelve # Vale la pena decir que este ejercicio, más allá de prepararnos para incidentes, tiene un beneficio que aparece antes de cualquier caída. Mapear de qué dependemos nos obliga a entender nuestro propio sistema con una profundidad que la operación diaria no exige. Y entender mejor lo que tenemos casi siempre mejora las decisiones que tomamos hacia adelante.\nUn equipo que conoce sus dependencias decide distinto. Piensa dos veces antes de sumar la integración número treinta y uno. Negocia mejor con sus proveedores, porque sabe exactamente qué tan atado está. Detecta antes la concentración de riesgo, esa situación incómoda en que demasiadas cosas críticas dependen de una misma pieza. Documenta lo que importa porque sabe qué importa. El mapa de dependencias no es solo un seguro contra el desastre; es también una herramienta de diseño, una forma de ver el sistema con honestidad que termina influyendo en cómo lo hacemos crecer. A veces, el solo hecho de hacer visible una dependencia ya cambia la decisión de mantenerla.\nLa incomodidad como aliada # Voy a volver al principio, a esa incomodidad del ejercicio en frío. Porque creo que ahí está el verdadero obstáculo, y no es técnico. El problema no es que mapear dependencias sea difícil de hacer; el problema es que es incómodo de enfrentar. Sentarse a descubrir que dependemos de cosas que no controlamos, que no entendemos del todo, que viven en la cabeza de una sola persona o en un servicio que nadie mira, no es una experiencia agradable. Es mucho más cómodo seguir operando con la ilusión de que todo está bajo control, mirando el diagrama lindo en vez de la telaraña real.\nPero esa incomodidad es exactamente la señal de que el ejercicio está funcionando. Cada cosa que nos incomoda descubrir es una cosa que ya estaba ahí, latente, esperando el peor momento para mostrarse. Hacerla visible no crea el problema: el problema ya existía. Lo único que hacemos al mapear es elegir descubrirlo nosotros, en nuestros términos, un día tranquilo, en lugar de que nos lo descubra un incidente en el peor momento posible. La incomodidad de saber siempre va a ser más barata que la sorpresa de no saber.\nMe quedo, entonces, con la invitación a hacer ese ejercicio incómodo, y con una pregunta que cada uno puede llevarse a su propio sistema. Si tuvieran que escribir ahora mismo, de memoria, la lista completa de cosas de las que depende su servicio más crítico, ¿cuán larga sería esa lista, y cuánto de lo que de verdad la sostiene quedaría afuera por la simple razón de que nunca, hasta hoy, se molestó en fallar? Porque las dependencias que no sabíamos que teníamos no dejan de existir por no conocerlas. Solo esperan, pacientes, el día en que ya no podamos seguir ignorándolas.\n","date":"20 de abril de 2025","externalUrl":null,"permalink":"/blog/post-las-dependencias-que-no-sabiamos-que-teniamos/","section":"Blog","summary":"Toda organización conoce sus dependencias visibles: la base de datos, la nube, el sistema de pagos. El problema son las invisibles, las que nadie anotó en ningún diagrama y que descubrimos recién cuando se caen. Mapearlas no es una tarea técnica más: es la base de cualquier resiliencia real, porque no se puede proteger ni recuperar lo que no se conoce.","title":"Las dependencias que no sabíamos que teníamos","type":"blog"},{"content":"","date":"4 de abril de 2025","externalUrl":null,"permalink":"/tags/especificaciones/","section":"Tags","summary":"","title":"Especificaciones","type":"tags"},{"content":"","date":"4 de abril de 2025","externalUrl":null,"permalink":"/tags/programacion/","section":"Tags","summary":"","title":"Programacion","type":"tags"},{"content":"","date":"4 de abril de 2025","externalUrl":null,"permalink":"/tags/trabajo-en-equipo/","section":"Tags","summary":"","title":"Trabajo-en-Equipo","type":"tags"},{"content":"Voy a empezar con una confesión que tal vez no esperan de alguien que lleva más de tres décadas en esto: el vibe coding me deslumbró. Lo probé en estas últimas semanas, cuando el término empezó a estar en todos lados, y la experiencia me sacudió de verdad. Ver cómo una idea descrita en lenguaje natural se convertía en algo que funcionaba, en minutos, sin escribir una línea a mano, me hizo sentir esa mezcla rara de entusiasmo y vértigo que no sentía hacía mucho. Por un rato me olvidé del código. Hablaba, probaba, corregía con otra frase, y la cosa avanzaba. Y sin embargo, casi en el mismo momento en que me maravillaba, una alarma se encendió en algún lado de mi cabeza. No una alarma de \u0026ldquo;esto no sirve\u0026rdquo; —porque sí sirve, y mucho—, sino una más incómoda: \u0026ldquo;esto, llevado a una empresa con equipos y sistemas en producción, se va a salir de control si no entendemos qué estamos haciendo\u0026rdquo;. Deslumbramiento y advertencia, el mismo día. De esa tensión quiero hablar acá, porque es la más honesta y la más interesante.\nQué es el vibe coding, en pocas palabras # A principios de febrero, Andrej Karpathy —cofundador de OpenAI, ex líder de IA en Tesla, una de las voces que la industria escucha— publicó un mensaje breve que terminó nombrando algo que muchos ya estábamos sintiendo sin saber cómo llamarlo. Habló de \u0026ldquo;una nueva forma de programar\u0026rdquo; en la que uno \u0026ldquo;se entrega del todo a las vibras, abraza los exponenciales y se olvida de que el código siquiera existe\u0026rdquo;. La describió como una experiencia donde le pega los errores a la IA sin siquiera leerlos, acepta los cambios que propone, y deja que el sistema crezca aunque ya no entienda del todo cómo funciona por dentro. Y aclaró algo importante, que después muchos pasaron por alto: que esto le resultaba ideal para \u0026ldquo;proyectos desechables de fin de semana\u0026rdquo;.\nEl término prendió fuego. En cuestión de semanas pasó de un mensaje en una red social a estar en el New York Times, en Ars Technica, en The Observer, e incluso a aparecer listado en un diccionario como palabra de tendencia. Y prendió porque le puso nombre a un cambio real: los modelos de lenguaje orientados a programación llegaron a un punto en el que, para ciertas cosas, \u0026ldquo;mostrás, decís, corrés, copiás y pegás, y mayormente funciona\u0026rdquo;. Esa es la cita de Karpathy, y captura bien la sensación. El rol del que construye software se corre del teclado hacia la conversación.\nConviene marcar desde el principio una distinción que el propio campo ya está discutiendo. No todo desarrollo asistido por IA es vibe coding. Simon Willison, que es un entusiasta de estas herramientas y no un detractor, lo planteó con una claridad que ayuda mucho a ordenar la discusión: si la IA escribió cada línea de nuestro código pero lo revisamos, lo probamos y lo entendimos todo, eso no es vibe coding, es usar la IA como asistente de tipeo. El vibe coding, en su versión pura, implica justamente lo contrario: confiar en la IA para los detalles, aceptar sin revisar, iterar sobre el comportamiento y no sobre el código. La diferencia no es un capricho de definición. Es la diferencia entre dos prácticas que se parecen por fuera y son opuestas por dentro.\nPor qué me deslumbró (y por qué eso importa) # Quiero ser honesto sobre lo que sentí, porque creo que descartarlo sería deshonesto y también un error de análisis. Hay algo genuinamente nuevo acá. Durante años, la distancia entre tener una idea y tener algo funcionando fue enorme: había que conocer un lenguaje, un framework, configurar un entorno, entender mil detalles antes de ver el primer resultado. El vibe coding colapsa esa distancia de una manera que, cuando la experimentamos de primera mano, es difícil de no encontrar mágica. Pensamos algo, lo decimos, y aparece. Iteramos hablando. El cuello de botella deja de ser la sintaxis y pasa a ser la claridad de la idea.\nEso tiene un valor real, y no solo para no programadores. Para alguien con experiencia, el vibe coding es un acelerador brutal de exploración. Quiero probar si una idea tiene sentido, quiero ver una primera versión, quiero validar un enfoque antes de comprometerme: todo eso, que antes llevaba horas o días, ahora puede llevar minutos. La capacidad de prototipar a esa velocidad cambia cómo pensamos los problemas, porque baja tanto el costo de experimentar que nos animamos a probar caminos que antes ni considerábamos por pereza o por costo. En ese terreno —exploración, prototipos, prueba de conceptos, herramientas personales— el vibe coding no solo funciona: es una de las mejores cosas que le pasaron al desarrollo en mucho tiempo.\nY vale la pena decir esto fuerte, porque la reacción fácil de alguien de mi generación sería el desdén: \u0026ldquo;esto no es programar de verdad\u0026rdquo;. Es una reacción cómoda y, creo, equivocada. Es la misma reacción que tuvieron en su momento contra los lenguajes de alto nivel, contra los frameworks, contra todo lo que subió el nivel de abstracción y dejó que más gente construyera cosas. El desdén envejece mal. La pregunta interesante nunca es si una herramienta nueva \u0026ldquo;es programar de verdad\u0026rdquo;, sino qué habilita, qué riesgos trae y dónde conviene usarla. Y ahí es donde, el mismo día que me deslumbré, se me encendió la alarma.\nEl momento exacto en que se encendió la alarma # Estaba en plena sesión de vibe coding, encantado, cuando me pregunté algo casi de reflejo, por costumbre de tantos años: \u0026ldquo;si esto que estoy haciendo lo tuviera que retomar otra persona la semana que viene, ¿podría?\u0026rdquo;. Y la respuesta, fría, fue que no. No porque el código estuviera mal, sino porque en ningún lado había quedado registrado qué le había pedido a la IA, en qué orden, con qué intención, qué descartamos y por qué, qué supuestos tomó ella por su cuenta. Todo eso vivía en una conversación efímera y en mi cabeza. El resultado existía; el camino para llegar a él, no. Y en software, muchas veces, el camino importa tanto como el destino.\nEse fue el momento. Me di cuenta de que el vibe coding, tal como lo estaba viviendo, no tenía versionado de especificaciones. Tenía versionado de código —el código está ahí, en el archivo— pero no tenía registro de las decisiones, de los requerimientos, de la intención que guió cada paso. Y eso, para un proyecto personal de fin de semana, es perfectamente aceptable. El propio Karpathy lo encuadró así. Pero mi cabeza no estaba pensando en un proyecto de fin de semana. Estaba pensando, inevitablemente, en empresas de software con equipos de varias personas, donde el código que escribimos hoy lo va a mantener otro dentro de seis meses, donde las decisiones tienen que poder explicarse, donde nadie trabaja solo. Y ahí la cosa cambia por completo.\nEl problema no es la IA, es lo que dejamos de versionar # Durante décadas, la industria del software aprendió, a los golpes, a versionar el código. El control de versiones fue una de las grandes conquistas de nuestra disciplina: poder saber quién cambió qué, cuándo y por qué, poder volver atrás, poder trabajar muchas personas sobre la misma base sin pisarnos. Cuesta imaginar hoy un equipo serio que no versione su código. Es parte del aire que respiramos.\nPero el vibe coding introduce una pregunta que no teníamos del todo resuelta: ¿qué pasa con el versionado de la intención? Cuando yo escribía código a mano, la intención estaba, de alguna forma imperfecta, embebida en el código mismo y en los commits. Cuando le pido a una IA que genere ese código a partir de una conversación, la intención vive en otro lado: en los prompts, en el contexto que le di, en las correcciones que fui haciendo. Y eso, hoy, en la práctica del vibe coding puro, no se versiona. Se evapora cuando cierro la sesión. Lo que queda es el resultado, huérfano de su porqué.\nPensémoslo así. Si dentro de seis meses ese código falla, o hay que extenderlo, o cambia un requerimiento del negocio, el que lo tenga que tocar va a encontrarse con un código que nadie escribió en el sentido tradicional, generado a partir de una conversación que ya no existe, guiado por decisiones que no están documentadas. No va a poder reconstruir por qué se hizo así. Va a tener que, en el mejor de los casos, volver a entender todo desde cero, o peor, volver a vibe-codear encima, acumulando capas de decisiones sin registro sobre decisiones sin registro. Lo vi venir clarísimo en esa sesión, y me incomodó, porque era exactamente el tipo de deuda que tardamos años en aprender a evitar y que esta forma de trabajar reintroduce por una puerta nueva.\nLo que no se organiza, la IA lo completa sola # Hay otra cosa que entendí casi al mismo tiempo, y que tiene que ver con cómo le hablamos a la IA. Cuando uno hace vibe coding, le da pedidos en lenguaje natural, muchas veces vagos, casi siempre incompletos. Y la IA, lejos de detenerse a preguntar, completa los huecos. Toma decisiones. Elige una estructura, una librería, un patrón, un enfoque. Lo hace con una seguridad que es convincente y, hay que decirlo, a menudo razonable. El problema es que esas decisiones quedan invisibles. Uno ve el resultado funcionando y asume que las decisiones de fondo fueron buenas, cuando en realidad nunca las revisó, ni siquiera supo que se habían tomado.\nEn un proyecto personal, da igual. Si funciona, funciona. Pero en un producto de software de empresa, esas decisiones invisibles son precisamente las que después se pagan caro. Una librería que no deberíamos haber sumado. Un patrón que contradice el resto del sistema. Una validación de seguridad que la IA no puso porque nadie se la pidió. Una lógica de negocio que la IA interpretó a su manera porque el pedido era ambiguo. Cada una de esas cosas, sola, parece menor. Juntas, y multiplicadas por la velocidad a la que el vibe coding genera, construyen un sistema que nadie diseñó del todo y que nadie entiende del todo.\nEsto me conecta con algo que vengo pensando hace tiempo y que ya escribí en otro lado: si la IA tiende a completar los vacíos con supuestos, nuestra responsabilidad pasa a ser reducir esos vacíos. No alcanza con pedirle a la IA \u0026ldquo;hacé esto\u0026rdquo;; hay que organizar de antemano qué queremos que haga, con qué reglas, con qué límites. El vibe coding, en su forma pura, va exactamente en la dirección contraria: celebra el no organizar, el dejarse llevar, el no pensar demasiado en la estructura. Y eso, que es liberador para explorar, es peligroso para construir algo que va a durar y que otros van a mantener.\nEl verdadero punto de quiebre: el trabajo en equipo # Si tuviera que señalar dónde el vibe coding pasa de \u0026ldquo;herramienta maravillosa\u0026rdquo; a \u0026ldquo;problema serio\u0026rdquo;, no dudaría: es cuando dejamos de ser una persona y pasamos a ser un equipo. Y acá hablo desde lo que conozco, desde haber estado en empresas de software con equipos de varias personas trabajando sobre los mismos sistemas. Porque una cosa es que yo vibe-codee mi prototipo, solo, entendiendo —o asumiendo que entiendo— lo que está pasando. Otra muy distinta es imaginar a cinco, diez, quince personas vibe-codeando en paralelo sobre el mismo producto, cada una con su conversación privada con la IA, cada una tomando decisiones que no quedan registradas, cada una generando código a una velocidad que nadie alcanza a revisar.\nPensemos qué significa eso en concreto. En un equipo, el código no es solo código: es un lenguaje común. Es la forma en que nos coordinamos, en que entendemos lo que hizo el otro, en que repartimos el trabajo sin chocarnos. Cuando alguien escribe código a mano, deja pistas: nombres, estructura, comentarios, commits, una lógica que otro puede seguir. Cuando ese código sale de conversaciones efímeras con una IA, multiplicadas por la cantidad de personas del equipo, esas pistas se diluyen. De repente tenemos un sistema construido por muchas manos a través de muchas conversaciones que nadie más vio, donde la coherencia que antes nos daba el lenguaje común del código empieza a resquebrajarse.\nY la velocidad, que en lo individual es una bendición, en lo colectivo se vuelve un agravante. Porque el cuello de botella del desarrollo nunca fue solamente escribir código. Fue entenderlo, coordinarlo, integrarlo, revisarlo, mantenerlo. El vibe coding acelera muchísimo la parte de escribir, pero no acelera —y en algunos casos empeora— la parte de entender y coordinar. Un equipo que produce diez veces más código del que puede revisar y comprender no es un equipo diez veces más productivo: es un equipo que está acumulando, diez veces más rápido, una deuda que va a pagar después. Lo dije una vez y lo sostengo: más código no es mejor software. Y más código generado sin registro, en equipo, es la receta más rápida que conozco para un caos difícil de gobernar.\nUna preocupación aparte: los que recién empiezan # Hay un costado de todo esto que me preocupa de una forma distinta, más a largo plazo, y tiene que ver con quienes están aprendiendo a programar ahora, en plena ola del vibe coding. Cuando yo aprendí, no había atajo: para que algo funcionara, había que entender por qué funcionaba. El error me obligaba a aprender. La fricción, que tantas veces maldije, era también la maestra. Cada bug que peleaba durante horas me dejaba un conocimiento que no se olvida. El que recién empieza hoy puede saltarse buena parte de esa fricción, y eso tiene una cara luminosa —puede construir cosas mucho antes, mantenerse motivado, ver resultados— pero también una sombra que no conviene ignorar.\nMi temor es que se confunda \u0026ldquo;lo logré\u0026rdquo; con \u0026ldquo;lo entiendo\u0026rdquo;. Que alguien junior, deslumbrado por la velocidad, acumule la sensación de competencia sin la competencia. Porque el día que el sistema falle de una manera que la IA no puede resolver sola —y ese día llega, siempre llega— el que no construyó los fundamentos va a quedar a la intemperie. No va a poder depurar lo que no entiende. No va a poder distinguir una buena sugerencia de la IA de una mala, porque para juzgar hace falta saber. La IA puede acelerar muchísimo a alguien que ya tiene criterio, pero a alguien que todavía no lo tiene puede darle una falsa autonomía que se derrumba en el primer problema serio.\nNo estoy diciendo que los que empiezan ahora no deban usar vibe coding. Sería ridículo e inútil pedir eso. Lo que digo es que, como industria y como personas que formamos equipos, tenemos una responsabilidad nueva: asegurarnos de que la herramienta no se coma el aprendizaje. Que vibe-codear sea una puerta de entrada al entendimiento, no un reemplazo de él. Que el junior que genera código con IA también sea empujado, con cariño pero con firmeza, a entender qué generó y por qué. Porque la abstracción siempre fue parte de la programación —nadie programa hoy en código de máquina— pero hay una diferencia entre apoyarnos en una abstracción que entendemos y delegar en una caja negra que no. La primera nos hace más productivos. La segunda nos vuelve frágiles.\nHay un dato de estas semanas que me dejó pensando. Se reportó que alrededor de una cuarta parte de las startups de un lote reciente de Y Combinator tenían bases de código generadas casi en su totalidad por IA. Es un número enorme, y a primera vista parece la prueba de que el vibe coding ya es el futuro del desarrollo profesional. Pero yo lo leo distinto, y la diferencia es crucial.\nUna startup en etapa muy temprana es, en muchos sentidos, un prototipo gigante. Está buscando si su idea tiene sentido, está iterando rapidísimo, está dispuesta a tirar todo y empezar de nuevo si hace falta. En ese contexto, el vibe coding es ideal: la velocidad vale más que la mantenibilidad, porque tal vez ese código ni siquiera exista en seis meses. Pero esa lógica no se traslada automáticamente a una empresa de software establecida, con clientes que dependen del sistema, con código que tiene que vivir años, con equipos que tienen que coordinarse, con cumplimiento, con seguridad, con responsabilidad sobre lo que está en producción. Confundir \u0026ldquo;esto funciona para una startup de tres personas que prototipa\u0026rdquo; con \u0026ldquo;esto funciona para cualquier desarrollo de software profesional\u0026rdquo; es, me parece, uno de los errores de interpretación más peligrosos de este momento.\nEl propio Karpathy fue cuidadoso al encuadrarlo en proyectos desechables. Willison fue explícito al decir que vibe-codear hasta una base de código de producción es claramente una mala idea, y eso lo dice alguien que ama estas herramientas. El problema no es lo que dijeron los que pensaron el concepto. El problema es cómo el entusiasmo colectivo le borra los matices a las ideas. \u0026ldquo;Vibe coding\u0026rdquo; empezó siendo un nombre para una práctica específica y acotada, y en cuestión de semanas se está convirtiendo en una etiqueta para todo el desarrollo con IA, perdiendo justamente la advertencia que venía incluida en el paquete original.\nEntonces, ¿qué hacemos? Ni prohibirlo ni rendirnos # Quiero ser claro en algo, porque sería fácil leer todo esto como una condena, y no lo es: no estoy en contra del vibe coding. Lo usé, me cambió la forma de ver las cosas, y voy a seguir usándolo. Estoy en contra de usarlo sin entender dónde sirve y dónde se vuelve peligroso. Y creo que el camino no es ni prohibirlo en las empresas —sería absurdo, además de inútil, porque la gente lo va a usar igual— ni adoptarlo sin reglas, dejándonos llevar por las vibras hasta que un día nos demos cuenta de que tenemos un producto que nadie entiende.\nMe parece que la clave está en separar los contextos con honestidad. Para explorar, prototipar, validar ideas, construir herramientas internas descartables o destrabar un experimento, el vibe coding es excelente, y restringirlo ahí sería matar su mejor virtud. Pero para el código que va a producción, que van a mantener otros, que tiene que durar y coordinarse en equipo, hace falta algo más. Hace falta recuperar, adaptadas a esta nueva forma de trabajar, las cosas que aprendimos a los golpes: versionar no solo el código sino la intención, registrar las especificaciones y las decisiones, organizar de antemano qué queremos que la IA construya en lugar de improvisarlo en una conversación, y revisar de verdad lo que se genera antes de aceptarlo. En cierto sentido, el desafío es traer disciplina a una práctica que nació, justamente, como la celebración de la falta de disciplina.\nY esto me lleva a una idea que me da vueltas y que dejo como debate abierto, porque no tengo la respuesta cerrada. Quizás lo que necesitamos no es elegir entre vibe coding y desarrollo riguroso, sino construir una forma nueva que tome la velocidad del primero y la disciplina del segundo. Una forma donde la conversación con la IA no se evapore, sino que quede versionada como un artefacto más del proyecto. Donde antes de vibe-codear algo serio, el equipo haya acordado y escrito qué quiere lograr, con qué reglas, con qué límites, de modo que la IA tenga contexto y no tenga que rellenar huecos con supuestos. Donde la revisión humana siga siendo innegociable para lo que va a producción. No sé todavía qué forma exacta va a tomar eso, ni qué herramientas lo van a soportar, pero intuyo que ahí está parte de hacia dónde tenemos que mirar.\nVersionar la intención: una idea para dejar sobre la mesa # Quiero detenerme un poco más en esa idea que mencioné antes, la del versionado de la intención, porque creo que ahí hay algo que vale la pena discutir en serio y que todavía nadie resolvió bien. Pensémoslo despacio. Hoy versionamos el código, que es el resultado. Pero en el vibe coding, el resultado se genera a partir de algo que no versionamos: la conversación, los prompts, el contexto, las decisiones que la IA tomó por nosotros. Es como si guardáramos la foto final pero tiráramos los negativos, el guión y las notas de dirección. Mientras el código lo escribíamos a mano, esa pérdida no dolía tanto, porque la intención quedaba más o menos impresa en el propio código. Cuando el código nace de una conversación efímera, la pérdida se vuelve grave.\n¿Y si empezáramos a tratar la especificación —lo que queremos que el sistema haga, con qué reglas, con qué límites— como un artefacto de primera clase del proyecto, versionado junto al código, evolucionando con él? No hablo de volver a los documentos de requisitos eternos de hace veinte años, esos que nadie leía y que envejecían antes de terminarse. Hablo de algo más vivo: un registro conciso y mantenido de la intención, que sirva tanto para que un humano nuevo entienda el porqué como para darle a la IA el contexto que necesita para no rellenar huecos con supuestos. Si la IA va a construir a partir de lo que le decimos, entonces lo que le decimos merece el mismo cuidado que le damos al código. Merece versionarse, revisarse, discutirse en equipo.\nLo dejo planteado como debate, no como receta, porque honestamente no sé todavía qué forma va a tomar ni qué herramientas lo van a soportar. Tal vez surjan formatos nuevos para esto. Tal vez los repositorios incorporen la especificación y el contexto de IA como parte natural de lo que guardan. Tal vez aparezca una disciplina entera alrededor de cómo darle contexto estructurado a la IA en un equipo, igual que en su momento apareció toda una disciplina alrededor del control de versiones. Lo que sí intuyo es que las organizaciones que resuelvan bien este problema —cómo combinar la velocidad del vibe coding con un registro versionado de la intención— van a tener una ventaja real sobre las que sigan generando código a la velocidad de la luz sin saber, dentro de seis meses, por qué su sistema hace lo que hace. La velocidad sin memoria es deuda. La velocidad con memoria es productividad. La diferencia está, justamente, en lo que decidamos versionar.\nEl rol del que lidera, otra vez en el centro # Si hay algo que esta sacudida me confirma, es que el rol de quien conduce equipos de tecnología se vuelve más importante, no menos. Cuando aparece una herramienta tan seductora y tan veloz, la tentación del equipo es lanzarse a usarla sin acuerdos, cada uno por su lado. Y el trabajo de liderar, en parte, es no apagar ese entusiasmo —sería un error matarlo— sino encauzarlo. Crear el espacio para que el equipo experimente con vibe coding donde tiene sentido, y al mismo tiempo establecer con claridad qué no aceptamos sin revisión, qué información sensible no se pega en una herramienta externa, cómo registramos las decisiones tomadas con ayuda de IA, qué nivel de comprensión exigimos del código que llega a producción.\nNo es control por el control mismo. Es la diferencia entre un equipo que usa una herramienta poderosa con criterio y uno que es usado por la herramienta. Y esa diferencia, en una empresa de software, se nota rápido: en la calidad de lo que se entrega, en cuánto cuesta mantenerlo, en cuántos incidentes aparecen, en si las personas todavía entienden el sistema que construyen o si pasaron a ser meros intermediarios entre el cliente y una IA que nadie supervisa de verdad. Liderar en esta época es, cada vez más, ayudar a la gente a distinguir entre la velocidad que suma y la velocidad que esconde problemas.\nLo que me queda dando vueltas # Termino donde empecé, con esa tensión del primer día. El vibe coding me deslumbró y me asustó casi en el mismo momento, y con el tiempo entendí que esas dos reacciones no se contradicen: las dos son correctas. Es una de las cosas más entusiasmantes que vi en años, y también una de las que más fácil puede salirse de control si la llevamos a contextos para los que no fue pensada. La magia es real. El riesgo también. Y la madurez, como casi siempre, no está en quedarse con una sola de las dos verdades, sino en sostener las dos a la vez.\nMe quedo con varias preguntas, más que con conclusiones, porque creo que este tema recién empieza y cualquier certeza hoy sería apresurada. ¿Cómo versionamos la intención y no solo el código? ¿Cómo trabajamos en equipo con vibe coding sin perder el lenguaje común que nos coordina? ¿Cómo aprovechamos su velocidad para explorar sin dejar que esa velocidad nos arrastre a producción? ¿Cómo enseñamos a los que recién empiezan a usar esta herramienta sin que confundan \u0026ldquo;funciona\u0026rdquo; con \u0026ldquo;está bien hecho\u0026rdquo;? No tengo todas las respuestas, y desconfío de quien diga que las tiene a tres semanas de que el término existe.\nLo que sí tengo es una convicción, formada en esa primera sesión donde el deslumbramiento y la alarma convivieron: el vibe coding no es el problema ni la solución. Es una herramienta nueva y potente que nos obliga, una vez más, a hacernos las preguntas de siempre con una urgencia nueva. Qué queremos construir, para qué, con qué cuidado, y quién se hace responsable cuando lo que generamos en una conversación de cinco minutos termina, sin que nos diéramos cuenta, sosteniendo algo que importa. Se los dejo para que lo piensen en su propio terreno: la próxima vez que una herramienta nos haga sentir que el trabajo se volvió mágicamente fácil, ¿esa facilidad está resolviendo el problema, o solo lo está corriendo unos meses hacia adelante, hacia el momento en que alguien —quizás nosotros mismos— tenga que entender lo que nadie se detuvo a entender?\nFuentes consultadas # Andrej Karpathy, publicación original sobre \u0026ldquo;vibe coding\u0026rdquo; en X, 2 de febrero de 2025. Benj Edwards, \u0026ldquo;Will the future of software development run on vibes?\u0026rdquo;, Ars Technica, 5 de marzo de 2025. Simon Willison, \u0026ldquo;Not all AI-assisted programming is vibe coding (but vibe coding rocks)\u0026rdquo;, 19 de marzo de 2025. Ivan Mehta, \u0026ldquo;A quarter of startups in YC\u0026rsquo;s current cohort have codebases that are almost entirely AI-generated\u0026rdquo;, TechCrunch, 6 de marzo de 2025. John Naughton, \u0026ldquo;Now you don\u0026rsquo;t even need code to be a programmer. But you do still need expertise\u0026rdquo;, The Observer, 16 de marzo de 2025. ","date":"4 de abril de 2025","externalUrl":null,"permalink":"/blog/post-vibe-coding-lo-probe-me-encanto-y-me-asuste/","section":"Blog","summary":"El vibe coding me cambió la forma de ver el desarrollo de software. Pero el mismo día que me deslumbró, también vi el problema: sin versionado de especificaciones, sin organizar qué queremos que haga la IA, y especialmente al trabajar en equipo, esta forma de programar puede volverse un caos difícil de gobernar. No estoy en contra. Estoy a favor de entenderlo antes de que nos arrastre.","title":"Vibe coding: lo probé, me encantó y me asusté el mismo día","type":"blog"},{"content":"","date":"15 de febrero de 2025","externalUrl":null,"permalink":"/tags/deepseek/","section":"Tags","summary":"","title":"Deepseek","type":"tags"},{"content":"","date":"15 de febrero de 2025","externalUrl":null,"permalink":"/tags/dependencia/","section":"Tags","summary":"","title":"Dependencia","type":"tags"},{"content":"","date":"15 de febrero de 2025","externalUrl":null,"permalink":"/tags/estrategia-tecnologica/","section":"Tags","summary":"","title":"Estrategia-Tecnologica","type":"tags"},{"content":"Hay una pregunta que me persigue desde hace años, y cada tanto algo la trae de vuelta con fuerza: ¿cuánto de lo que damos por cierto en tecnología es realmente verdad, y cuánto es simplemente algo que dejamos de cuestionar? Las últimas semanas fueron, para mí, un buen recordatorio de esa diferencia. Un modelo de inteligencia artificial salido de una empresa china relativamente desconocida bastó para que medio mundo, incluidos mercados financieros que mueven cifras inimaginables, se sacudiera en cuestión de días. Y lo que más me interesó no fue el modelo en sí —ya van a salir otros, mejores, la semana que viene o el mes que viene—, sino lo que su irrupción dejó al descubierto: la cantidad de supuestos que repetíamos como si fueran leyes físicas. Que hacía falta un presupuesto descomunal. Que el liderazgo estaba donde siempre había estado. Que más grande era, sí o sí, mejor. De eso quiero hablar acá. No del modelo, sino de nuestras certezas.\nLo que pasó, contado en pocas líneas # El 20 de enero, una empresa china llamada DeepSeek liberó un modelo de razonamiento al que bautizó R1. Hasta ahí, una noticia más en un campo que produce noticias todos los días. Lo que lo volvió distinto fueron dos cosas. La primera, que su desempeño se acercaba bastante al de los mejores modelos de razonamiento disponibles, esos que hasta hace poco parecían patrimonio exclusivo de un puñado de laboratorios occidentales con bolsillos profundos. La segunda, y para mí la más interesante, que lo hizo afirmando haber gastado una fracción de lo que esos laboratorios invierten, y lo publicó de forma abierta, con sus pesos disponibles para que cualquiera lo descargue, lo inspeccione y lo modifique.\nLa reacción fue rápida y desproporcionada en relación con cómo solemos tratar este tipo de lanzamientos. Para fin de enero, la aplicación de asistente conversacional de DeepSeek había escalado hasta lo más alto de las descargas en la tienda de Apple, trepó hasta el primer puesto de las apps más descargadas en la tienda de Apple en Estados Unidos, desplazando nada menos que a ChatGPT. Un inversor de los más ruidosos de Silicon Valley llegó a llamarlo \u0026ldquo;el momento Sputnik de la IA\u0026rdquo;, comparándolo con aquel satélite soviético de 1957 que obligó a Estados Unidos a repensar su lugar en la carrera espacial. Y el 27 de enero los mercados respondieron con una caída fuerte de las acciones de los fabricantes de chips y de varias de las empresas más expuestas a la promesa de la IA, borrando de golpe una cantidad enorme de valor bursátil.\nNo me interesa entrar en si la comparación con Sputnik es justa o exagerada, ni en la pelea geopolítica que se armó alrededor, ni siquiera en validar los números que DeepSeek puso sobre la mesa, varios de ellos en disputa desde el primer día. Me interesa otra cosa. Me interesa que un solo evento haya bastado para que tanta gente, de un día para el otro, empezara a dudar de cosas que venía repitiendo con total seguridad. Porque eso no dice tanto sobre DeepSeek como sobre la fragilidad de nuestras certezas.\nEl supuesto del presupuesto infinito # Durante el último par de años, una idea se instaló casi sin discusión: para jugar en la primera división de la inteligencia artificial hacían falta cifras de entrenamiento descomunales. Cientos de millones, miles de millones, infraestructura del tamaño de un país. La conversación pública estaba dominada por anuncios de inversiones gigantescas, y de tanto escucharlos terminamos asumiendo que el dinero era, lisa y llanamente, la barrera de entrada. Si no tenías ese capital, no estabas en la mesa.\nDeepSeek no demostró que esa idea sea completamente falsa —entrenar modelos de frontera sigue siendo caro, y la cifra que reportaron probablemente esconde costos que no están en el titular—, pero sí metió una astilla incómoda en la certeza. Si una empresa con recursos limitados, trabajando además bajo restricciones de acceso al mejor hardware, logró acercarse tanto, entonces quizás el presupuesto no era exactamente la barrera que creíamos. Quizás parte de esa cifra astronómica era necesaria, y parte era simplemente la forma en que un grupo de actores muy bien financiados decidió resolver el problema, porque podían permitírselo.\nY acá hay algo que en tecnología vemos todo el tiempo, lejos de los modelos de IA. Cuando una solución funciona y hay plata, rara vez nos preguntamos si era la forma más eficiente de resolverla. Funciona, listo, seguimos. La eficiencia se vuelve una preocupación recién cuando aparece la restricción: cuando el presupuesto se achica, cuando la infraestructura no da más, cuando alguien de afuera hace lo mismo gastando menos y nos obliga a mirar nuestros propios números con otros ojos. La restricción, muchas veces, es la que empuja la innovación real. Lo vi en proyectos chicos que resolvieron con ingenio lo que otros equipos, con muchísimos más recursos, resolvían a fuerza de comprar más servidores.\nEl supuesto del liderazgo permanente # El segundo supuesto que tambaleó fue más sutil, pero quizás más importante: la idea de que el liderazgo tecnológico, una vez conseguido, se queda donde está. Que los que están adelante van a seguir adelante, casi por inercia. Que existe una especie de foso, un \u0026ldquo;moat\u0026rdquo;, que protege a quien llegó primero y vuelve muy difícil que alguien lo alcance.\nEs una idea reconfortante si uno está adelante, y peligrosa por la misma razón. La historia de la tecnología está llena de liderazgos que parecían inamovibles y que dejaron de serlo. Empresas que dominaban un mercado y desaparecieron, no porque hicieran algo terriblemente mal, sino porque asumieron que su posición era permanente y dejaron de cuestionarse. El foso no es un accidente geográfico: hay que mantenerlo, y mantenerlo cuesta atención, humildad y la disposición a asumir que el que viene atrás puede estar resolviendo el problema de una manera que vos descartaste por comodidad.\nLo que DeepSeek puso sobre la mesa no fue tanto \u0026ldquo;China alcanzó a Occidente\u0026rdquo; —eso es un titular, y los titulares envejecen rápido— sino algo más general: la ventaja era menos sólida de lo que se asumía. Y eso aplica muchísimo más allá de la geopolítica de la IA. Aplica a cualquier organización, a cualquier producto, a cualquier equipo que crea que su posición está garantizada. La pregunta no es si tenemos una ventaja hoy, sino qué tan fácil sería para alguien construir algo equivalente, y qué estamos haciendo para que esa ventaja no se evapore mientras miramos para otro lado.\nEl supuesto de que más grande es mejor # El tercer supuesto, y el que más me interesa como persona técnica, tiene que ver con la fuerza bruta. Durante mucho tiempo la lógica dominante en IA fue, simplificando bastante, \u0026ldquo;más es más\u0026rdquo;: más datos, más parámetros, más cómputo, modelos más grandes. Y funcionó, no lo niego. Esa escala produjo avances reales. El problema es cuando una estrategia que funciona se convierte en la única estrategia que se considera, y lo que era un camino pasa a ser, sin que nadie lo decida explícitamente, el camino.\nParte de lo que llamó la atención de DeepSeek fueron las optimizaciones técnicas que reportaron para lograr más con menos: formas de reducir el cómputo necesario sin sacrificar tanto la calidad. Más allá de los detalles, que se discutirán y se replicarán o se desmentirán con el tiempo, lo relevante es el recordatorio: cuando la fuerza bruta es abundante y barata, la eficiencia deja de ser una prioridad. Y cuando deja de ser una prioridad, dejamos de buscarla. Nos volvemos perezosos, no por falta de talento, sino por exceso de recursos.\nEsto resuena con algo que aprendí en muchos años de mantener sistemas en producción. La solución más grande, la más cara, la que mete más máquinas al problema, no es necesariamente la mejor. A veces lo es. Pero muchas otras veces es solo la que está al alcance de quien tiene los recursos para no pensar demasiado. La elegancia técnica, la solución que hace lo mismo gastando menos, entendiendo mejor el problema, suele venir de equipos que no podían permitirse el lujo de la fuerza bruta. La escasez agudiza el ingenio. La abundancia, con frecuencia, lo adormece.\nLo abierto cambia la conversación # Hay un cuarto elemento en esta historia que no quiero pasar por alto, porque para una organización tiene consecuencias muy concretas: DeepSeek liberó su modelo de forma abierta. Cualquiera puede descargarlo, ejecutarlo en su propia infraestructura, estudiarlo, adaptarlo. Eso es distinto del modelo cerrado al que accedemos a través de una interfaz o una API, donde la empresa que lo construyó mantiene el control sobre los pesos y sobre las condiciones de acceso.\nNo quiero idealizar lo abierto, porque también trae sus complicaciones —preguntas sobre seguridad, sobre cómo se entrenó, sobre qué se puede y qué no se puede hacer con eso, sobre la confianza que merece un componente que vamos a meter en el corazón de un sistema—. Pero sí quiero señalar lo que habilita. Cuando un modelo capaz se vuelve descargable, baja la barrera para que organizaciones más chicas, equipos con menos recursos o lugares con menos acceso a infraestructura de punta puedan construir sobre esa base en lugar de empezar de cero. Cambia quién puede participar de la conversación.\nY cambia algo más, algo que toca de lleno a cualquier responsable de tecnología: la pregunta de la dependencia. Cuando dependemos de un modelo cerrado al que accedemos por una API, dependemos también de las decisiones de quien lo controla: sus precios, sus términos, su disponibilidad, su continuidad. Un modelo abierto, que puedo correr en mi propia infraestructura, ofrece una forma distinta de dependencia, con otras ventajas y otros costos. No digo que una opción sea mejor que la otra en abstracto; digo que la irrupción de alternativas abiertas y capaces nos obliga a tomar esa decisión con conciencia, en lugar de asumir que el único camino es atarse a un proveedor y rezar para que no cambie las reglas.\nLa trampa de reaccionar al titular # Ahora bien, hay una reacción que me parece tan equivocada como la certeza ciega que critiqué hasta acá, y es la reacción opuesta: el pánico. En estas semanas vi de todo. Gente declarando el fin del liderazgo occidental en IA. Gente diciendo que había que tirar a la basura toda la estrategia de inversión en infraestructura. Gente afirmando que las restricciones de hardware ya no servían para nada. Y gente, también, asegurando que todo era un truco, que las cifras eran mentira, que no había que prestarle atención.\nEsa oscilación entre el deslumbramiento y el desprecio es, en sí misma, otra forma de no pensar. Reaccionar al titular —para celebrarlo o para descartarlo— nos ahorra el trabajo más difícil, que es mirar con calma qué cambió de verdad y qué no. Lo que un evento como este merece no es una conclusión apresurada, sino una revisión honesta de nuestros supuestos. ¿Era el presupuesto la barrera que creíamos? Tal vez no del todo. ¿Está el liderazgo tan garantizado como asumíamos? Claramente no. ¿Es la fuerza bruta el único camino? Parece que no. Pero de ahí a saltar a \u0026ldquo;todo cambió\u0026rdquo; o \u0026ldquo;no cambió nada\u0026rdquo; hay un abismo, y ese abismo se cruza pensando, no reaccionando.\nEsto vale para la IA, pero vale para casi todo lo que llega como novedad disruptiva. La madurez técnica no está en abrazar cada anuncio ni en rechazarlo por reflejo. Está en la capacidad de sostener la incomodidad de no tener una opinión definitiva hasta haber entendido lo suficiente. Y esa incomodidad, en un mundo que premia la reacción inmediata, es cada vez más difícil de sostener.\nLo que esto significa para una organización real # Bajemos esto a tierra, porque toda esta reflexión corre el riesgo de quedar en lo abstracto. ¿Qué hace alguien que lidera tecnología en una empresa cuando pasa algo así? Lo primero, creo, es resistir la tentación de actuar de inmediato. No hay que salir corriendo a cambiar de proveedor porque apareció un modelo nuevo, ni a reescribir la estrategia porque un inversor habló de Sputnik en una red social. La gran mayoría de las decisiones que tomamos no deberían depender de qué modelo está de moda esta semana.\nLo segundo, y más valioso, es usar el evento como una excusa para revisar los propios supuestos. Si estábamos asumiendo que cierto proveedor era insustituible, conviene preguntarse qué tan cierto es eso hoy. Si dábamos por hecho que cierta capacidad solo estaba al alcance de los grandes, vale la pena verificar si eso sigue siendo así. Si elegimos una solución grande y costosa sin evaluar alternativas más eficientes, quizás sea momento de mirar de nuevo. El valor de un evento como DeepSeek, para una organización, no está en lo que hace DeepSeek, sino en las preguntas que nos obliga a hacernos sobre nuestras propias decisiones.\nY lo tercero, que es casi una postura ante la tecnología en general: cultivar la duda sana. No la duda paralizante, la que impide decidir, sino la que mantiene viva la pregunta. La que nos hace revisar cada tanto si lo que creemos saber sigue siendo verdad o si se convirtió, sin que nos diéramos cuenta, en un supuesto que dejamos de cuestionar. Las organizaciones que mejor se adaptan no son las que tienen más certezas, sino las que tienen mejores preguntas y la humildad de hacérselas aunque las respuestas resulten incómodas.\nLa ironía de la restricción # Hay un detalle en esta historia que merece una pausa, porque es profundamente contraintuitivo. Buena parte del contexto en el que apareció DeepSeek está marcado por las restricciones que Estados Unidos impuso sobre la exportación de los chips más avanzados, pensadas justamente para frenar el desarrollo de la IA en China. La lógica detrás de esas restricciones era simple: si limitamos el acceso al mejor hardware, limitamos la capacidad de competir. Y sin embargo, lo que muchos leyeron en este episodio fue casi lo opuesto. La restricción de acceso al hardware de punta pudo haber sido, paradójicamente, uno de los motores de la eficiencia.\nNo quiero afirmar esto como una certeza, porque caería en el mismo error que vengo criticando. Es una hipótesis, y habrá que ver cómo se sostiene con el tiempo. Pero la idea me resulta fascinante porque la vi funcionar en escalas mucho más chicas, una y otra vez, a lo largo de mi carrera. Cuando un equipo tiene acceso ilimitado a recursos, rara vez optimiza. ¿Para qué, si siempre puede sumar otra máquina, otro servicio, otra licencia? La optimización aparece cuando el recurso escasea. El programador que tiene que hacer que algo corra en un dispositivo modesto piensa la solución de otra manera que el que asume memoria y cómputo infinitos. La restricción no es solo un obstáculo: a veces es el incentivo que faltaba para buscar la solución elegante en lugar de la solución cara.\nEsto debería darnos que pensar sobre cómo diseñamos nuestros propios entornos de trabajo. No estoy proponiendo trabajar con las manos atadas ni celebrar la precariedad, que sería absurdo. Pero sí sospecho que la abundancia de recursos, cuando no viene acompañada de la disciplina de cuestionarse si los estamos usando bien, tiende a producir soluciones perezosas. El equipo que nunca tuvo que preocuparse por el costo de su infraestructura probablemente esté gastando de más sin saberlo. El que nunca tuvo que pelear con un presupuesto ajustado quizás nunca aprendió a distinguir lo necesario de lo cómodo. La restricción, bien entendida, es una maestra incómoda pero efectiva.\nEl liderazgo técnico frente a las modas # Quiero detenerme en algo que me toca de cerca, porque tiene que ver con el rol de quien conduce equipos de tecnología. Cuando aparece un evento como este, con toda su carga mediática, una de las cosas más difíciles de gestionar no es la tecnología en sí, sino la ansiedad que genera alrededor. De golpe llegan preguntas de todos lados: ¿no deberíamos estar usando esto? ¿no nos estamos quedando atrás? ¿por qué seguimos con el proveedor de siempre si apareció algo más barato? Son preguntas legítimas, y descartarlas de plano sería un error. Pero responderlas apresuradamente, dejándose llevar por el ruido, es un error todavía peor.\nParte del trabajo de liderar tecnología es, justamente, ser una especie de amortiguador entre el ruido del afuera y las decisiones del adentro. No para frenar la innovación ni para resistirse al cambio por comodidad, sino para asegurarse de que las decisiones se tomen por las razones correctas y no por la urgencia que impone un titular. Cambiar de tecnología tiene un costo real: migración, aprendizaje, riesgo, deuda nueva. Ese costo se justifica cuando hay un beneficio claro, no cuando lo único que cambió es qué nombre está de moda esta semana. Una de las cosas más valiosas que puede hacer alguien en esa posición es ayudar al equipo a distinguir entre lo que es urgente y lo que solo parece urgente porque está en todas las conversaciones.\nY hay una dimensión más, que es la del aprendizaje. Un evento como DeepSeek es una oportunidad pedagógica enorme, mucho más que una amenaza. Es el momento ideal para sentarse con el equipo y revisar juntos los supuestos sobre los que venimos trabajando, para preguntarse en voz alta qué damos por cierto y por qué, para mirar la propia arquitectura, los propios costos, las propias dependencias con ojos frescos. No para cambiar todo, sino para entender mejor lo que tenemos. Las mejores conversaciones técnicas que tuve en mi carrera no surgieron de implementar la última herramienta, sino de cuestionar, con honestidad y sin miedo, decisiones que ya habíamos tomado. Y los eventos disruptivos, cuando uno los usa bien, son la excusa perfecta para esas conversaciones.\nLa velocidad del campo y lo que de verdad perdura # Hay algo más que este episodio deja en claro, y es la velocidad a la que se mueve todo esto. Cuando escribo estas líneas, R1 es la novedad. Pero sería ingenuo pensar que lo seguirá siendo por mucho tiempo. Los laboratorios que se sintieron desafiados ya están trabajando en sus respuestas, y es probable que en las próximas semanas o meses aparezcan modelos que dejen a este episodio como una nota al pie. Esa es la naturaleza del campo: lo que hoy parece un terremoto, en unos meses es historia conocida.\nY justamente por eso me parece un error escribir sobre el modelo en sí. El modelo va a envejecer. Lo que no envejece tan rápido son las preguntas que dejó al descubierto. Dentro de un año, cuando R1 sea apenas un recuerdo y haya cinco modelos mejores, las preguntas sobre nuestros supuestos van a seguir siendo igual de válidas. ¿Cuánto de lo que asumimos como necesario lo es realmente? ¿Cuánto de nuestra ventaja es sólida y cuánto es comodidad? ¿Estamos eligiendo nuestras soluciones por criterio o por inercia? Esas preguntas no caducan con el próximo lanzamiento.\nMe parece una distinción importante para cualquiera que trabaje en tecnología y quiera no quedar atrapado en la rueda de las novedades. La rueda gira sin parar, y si uno corre detrás de cada anuncio, termina agotado y sin haber pensado nada en profundidad. El valor no está en saber primero qué modelo salió, sino en entender qué nos dice cada uno de estos sacudones sobre cómo construimos, decidimos y nos posicionamos. La novedad es el ruido. El aprendizaje sobre nuestros propios supuestos es la señal.\nCuando la certeza es el verdadero riesgo # Si tuviera que quedarme con una sola idea de todo esto, sería esta: en tecnología, el mayor riesgo no suele ser equivocarse, sino estar demasiado seguro. La equivocación se corrige cuando aparece la evidencia. La certeza, en cambio, nos vuelve ciegos a esa evidencia, porque cuando algo nos parece obvio dejamos de mirarlo. Y mientras dejamos de mirarlo, el mundo sigue cambiando.\nDeepSeek no es importante por ser un modelo extraordinario, aunque quizás lo sea. Es importante porque, en pocos días, le recordó a una industria entera que varias de sus verdades fijas eran en realidad supuestos que nadie se había molestado en revisar. Y ese recordatorio es valioso no por DeepSeek, sino por la incomodidad sana que produce. La incomodidad de descubrir que algo que repetíamos con seguridad era apenas una costumbre.\nMe quedo, entonces, con una pregunta que cada uno puede llevarse a su propio terreno, lejos de la IA y de los modelos de razonamiento. En tu trabajo, en tu equipo, en tu organización: ¿cuáles son las certezas que repetís sin cuestionar? ¿Qué supuesto estás tratando como ley cuando quizás sea solo una comodidad heredada? Porque tarde o temprano va a aparecer tu propio DeepSeek —un competidor, una tecnología, una forma distinta de hacer las cosas— que te va a obligar a revisarlo. Y la diferencia entre las organizaciones que se adaptan y las que se quedan no está en quién tiene más certezas, sino en quién es capaz de cuestionarlas antes de que la realidad lo obligue.\nFuentes consultadas # DeepSeek, \u0026ldquo;DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning\u0026rdquo;, repositorio del modelo publicado el 20 de enero de 2025. Reuters, \u0026ldquo;DeepSeek sparks AI stock selloff; Nvidia posts record market-value loss\u0026rdquo;, 27 de enero de 2025. Fortune, \u0026ldquo;Marc Andreessen warns DeepSeek is \u0026lsquo;AI\u0026rsquo;s Sputnik moment\u0026rsquo;\u0026rdquo;, 27 de enero de 2025. World Economic Forum, \u0026ldquo;What is open-source AI and how could DeepSeek change the industry?\u0026rdquo;, febrero de 2025. ","date":"15 de febrero de 2025","externalUrl":null,"permalink":"/blog/post-lo-que-deepseek-nos-ensena-sobre-lo-que-creiamos-saber/","section":"Blog","summary":"DeepSeek no es importante por ser un modelo más. Es importante porque, en pocos días, puso en duda varias certezas que la industria repetía como verdades fijas: que hacía falta un presupuesto enorme, que el liderazgo estaba donde siempre había estado y que la fuerza bruta era el único camino. La lección no es sobre un modelo, es sobre cuánto de lo que creemos saber es en realidad un supuesto heredado.","title":"Lo que DeepSeek nos enseña sobre lo que creíamos saber","type":"blog"},{"content":"Si tuviera que resumir el año con una sola imagen, diría que la inteligencia artificial dejó de sentirse como una novedad lejana y empezó a meterse, con fuerza, en conversaciones mucho más reales. Ya no hablamos solo de probar un chat, generar una imagen curiosa o pedirle a una herramienta que nos explique un concepto: durante este año empezamos a hablar de IA en el desarrollo de software, en los procesos de negocio, en la automatización, en la seguridad, en la regulación y hasta en la forma de pensar la arquitectura de nuestros sistemas. Y eso cambia la conversación, porque cuando una tecnología sale del terreno de la curiosidad y entra en el de la operación, ya no alcanza con entusiasmarse: también hay que empezar a hacerse cargo. Este no pretende ser un resumen perfecto de todo lo que pasó —sería imposible—, sino algo más modesto: mirar algunas señales que nos dejó 2024 y pensar qué nos están pidiendo como profesionales, como equipos y como organizaciones.\nLa IA dejó de ser solo una novedad # Este año quedó bastante claro que la inteligencia artificial ya no ocupa solamente el lugar del experimento interesante. Entró en el editor de código, en las herramientas de productividad, en los buscadores, en los sistemas de atención, en los flujos internos y en muchísimas pruebas que las empresas vienen haciendo para entender dónde puede aportar valor de verdad. En desarrollo de software, por ejemplo, ya no hablamos solo de autocompletado, sino de asistentes que explican código, generan tests, revisan errores, proponen cambios, escriben documentación, analizan logs o transforman una idea inicial en un plan de implementación.\nLas señales se acumularon a lo largo del año. GitHub presentó Copilot Workspace en technical preview, con una propuesta clara: pasar de una tarea expresada en lenguaje natural a una planificación y luego a código, manteniendo al desarrollador en control. OpenAI presentó o1-preview en septiembre, una serie de modelos orientados a razonar mejor en problemas complejos de código, ciencia y matemática. Anthropic mostró en octubre la capacidad de uso de computadora para Claude, con una IA capaz de interactuar con una interfaz usando pantalla, cursor y teclado. Y en diciembre Google presentó Gemini 2.0, pensado para esta etapa más \u0026ldquo;agentic\u0026rdquo;, con uso de herramientas y capacidades multimodales todavía experimentales.\nTodo esto marca un cambio de etapa. No significa que la IA ya resuelva todo, lejos de eso, pero sí que la pregunta empieza a mover el eje: ya no es solamente qué puede responder una IA, sino qué puede hacer una IA con acceso a herramientas, datos, interfaces y contexto. Esa segunda pregunta es muchísimo más potente y, también, mucho más delicada.\nDe responder a actuar # Hasta hace poco, para muchas personas la IA era una caja de texto: uno preguntaba y la herramienta respondía, mejor o peor. Este año tomó fuerza otra idea: sistemas capaces de planificar pasos, usar herramientas, consultar información, interactuar con interfaces y ejecutar acciones con cierto nivel de supervisión. Ahí aparece la conversación sobre agentes.\nNo me gusta pensar los agentes como una magia autónoma que va a resolver cualquier problema empresarial mientras nosotros miramos desde afuera; esa visión me parece peligrosa y demasiado cómoda. Prefiero verlos, al menos por ahora, como una evolución natural de algo que ya veníamos viendo: modelos con más capacidad de razonamiento, conectados a herramientas concretas y limitados por reglas, permisos y objetivos. Un agente no debería ser \u0026ldquo;una IA suelta haciendo cosas\u0026rdquo;, sino un sistema diseñado con intención, límites, contexto, trazabilidad y una arquitectura que lo contenga. Porque cuando una IA solo responde mal, el problema puede quedar en una mala respuesta; pero cuando ejecuta mal, el impacto puede ser mucho mayor: puede tocar datos, llamar APIs, crear tickets, generar código o tomar una decisión operativa. Y ahí la conversación deja de ser solo de productividad para volverse también de seguridad, gobierno, arquitectura y responsabilidad.\nConectar la IA con nuestros sistemas cambia todo # Una de las señales más interesantes de este cierre de año es que empieza a ordenarse mejor la idea de conectar modelos de IA con datos y herramientas externas. El anuncio del Model Context Protocol por parte de Anthropic, a fines de noviembre, apunta justamente a ese problema: cómo conectar asistentes con repositorios, herramientas de negocio, entornos de desarrollo y fuentes de datos sin tener que inventar una integración distinta para cada caso. Puede sonar a detalle técnico, pero no lo es.\nDurante mucho tiempo, el límite de muchas herramientas de IA fue el contexto. El modelo razonaba sobre lo que uno le pegaba en el chat, pero no entendía el sistema real donde uno trabaja: no conocía el repositorio completo, las reglas internas, el historial de decisiones ni los procesos de la empresa. Cuando empezamos a conectar IA con sistemas, ese límite se empieza a mover, y con él se mueven también los riesgos. Darle contexto a la IA no es solo mejorar sus respuestas; es darle acceso a información que puede ser sensible, estratégica o crítica. Y darle herramientas no es solo hacerla más útil; es darle capacidad de acción. Por eso creo que esta etapa va a necesitar mucha más madurez que la del chatbot. Antes de conectar una IA a un repositorio, una base de datos o un sistema de tickets, conviene hacerse algunas preguntas simples: qué puede leer, qué puede modificar, con qué permisos actúa, cómo auditamos sus decisiones y qué hacemos si interpreta mal una instrucción. No son detalles para más adelante; son parte del diseño.\nLa velocidad volvió a ser una tentación # Uno de los grandes atractivos de la IA es la velocidad, y es entendible: nos ayuda a escribir, investigar, resumir, prototipar y destrabar problemas mucho más rápido que antes. Pero este año también dejó una advertencia clara: más velocidad no siempre significa mejor software, mejores procesos o mejores decisiones. En desarrollo se ve enseguida. Una IA genera código en segundos, y eso no garantiza que respete la arquitectura, entienda el negocio, contemple seguridad, use bien los datos o sea fácil de mantener; puede sonar correcto, compilar y pasar algunos tests, y aun así estar mal pensado.\nFuera del código pasa lo mismo. La IA puede generar un documento, una respuesta a cliente, una propuesta comercial o un análisis, pero sin criterio humano que revise, contextualice y valide, terminamos decidiendo sobre una base que parece sólida y no lo es. La velocidad es excelente cuando acelera un proceso bien entendido, y peligrosa cuando acelera la confusión. Este punto me parece central para lo que viene: la IA no elimina la necesidad de pensar; en algunos casos, incluso nos exige pensar mejor.\nLa calidad del contexto empieza a valer más # Si algo nos deja claro este año es que el contexto importa muchísimo. Un modelo puede ser muy potente, pero si trabaja con información incompleta, instrucciones vagas o datos poco confiables, el resultado queda igual de limitado. No es tan distinto de lo que ya pasaba con las personas: un desarrollador con un ticket pobre puede interpretar mal, un equipo con requerimientos ambiguos puede construir algo que no era, un área con datos inconsistentes puede tomar malas decisiones. La diferencia es que la IA completa los huecos con mucha seguridad aparente, y eso confunde.\nPor eso empiezan a ganar valor cosas que antes parecían menos atractivas: documentación clara, criterios de aceptación, reglas de arquitectura, estándares de desarrollo, catálogos de APIs, modelos de datos entendibles, permisos bien definidos y decisiones técnicas registradas. Todo eso ya servía para los humanos, pero ahora también empieza a servir para orientar a la IA, y ahí hay un cambio cultural interesante. Durante años muchas organizaciones trataron la documentación como una carga, algo que se escribe cuando sobra tiempo —que casi nunca sobra—. Pero si vamos hacia entornos donde la IA ayuda a desarrollar, analizar u operar, la documentación deja de ser solo memoria humana para convertirse en contexto operativo. Y el contexto operativo puede marcar la diferencia entre una IA útil y una IA peligrosa.\nLa regulación dejó de ser una conversación lejana # Este año también trajo una señal fuerte desde Europa: la AI Act entró en vigor el 1 de agosto. Más allá de los detalles legales, el mensaje de fondo es bastante claro: la inteligencia artificial ya es lo suficientemente importante como para necesitar reglas, responsabilidades y marcos de uso. Esto no significa frenar la innovación; al contrario, puede ayudar a que sea más seria, porque cuando una tecnología empieza a afectar decisiones, clientes, datos personales, empleo o servicios críticos, no puede quedar librada únicamente al entusiasmo del momento.\nLas empresas van a tener que aprender a preguntarse no solo si pueden usar IA, sino también si deben usarla de cierta manera, y eso implica revisar bajo qué condiciones, con qué datos, con qué controles, con qué explicabilidad, con qué trazabilidad y con qué supervisión humana. Puede sonar burocrático, pero es parte de la madurez. Una organización madura no adopta tecnología porque está de moda; la adopta porque entiende el problema, el impacto, los riesgos y la responsabilidad que asume.\nSeguridad: la otra cara de la innovación # Cuando hablamos de IA solemos enfocarnos en productividad, automatización y nuevas capacidades, pero cada capacidad nueva también puede abrir una superficie de riesgo nueva. Si una IA puede leer documentos internos, hay que pensar en privacidad; si puede consultar bases de datos, en permisos; si puede generar código, en vulnerabilidades; si puede interactuar con sistemas, en auditoría; si puede tomar acciones, en límites. Y si puede conectarse a múltiples herramientas, hay que pensar qué pasa cuando una instrucción maliciosa, ambigua o simplemente equivocada atraviesa todo ese flujo.\nLa seguridad no puede quedar para después. Esto ya era cierto antes de la IA, pero con IA se vuelve aún más importante, porque muchos de estos sistemas trabajan con lenguaje natural, contexto dinámico y decisiones probabilísticas: no todo está escrito en código tradicional, no todo es determinístico, no todo se prueba con los mecanismos de siempre. Por eso, cuando una organización empieza a usar IA en serio, también debería revisar cómo gobierna accesos, datos, logs, permisos, entornos, secretos y aprobaciones. La IA es una herramienta poderosa, pero una herramienta poderosa conectada sin control puede convertirse en un problema poderoso.\nCrowdStrike nos recordó que la resiliencia sigue siendo central # Aunque este cierre de año esté muy marcado por la inteligencia artificial, sería un error mirar 2024 solo desde ahí. El incidente de CrowdStrike de julio fue una de esas situaciones que obligan a mirar la tecnología desde otro lugar: una actualización defectuosa terminó afectando millones de dispositivos Windows y generando impacto en aerolíneas, bancos, hospitales, medios y organizaciones de distintos sectores. Ese caso nos recordó algo que solemos olvidar cuando hablamos de innovación: los sistemas modernos son profundamente dependientes.\nDependemos de proveedores, de actualizaciones, de agentes instalados en los endpoints, de nubes, de integraciones, de librerías y de APIs; en buena medida, dependemos de sistemas que no controlamos del todo. Y cuando una pieza crítica falla, el impacto puede ser enorme. Por eso la resiliencia tecnológica no debería verse como un tema separado de la innovación, sino como parte de la innovación responsable. No alcanza con construir sistemas más inteligentes si también los hacemos más frágiles, ni con automatizar más si no sabemos cómo detener, aislar o recuperar lo automatizado, ni con conectar más herramientas si no entendemos qué pasa cuando una de ellas falla. La transformación digital sin resiliencia puede terminar construyendo organizaciones modernas pero vulnerables.\nLa deuda técnica no desaparece con IA # Otra tentación de este año fue pensar que la IA podía resolver, casi mágicamente, problemas acumulados durante años: código viejo, sistemas heredados, documentación incompleta, integraciones difíciles, procesos manuales, datos duplicados y arquitecturas que crecieron por necesidad más que por diseño. Y sí, la IA puede ayudar muchísimo: explica código heredado, genera documentación inicial, detecta patrones repetidos, propone refactors, ayuda a escribir pruebas y acelera migraciones. Pero no elimina la deuda técnica por decreto.\nLa deuda técnica no es solo código viejo. Es conocimiento perdido, decisión no documentada, dependencia invisible, miedo a tocar una parte del sistema, falta de tests, una arquitectura que ya no representa bien el negocio, una solución rápida que se volvió permanente. La IA puede ayudarnos a enfrentar esa deuda, pero también puede crear deuda nueva si la usamos sin criterio: generando más código del necesario, duplicando lógica, introduciendo dependencias, ocultando decisiones importantes detrás de respuestas convincentes o acelerando una mala dirección. Por eso una de las preguntas más importantes no es si usamos IA para escribir más código, sino si la usamos para construir mejor software. Y eso es bastante distinto.\nEl liderazgo técnico importa más, no menos # A medida que las herramientas se vuelven más potentes, puede aparecer la idea de que el liderazgo técnico pierde importancia. Yo creo exactamente lo contrario. Cuando una tecnología acelera tanto, alguien tiene que ayudar a decidir hacia dónde acelerar: cuidar la arquitectura, ordenar prioridades, hacer las preguntas incómodas, poner límites, mirar seguridad, datos, operación, costos y mantenimiento, y separar una prueba interesante de una solución lista para producción. Alguien tiene que poder decir \u0026ldquo;esto está bueno, pero todavía no\u0026rdquo;, o \u0026ldquo;esto parece simple y puede romper algo importante\u0026rdquo;.\nLa IA ayuda a los equipos a trabajar mejor, pero no reemplaza la necesidad de criterio, experiencia y responsabilidad. En todo caso, cambia el tipo de liderazgo que necesitamos: menos basado en controlar cada línea de código y más en crear contexto, reglas, claridad, estándares, espacios de aprendizaje y mecanismos de revisión. Un equipo que usa IA sin acuerdos puede terminar trabajando más rápido y más desordenado; uno que la usa con método puede ganar una ventaja real.\nNo todo tiene que convertirse en IA # También me parece importante decir algo simple: no todo problema necesita inteligencia artificial. A veces necesitamos mejores procesos, mejores datos, una arquitectura más simple, eliminar pasos innecesarios, automatizar algo básico, hablar mejor entre áreas o, directamente, borrar código en lugar de generar más. La IA puede ser espectacular, pero no debería convertirse en una excusa para no mirar el problema real. Si un proceso es confuso, la IA lo hará más rápido y seguirá siendo confuso; si los datos son malos, producirá una respuesta elegante basada en datos malos; si la arquitectura es frágil, agregará funcionalidades sobre esa fragilidad; si el equipo no tiene prioridades claras, acelerará tareas que tal vez no eran las más importantes. La tecnología no reemplaza la dirección. Y la IA tampoco.\nLo que me deja el año # Si tuviera que resumir lo que me deja 2024, no diría solamente que la IA avanzó mucho —eso es evidente—, sino que nos obligó a madurar la conversación. La IA generativa dejó de ser una herramienta curiosa, los asistentes de programación dejaron de ser autocompletado, los agentes pasaron de idea llamativa a posibilidad técnica concreta y la regulación empezó a marcar un marco más serio. La seguridad volvió a recordarnos que cada capacidad nueva trae riesgos nuevos, la resiliencia volvió a aparecer como una necesidad y no como un lujo, la deuda técnica demostró que no desaparece por sumar herramientas más inteligentes, y el liderazgo técnico volvió a ocupar un lugar central, no porque tenga todas las respuestas, sino porque ayuda a hacer mejores preguntas.\nMirando hacia el año que viene hay entusiasmo, pero también mucha incertidumbre. No sabemos hasta dónde van a mejorar estos modelos, qué tan rápido se van a integrar los agentes en herramientas reales, qué prácticas van a sobrevivir y cuáles van a quedar como experimentos de una etapa inicial, cómo van a responder las organizaciones cuando tengan que pasar de la prueba al uso productivo, ni cómo van a evolucionar los costos, la regulación, la privacidad y la confianza. Tampoco sabemos cuánto de todo esto será una revolución profunda y cuánto, simplemente, una nueva capa de herramientas sobre problemas viejos. Y está bien no saberlo: la incertidumbre también es parte del momento.\nLo importante, creo, es no reaccionar desde los extremos. Ni creer que la IA va a resolver todo ni negar que puede cambiar muchísimo; ni adoptarla sin pensar ni rechazarla por miedo. El desafío está en encontrar una forma madura de incorporarla: con curiosidad pero con criterio, con velocidad pero con revisión, con automatización pero con control, con ambición pero con responsabilidad. Si una organización quiere entrar mejor preparada en esta etapa, yo empezaría por cosas bastante concretas: identificar dónde la IA aporta valor real y dónde sería solo una moda; ordenar datos, documentación y contexto antes de esperar resultados mágicos; definir reglas claras para su uso en desarrollo, soporte, operaciones y negocio; revisar seguridad, privacidad y permisos desde el inicio; evitar conectarla a sistemas críticos sin trazabilidad ni límites; usarla para mejorar calidad y no solo para generar volumen; medir impacto real y no sensación de productividad; formar a los equipos; revisar la arquitectura antes de sumar automatizaciones complejas; y hacer postmortems, aprender y ajustar de forma continua.\nNo hace falta hacer todo de golpe; de hecho, intentarlo todo al mismo tiempo suele ser mala idea. Pero sí hace falta empezar con una mirada más madura, porque la IA aplicada no es solamente una cuestión de herramientas, sino de sistema. Y cuando digo sistema no hablo solo de software, sino de personas, procesos, datos, arquitectura, cultura, seguridad, liderazgo y capacidad de aprendizaje. Tal vez lo más importante de este año no sea que aparecieron modelos más potentes o herramientas más integradas, sino que empezamos a entender mejor el tamaño de la responsabilidad. La IA puede ayudarnos a escribir, programar, analizar, automatizar y planificar; puede acelerar equipos, abrir oportunidades y ayudarnos a pensar mejor; pero también puede amplificar errores, exponer datos, crear dependencias nuevas y generar una falsa sensación de control. La enseñanza que me llevo es bastante clara: no alcanza con usar IA, hay que aprender a usarla bien. Y usarla bien no es solo escribir mejores prompts, sino construir contexto, cuidar la arquitectura, revisar resultados, proteger datos, medir impacto, formar equipos, diseñar procesos y mantener vivo el criterio técnico. La IA dejó de ser novedad; ahora empieza a pedir madurez. Quizá ese sea el verdadero desafío que se abre hacia adelante: no correr detrás de cada anuncio ni enamorarnos de cada herramienta, sino aprender a incorporar esta tecnología de una forma que de verdad mejore cómo trabajamos, cómo decidimos y cómo construimos. Porque la tecnología, por sí sola, nunca fue suficiente. Y con la inteligencia artificial pasa exactamente lo mismo.\nFuentes consultadas # Stack Overflow, \u0026ldquo;2024 Developer Survey — AI\u0026rdquo;, resultados publicados en 2024 sobre uso de herramientas de IA por desarrolladores. GitHub, \u0026ldquo;Welcome to the Copilot-native developer environment\u0026rdquo;, 29 de abril de 2024. Microsoft, \u0026ldquo;Helping our customers through the CrowdStrike outage\u0026rdquo;, 20 de julio de 2024. Comisión Europea, \u0026ldquo;AI Act enters into force\u0026rdquo;, 1 de agosto de 2024. OpenAI, \u0026ldquo;Introducing OpenAI o1-preview\u0026rdquo;, 12 de septiembre de 2024. Google Cloud, \u0026ldquo;Announcing the 2024 DORA Report\u0026rdquo;, 23 de octubre de 2024. Anthropic, \u0026ldquo;Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku\u0026rdquo;, 22 de octubre de 2024. Anthropic, \u0026ldquo;Introducing the Model Context Protocol\u0026rdquo;, 25 de noviembre de 2024. Google, \u0026ldquo;Introducing Gemini 2.0: our new AI model for the agentic era\u0026rdquo;, 11 de diciembre de 2024. ","date":"20 de diciembre de 2024","externalUrl":null,"permalink":"/blog/post-2024-ia-dejo-de-ser-novedad-y-empezo-a-pedir-madurez/","section":"Blog","summary":"2024 no fue solamente otro año de novedades en inteligencia artificial. Fue el año en que empezamos a ver con más claridad que la IA aplicada necesita madurez: buenos datos, contexto, seguridad, resiliencia, arquitectura y liderazgo técnico.","title":"2024: el año en que la IA dejó de ser novedad y empezó a pedir madurez","type":"blog"},{"content":"","date":"20 de diciembre de 2024","externalUrl":null,"permalink":"/tags/transformacion-digital/","section":"Tags","summary":"","title":"Transformacion-Digital","type":"tags"},{"content":"Durante mucho tiempo hablamos con la inteligencia artificial como si fuera una caja de texto inteligente: le escribíamos algo, nos respondía, copiábamos una parte, corregíamos otra, volvíamos a preguntar y seguíamos trabajando nosotros. Eso ya era potente, y de hecho lo sigue siendo. Pero en este último tiempo empieza a aparecer una pregunta más incómoda y bastante más interesante: ¿qué pasa cuando la IA no solo responde, sino que también puede hacer cosas? No hablo de magia ni de robots reemplazando personas de un día para el otro, sino de algo más concreto: modelos capaces de usar herramientas, leer pantallas, navegar, escribir código, planificar pasos y conectarse con sistemas reales. Y cuando una tecnología pasa de responder a actuar, la conversación cambia de naturaleza. Porque una respuesta equivocada puede ser molesta, pero una acción equivocada puede tener impacto.\nDe la conversación a la acción # Hasta hace poco, gran parte de la experiencia con IA generativa pasaba por una interfaz muy simple: una caja de texto. Uno escribía una pregunta y recibía una respuesta. Eso abrió un montón de posibilidades —explicaciones, ejemplos, ideas, resúmenes, código, correcciones— pero mantenía una frontera bastante clara: la IA sugería y nosotros ejecutábamos. La IA escribía una función y nosotros la revisábamos, la pegábamos, la probábamos y, si tenía sentido, la llevábamos a producción. La IA explicaba un comando y nosotros decidíamos si correrlo. Ese límite la mantenía en un lugar de asistencia: muy potente, sí, pero todavía contenido.\nAhora empieza a aparecer otra etapa, una en la que la IA puede interactuar con herramientas, entornos de desarrollo, navegadores, APIs, archivos, terminales e incluso interfaces gráficas. Eso ya no es solamente conversar; se acerca bastante a delegar una parte del trabajo.\n¿Qué estamos llamando agentes? # La palabra \u0026ldquo;agente\u0026rdquo; se escucha cada vez más, así que conviene bajarla a tierra. Un agente de IA no debería imaginarse como una entidad mágica que entiende todo, decide todo y resuelve todo sola, al menos no en la realidad práctica de hoy. Una forma simple de pensarlo es esta: un agente es una IA que no solo genera una respuesta, sino que puede seguir un objetivo, dividirlo en pasos, usar herramientas y ejecutar acciones para intentar completarlo.\nLa diferencia parece pequeña, pero no lo es. Un chatbot responde; un agente intenta avanzar. Un chatbot te explica cómo revisar una web; un agente podría abrirla, leer la información, completar una planilla y devolverte un resultado. Un chatbot te sugiere cómo resolver un bug; un agente podría revisar el repositorio, proponer cambios, editar archivos, correr tests y dejarte una rama lista para mirar. El cambio no está solo en la inteligencia del modelo, sino en su conexión con el entorno. Y cuando conectamos IA con herramientas reales, aparecen oportunidades enormes y también riesgos mucho más concretos.\nLo que está pasando en 2024 # Durante este año vimos varias señales de que la industria se mueve desde la IA conversacional hacia experiencias más orientadas a tareas. GitHub presentó Copilot Workspace en abril, proponiendo un flujo donde una tarea arranca en lenguaje natural y avanza hacia un plan, cambios de código, pruebas y una posible implementación dentro del propio entorno. Cognition mostró Devin como una propuesta de \u0026ldquo;ingeniero de software de IA\u0026rdquo;, con capacidad de planificar y ejecutar tareas de desarrollo usando editor, navegador y terminal. OpenAI presentó o1-preview en septiembre, una serie de modelos pensados para razonar más tiempo antes de responder en problemas complejos. Y en octubre, Anthropic mostró una capacidad experimental muy interesante en Claude: el uso de computadora, es decir, la posibilidad de que el modelo mire una pantalla, mueva el cursor, haga clic y opere una interfaz de manera más parecida a como lo haría una persona.\nNada de esto está maduro ni listo para usarse sin cuidado, y menos para llevarlo directo a procesos críticos. Pero marca una dirección clara: la IA empieza a salir del chat y a acercarse al escritorio, al navegador, al editor, al repositorio, a la terminal y a las APIs que usamos todos los días. Y cuando eso pasa, la pregunta deja de ser solamente qué tan buena es la respuesta para incluir otra igual de importante: qué tan segura, controlada y reversible es la acción.\nLa diferencia entre ayudar y actuar # Hay una distancia enorme entre que una IA nos diga qué hacer y que lo haga. Si le preguntamos cómo borrar archivos temporales y responde mal, podemos revisar antes de ejecutar; pero si le damos permiso para operar sobre un entorno y corre el comando equivocado, el problema deja de ser teórico. Si le pedimos que redacte un correo, lo leemos antes de enviarlo; si le damos acceso para enviarlo directamente, necesitamos otros controles. Si propone un cambio en una base de datos, lo discutimos; si le damos acceso para correr scripts, la validación previa deja de ser opcional.\nPor eso, cuando hablamos de agentes, no alcanza con hablar de inteligencia. Hay que hablar de permisos, de límites, de trazabilidad, de entornos seguros, de revisión humana, de reversibilidad, de arquitectura y de responsabilidad. La IA puede ayudarnos mucho más cuando puede actuar, pero también puede equivocarse con mucho más impacto.\nEl entusiasmo es razonable # No quiero escribir esto desde el miedo, porque sería un error mirar esta evolución solo como una amenaza. Un agente bien diseñado puede cambiar bastante la forma en que trabajamos. En desarrollo de software podría revisar un issue, buscar archivos relacionados, proponer un plan, generar una primera versión de código, correr tests, preparar documentación, resumir un pull request o revisar logs. En operaciones podría consultar métricas, revisar alertas, cruzar información entre sistemas, preparar reportes de incidentes o sugerir acciones de recuperación. En áreas de negocio podría consultar datos, preparar análisis, completar tareas administrativas o conectar herramientas que hoy viven separadas.\nBien usado, todo eso reduce fricción, y reducir fricción es una de las mejores maneras de generar valor real con tecnología. No porque la IA haga todo sola, sino porque puede encargarse de partes repetitivas, mecánicas o exploratorias y dejarnos más tiempo humano para decidir, revisar, priorizar y pensar.\nPero el agente no entiende tu empresa por defecto # Este punto me parece central. Un agente puede ser capaz de usar herramientas sin que eso signifique que entiende el contexto de una organización. No sabe qué cliente es crítico, qué proceso tiene excepciones históricas, qué tabla no debería tocarse sin avisar a datos, qué integración falla fuera de horario, qué parte del sistema está en migración o qué deuda técnica el equipo decidió tolerar a propósito. Puede saberlo si se lo damos, puede respetarlo si lo definimos y puede operar mejor si lo guiamos, pero no lo adivina por arte de magia.\nY esto conecta con algo que ya veníamos viendo en programación asistida: cuanto más grande es el sistema, más importante se vuelve el contexto. Un agente sin contexto puede actuar rápido, pero actuar rápido no siempre es actuar bien.\nLa ilusión del piloto automático # Cada vez que aparece una tecnología que automatiza algo, aparece también la tentación de dejarla trabajar sola. Es lógico: si una herramienta resuelve tareas, queremos sacarnos trabajo de encima. Pero en sistemas reales, el piloto automático absoluto suele ser peligroso, no porque la IA sea inútil, sino porque el mundo donde opera es ambiguo, cambiante, lleno de excepciones y muchas veces mal documentado.\nUn agente puede interpretar mal una instrucción, elegir la herramienta equivocada, completar un formulario con datos incorrectos, tomar una decisión razonable en apariencia pero mala para el negocio, ejecutar pasos en un orden que no corresponde o insistir cuando debería detenerse y preguntar. Incluso puede lograr el objetivo rompiendo una regla que no estaba escrita en ningún lado. Y ahí está uno de los grandes desafíos: muchas reglas importantes de una organización viven en conversaciones, experiencia, memoria del equipo, incidentes pasados y conocimiento tribal. Si queremos que una IA actúe dentro de nuestros sistemas, tenemos que empezar a convertir parte de ese conocimiento en instrucciones, reglas y límites claros.\nLos agentes necesitan barandas # Me gusta pensar que los agentes necesitan barandas. No para impedirles trabajar, sino para evitar que se salgan del camino. Una baranda puede ser una regla de arquitectura, un permiso limitado, un entorno sandbox, una lista de acciones prohibidas, una revisión humana obligatoria antes de algo irreversible, un conjunto de tests, un registro de auditoría o un criterio de escalamiento para cuando el agente no está seguro. Cuando un agente solo responde texto, esas barandas son importantes; cuando puede actuar, se vuelven indispensables.\nUn agente que consulta información necesita permisos; uno que la modifica necesita controles; uno que despliega código necesita revisión; uno que opera sobre clientes necesita trazabilidad; uno que ejecuta comandos necesita límites muy claros. Por eso la pregunta no debería ser solamente qué puede hacer este agente, sino también qué no debería poder hacer nunca.\nLa seguridad cambia de lugar # Cuando conectamos IA con herramientas, la seguridad deja de ser un tema externo al modelo. Ya no se trata solo de si responde algo incorrecto, sino de qué accesos tiene, qué datos ve, qué acciones puede ejecutar y cómo se controla su comportamiento. Empiezan a ser inevitables preguntas como si el agente puede acceder a datos sensibles, enviar información a terceros, ejecutar comandos, modificar archivos, tocar producción, crear usuarios o borrar datos; si queda registro de lo que hizo, si podemos reconstruir por qué tomó una decisión y —tal vez la más interesante— si alguien podría engañarlo desde una página web, un documento o un texto malicioso.\nEse último punto es especialmente delicado. Si un agente navega, lee documentos o interpreta instrucciones externas, también puede quedar expuesto a instrucciones escondidas dentro del contenido que consume. Dicho de otro modo: cuando la IA empieza a usar herramientas, aparece una nueva superficie de ataque. No alcanza con decir \u0026ldquo;el modelo es bueno\u0026rdquo;; hay que diseñar el sistema completo pensando en seguridad.\nAutomatizar no es delegar responsabilidad # Este punto vale la pena repetirlo: automatizar una tarea no significa delegar la responsabilidad. Si un agente ejecuta una acción dentro de una empresa, alguien diseñó ese flujo, alguien le dio permisos, alguien definió los límites y alguien decidió ponerlo a trabajar. La responsabilidad sigue siendo humana y organizacional. Esto vale para la IA, pero también para cualquier automatización: un script mal hecho puede borrar datos, un job mal configurado puede saturar un servicio, un pipeline mal armado puede desplegar algo roto. La diferencia con la IA es que aparece una capa adicional de interpretación, y donde hay interpretación, hay ambigüedad. Por eso los agentes tienen que diseñarse como parte de una arquitectura, no como juguetes sueltos conectados a sistemas importantes.\nEl problema no es que la IA actúe, sino dónde y cómo # No todos los usos tienen el mismo riesgo. Un agente que ordena archivos en una carpeta de pruebas no es lo mismo que uno que modifica datos de clientes; uno que resume logs no es lo mismo que uno que reinicia servicios; uno que propone código no es lo mismo que uno que hace merge automático a main. Me resulta útil pensarlo en niveles de autonomía crecientes, desde la pura asistencia —donde la IA responde, explica o propone y el humano ejecuta— hacia la preparación, donde la IA arma cambios, borradores o planes y el humano revisa y aprueba.\nUn paso más allá está la ejecución controlada: la IA actúa en entornos limitados, con permisos acotados, registro y posibilidad de revertir, mientras el humano supervisa. Después aparece una autonomía parcial, donde la IA completa tareas repetitivas dentro de reglas muy claras y el humano audita y ajusta límites. Y en el extremo está la autonomía crítica, con la IA operando sobre procesos importantes con poco o ningún control humano inmediato. Para muchos sistemas empresariales actuales, ese último escalón conviene tratarlo con muchísimo cuidado; no porque sea imposible para siempre, sino porque todavía estamos aprendiendo cómo hacerlo bien.\nLos agentes en desarrollo de software # En software esta evolución se siente con fuerza. Primero tuvimos autocompletado, después asistentes que explicaban código, luego generación de funciones, tests y documentación; ahora empezamos a ver herramientas que intentan tomar una tarea más completa: entender un issue, armar un plan, tocar archivos, ejecutar pruebas y acercarse a una solución. Puede ser muy valioso, pero también amplifica los mismos problemas que ya vimos al programar con IA. Si el agente no entiende la arquitectura, ubica código donde no corresponde; si no conoce las convenciones, inventa patrones nuevos; si le falta contexto, duplica lógica; si los tests son pobres, cree que todo está bien; si el repositorio es caótico, copia el caos; si las instrucciones son vagas, completa los huecos con supuestos. La diferencia es que ahora no solo genera una respuesta: puede avanzar varios pasos en una dirección equivocada.\nPor eso, para desarrollo, los agentes necesitan algo más que acceso al repositorio. Necesitan reglas, documentación, criterios de aceptación, límites de arquitectura, pruebas reales, revisión humana y, sobre todo, que el equipo tenga claro qué está intentando construir.\nLa documentación vuelve a ser importante # Hay algo casi irónico en todo esto. Durante años muchos equipos trataron la documentación como una molestia: algo que se escribe cuando sobra tiempo, que se desactualiza y que nadie lee. Pero cuanto más queremos que la IA nos ayude, más importante se vuelve tener contexto escrito, porque un agente no puede adivinar la intención del negocio, ni reconstruir la historia de una arquitectura que nadie documentó, ni respetar reglas que nunca fueron explicitadas, ni distinguir una excepción válida de una mala práctica heredada si todo está mezclado.\nAsí, paradójicamente, la IA vuelve a poner valor sobre prácticas que nunca debieron perderlo: buenas especificaciones, criterios de aceptación, documentación de arquitectura, decisiones técnicas registradas, guías de desarrollo, runbooks, postmortems, contratos de APIs y tests que expresen comportamiento real. No como burocracia, sino como contexto operativo, memoria del sistema y barandas que sirven para humanos y también para máquinas.\nNo todo tiene que ser agente # Conviene decir algo que parece obvio pero que se pierde con el entusiasmo: no todo problema necesita un agente. A veces alcanza con un script, con una automatización simple, con una integración bien hecha, con mejorar un proceso, con documentar o con eliminar un paso innecesario. La IA es muy poderosa, pero no debería ser la excusa para complicar soluciones simples. Si una tarea es determinística, repetitiva y con reglas claras, tal vez un proceso clásico sea mejor que un agente interpretando instrucciones; si una acción es crítica y sensible, tal vez convenga mantener aprobación humana; si un flujo necesita trazabilidad fuerte, tal vez haya que diseñarlo como sistema antes de conectarlo a un modelo. La pregunta no es dónde podemos meter IA, sino qué problema real queremos resolver y qué nivel de autonomía tiene sentido permitir.\nEmpezar por lo interno, no por lo crítico # Si una organización quiere experimentar con agentes, yo lo haría primero en lugares de bajo riesgo: asistentes internos para documentación, análisis de logs sin capacidad de modificar nada, generación de borradores y reportes, clasificación de tickets, revisión de pull requests sin merge automático, búsqueda en bases de conocimiento o automatizaciones en sandbox. Ese tipo de casos permite aprender sin poner en juego procesos críticos desde el primer día; después, con experiencia, métricas, errores conocidos y mejores controles, se puede avanzar. Empezar conectando un agente a producción, datos sensibles o acciones irreversibles solo porque la demo se ve impresionante me parece una mala idea. La madurez no está en automatizar todo rápido, sino en saber dónde conviene automatizar, con qué límites y bajo qué responsabilidad.\nEl rol del liderazgo técnico # Los agentes de IA no son solo una decisión de herramienta; son también una decisión de liderazgo técnico, porque alguien tiene que definir qué se permite, qué no, dónde se prueba, cómo se mide, cómo se audita y cómo se protege la organización. Un equipo puede entusiasmarse con una herramienta nueva y empezar a usarla de forma desordenada —eso ya pasa con muchas tecnologías— pero cuando la herramienta puede actuar, el desorden pesa más. El liderazgo técnico ayuda a convertir el entusiasmo en método, no para frenar la innovación sino para hacerla sostenible.\nHay conversaciones que empiezan a ser necesarias: qué tareas queremos delegar parcialmente, qué permisos y qué datos puede tener un agente, qué acciones requieren aprobación humana, qué entornos son seguros para experimentar, cómo registramos lo que hizo, cómo evaluamos si realmente mejora el trabajo, qué hacemos cuando se equivoca y quién es responsable del resultado. Si esas preguntas no aparecen, la herramienta puede avanzar más rápido que la organización, y cuando eso ocurre rara vez termina bien.\nLa productividad también necesita medición # Otro punto importante: no todo lo que parece más rápido es realmente más productivo. Un agente puede completar una tarea en minutos, pero si después el equipo necesita horas para revisar, corregir y limpiar lo que hizo, tal vez no hubo mejora real. La productividad no debería medirse solo por cantidad de acciones ejecutadas; también importan la calidad del resultado, el tiempo de revisión, los errores, el impacto en deuda técnica, la facilidad de mantenimiento, la seguridad y la confianza del equipo. Pasa lo mismo que con el código: más código no siempre es mejor software, y más acciones no significan mejor automatización. La buena automatización reduce ruido; la mala genera trabajo invisible.\nHumanos en el circuito # Durante mucho tiempo vamos a necesitar humanos en el circuito, y no como una frase para quedarnos tranquilos, sino como diseño real del sistema: humanos para aprobar cambios importantes, para revisar decisiones ambiguas, para interpretar contexto de negocio, para definir prioridades, para detectar que algo \u0026ldquo;técnicamente correcto\u0026rdquo; no tiene sentido en la práctica y para asumir responsabilidad. La IA puede ayudarnos a hacer más cosas, pero eso no significa apagar el criterio. De hecho, cuanto más capaz se vuelve la herramienta, más importante se vuelve el criterio de quien la usa.\nSi tuviera que pensar una forma razonable de empezar con agentes, la haría gradual: identificar tareas repetitivas, frecuentes y de bajo riesgo; separar claramente asistencia, preparación y ejecución; empezar en entornos internos o sandbox; definir permisos mínimos; registrar todas las acciones; exigir aprobación humana para lo sensible; crear documentación y reglas que el agente pueda seguir; medir resultados reales y no demos lindas; revisar errores y ajustar límites; y escalar solo cuando haya confianza suficiente. No se trata de tenerle miedo a la IA, sino de no confundir capacidad con madurez. Un agente puede ser capaz de hacer muchas cosas; una organización madura decide cuáles de esas cosas conviene permitir.\nEstamos entrando en una etapa muy interesante. La IA ya no es solamente una herramienta para escribir mejor, resumir más rápido o generar código: empieza a convertirse en una capa que puede operar sobre otras herramientas, y eso cambia la discusión, porque cuando se conecta con los sistemas deja de ser una ayuda individual y pasa a formar parte de la arquitectura de trabajo. Puede mejorar procesos, reducir tareas repetitivas, ayudar a equipos chicos a hacer más, ordenar información dispersa y acelerar análisis; pero también puede actuar con poco contexto, ejecutar mal, tocar datos que no debería, amplificar errores y generar una falsa sensación de autonomía segura.\nPor eso la pregunta de fondo no es si los agentes van a llegar —ya están empezando a llegar— sino cómo vamos a integrarlos sin perder control, seguridad, criterio y responsabilidad. Una cosa es tener una IA que responde; otra muy distinta es tener una IA que hace. Y cuando una herramienta empieza a hacer cosas dentro de nuestros sistemas, ya no alcanza con mirar la demo: hay que mirar la arquitectura, los permisos, los límites, la trazabilidad, los datos, la seguridad, el proceso y, sobre todo, la responsabilidad humana detrás de cada automatización. La IA puede dejar de ser una caja de texto y convertirse en una compañera de trabajo mucho más activa; pero si va a operar sobre nuestros sistemas, tenemos que dejar de pensarla como una herramienta simpática y empezar a diseñarla como parte real de nuestra tecnología. Porque cuando la IA deja de responder y empieza a hacer cosas, también nosotros tenemos que empezar a hacernos mejores preguntas.\nFuentes consultadas # GitHub, \u0026ldquo;GitHub Copilot Workspace: Welcome to the Copilot-native developer environment\u0026rdquo;, 29 de abril de 2024. Cognition, \u0026ldquo;Introducing Devin, the first AI software engineer\u0026rdquo;, 12 de marzo de 2024. OpenAI, \u0026ldquo;Introducing OpenAI o1-preview\u0026rdquo;, 12 de septiembre de 2024. Anthropic, \u0026ldquo;Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku\u0026rdquo;, 22 de octubre de 2024. Anthropic, \u0026ldquo;Developing a computer use model\u0026rdquo;, 22 de octubre de 2024. ","date":"20 de noviembre de 2024","externalUrl":null,"permalink":"/blog/post-cuando-la-ia-deja-de-responder-y-empieza-a-hacer-cosas/","section":"Blog","summary":"La inteligencia artificial empieza a dejar de ser solamente una caja de texto para convertirse en una herramienta capaz de planificar, usar software, navegar, escribir código y ejecutar tareas. El desafío no es solo técnico: también es de arquitectura, seguridad, criterio y responsabilidad.","title":"Cuando la IA deja de responder y empieza a hacer cosas","type":"blog"},{"content":"Hay una sensación que seguramente más de un desarrollador viene experimentando en estos meses: la inteligencia artificial nos da una velocidad que entusiasma y, al mismo tiempo, una velocidad que puede confundir. Le pedimos que genere una función, que explique un error, que arme un test, que escriba una query o que nos ayude a pensar una arquitectura, y muchas veces responde rápido. Muy rápido. El problema es que en software, como en tantas otras cosas, ir más rápido no siempre significa llegar mejor. Podemos escribir más código en menos tiempo, resolver dudas sin abrir veinte pestañas y destrabar tareas que antes llevaban horas; pero si usamos la IA sin contexto, sin revisión, sin arquitectura y sin criterio, también podemos acelerar errores, deuda técnica y decisiones que alguien va a terminar pagando en producción. Sobre eso quiero detenerme acá: no mirar la IA como enemiga ni como magia, sino como una herramienta poderosa que necesita límites, método y responsabilidad.\nLa IA ya entró en el día a día del desarrollo # En lo que va del año quedó bastante claro que la inteligencia artificial dejó de ser una curiosidad para meterse en el trabajo real de muchos desarrolladores. Ya no se trata solo de preguntarle algo a un chat para que explique un concepto: hablamos de asistentes dentro del editor, autocompletado avanzado, generación de código, revisión de errores, documentación, tests, refactors, análisis de logs, ayuda con comandos y consultas SQL, entre tantas tareas que forman parte de la rutina.\nLa encuesta de Stack Overflow publicada en julio puso un número sobre esa sensación: el 76% de los encuestados decía que ya usaba o planeaba usar herramientas de IA en su proceso de desarrollo durante este año. No es un dato menor. Marca que la IA dejó de estar en la periferia de la conversación técnica para entrar al flujo normal de trabajo. Y desde los grandes jugadores también llegaron señales fuertes: GitHub presentó Copilot Workspace en technical preview, con la idea de pasar de una tarea expresada en lenguaje natural a un plan y luego a código, manteniendo al desarrollador en control del proceso; y OpenAI presentó o1-preview hace pocos días, una serie de modelos orientados a razonar mejor en problemas complejos, incluyendo código, matemática y ciencia. Todo eso empuja una idea potente: cada vez más, parte del desarrollo puede empezar desde una conversación. Pero una conversación no es todavía una especificación, y una respuesta rápida no es necesariamente una buena solución.\nLa parte buena: cuando la IA ayuda de verdad # Sería injusto entrar al tema solamente desde el miedo, porque la IA, usada con criterio, es una herramienta excelente para desarrollar software. Sirve para destrabar a alguien que está peleando con un error poco claro, para explicar una librería, para proponer una primera versión de una función, para escribir tests o sugerir mejoras sobre un fragmento, para traducir lógica de un lenguaje a otro o para documentar eso que todos usan pero nadie escribió nunca.\nTambién funciona como una especie de compañero de pensamiento. No porque siempre tenga razón, sino porque obliga a ordenar la pregunta: muchas veces, cuando uno intenta explicarle a la IA qué necesita, termina entendiendo mejor el problema, y eso solo ya tiene valor. La ayuda se vuelve muy concreta en cosas como armar esqueletos iniciales, generar ejemplos de uso, crear tests unitarios básicos, explicar stack traces, entender código heredado, proponer refactors chicos o acelerar la investigación sobre librerías y patrones. Para un equipo técnico todo esto puede valer mucho, sobre todo cuando se combina con experiencia, revisión y contexto real del proyecto. El problema empieza cuando confundimos asistencia con delegación total.\nLa IA escribe código, pero no conoce tu producción # Una herramienta de IA puede generar código que parece correcto: nombres prolijos, patrones conocidos, explicaciones convincentes, incluso un tono seguro al responder. Pero no vive dentro de tu sistema. No conoce las decisiones históricas que llevaron a tu arquitectura actual, no sabe qué partes son frágiles, qué integración falló tres veces el mes pasado, qué servicio carga más, qué tabla no se toca sin avisarle a alguien de datos, ni qué decisión técnica responde a una restricción de negocio y no a una preferencia del equipo. Puede tener todo ese contexto si se lo damos, pero no lo trae por defecto. Y en proyectos grandes, esa diferencia es enorme.\nUn código puede compilar y estar mal ubicado. Puede pasar un test y romper una regla de arquitectura. Puede resolver el caso feliz y fallar en escenarios reales, sumar una dependencia que no deberíamos arrastrar, repetir lógica que ya existe en otra capa, saltarse convenciones del equipo o funcionar perfecto en un ejemplo chico y no escalar en el sistema real. Por eso vale la pena repetirlo: la IA puede escribir código, pero todavía no se hace cargo de producción. Producción se hace cargo sola, con usuarios, carga, datos reales, integraciones, tiempos de respuesta, incidentes y gente tratando de entender qué pasó cuando algo se cae.\nEl riesgo de programar solo a base de prompts # Todavía no está tan instalado el concepto de programar \u0026ldquo;por impulso\u0026rdquo;, dejándose llevar por una conversación con la IA hasta que algo funcione, pero en la práctica ya empieza a aparecer. Uno escribe un prompt, la IA devuelve código, uno prueba y falla, le pega el error, la IA corrige, vuelve a fallar, pedimos otra variante, y otra, hasta que en algún momento funciona. O parece funcionar.\nAhí aparece la trampa. Cuando ese proceso no está guiado por una idea clara, la solución termina armada por acumulación de parches conversacionales y no por diseño. Para un prototipo, una prueba rápida o un experimento personal puede alcanzar; en software de empresa, con arquitectura, equipos, integraciones y mantenimiento a largo plazo, esa forma de trabajar es peligrosa. El código generado puede inventar APIs o métodos que no existen, usar versiones incorrectas de librerías, ignorar patrones del proyecto, duplicar lógica en vez de reutilizar, resolver el problema en la capa equivocada, mezclar responsabilidades, omitir validaciones de seguridad o generar tests que prueban lo obvio y no lo importante. A veces el problema no es que la IA no sepa programar; es que no sabe qué estamos intentando construir realmente. Y si nosotros tampoco se lo explicamos bien, el resultado es esa mezcla rara entre velocidad, ilusión de avance y deuda técnica nueva.\nEl prompt no reemplaza al criterio técnico # Hay una idea que para mí es central: escribir buenos prompts ayuda, pero no reemplaza saber de software. Pedirle a una IA \u0026ldquo;haceme esta pantalla\u0026rdquo;, \u0026ldquo;creame esta API\u0026rdquo; o \u0026ldquo;arreglame este error\u0026rdquo; puede funcionar en casos simples, pero cuanto más grande es el sistema, más pesa el contexto. El desarrollador sigue teniendo que entender dónde vive esa funcionalidad, qué responsabilidades tiene cada capa, qué contratos existen entre servicios, qué datos son confiables, qué reglas de negocio no se pueden romper, qué impacto tiene un cambio, y cómo se prueba, se despliega, se monitorea y se revierte si algo sale mal.\nLa IA ayuda en muchas de esas cosas, pero necesita dirección, y ahí el rol del programador cambia un poco. No desaparece: se vuelve más exigente en otro sentido. Antes buena parte del trabajo estaba en escribir código línea por línea; ahora, cada vez más, está también en explicar bien, revisar bien, validar bien y decidir bien. Y para revisar bien hay que saber, para decidir bien hay que entender, para validar bien hay que tener criterio. La IA puede acelerar a un buen desarrollador, pero también puede darle demasiada confianza a alguien que todavía no entiende lo que está aceptando.\nDarle reglas a la IA, no solo pedidos sueltos # Con el tiempo, una práctica que se vuelve natural es dejar de pedirle cosas sueltas y empezar a darle reglas claras. No alcanza con \u0026ldquo;agregá esta funcionalidad\u0026rdquo;; conviene explicarle qué arquitectura debe respetar, qué patrones usa el proyecto, qué convenciones seguir, qué dependencias están permitidas, qué no debe tocar, qué estilo de tests se espera, qué reglas de seguridad son obligatorias y qué archivos tiene que revisar antes de proponer un cambio.\nEsto se parece bastante a algo que en software ya conocemos hace años: trabajar con especificaciones, contratos, documentación técnica, guías de arquitectura y criterios de aceptación. La diferencia es que ahora esos documentos no sirven solo para humanos: también empiezan a orientar a la IA. Y me parece una idea importante, porque si la IA tiende a completar huecos con supuestos, nuestra responsabilidad pasa a ser reducir esos huecos. Si queremos que no delire, no alcanza con pedirle \u0026ldquo;no delires\u0026rdquo;; hay que darle contexto, límites, ejemplos y reglas.\nRequerimientos más estructurados, menos magia # Tal vez uno de los aprendizajes más interesantes de esta etapa es que la IA nos vuelve a recordar algo que solemos olvidar: los requerimientos importan. Durante años muchos equipos intentaron moverse rápido con tickets pobres, descripciones vagas o historias de usuario demasiado livianas; eso ya generaba problemas entre humanos, y con IA esos problemas se amplifican. Lo vi en prácticamente todos los lugares donde aporté mi granito de arena. Si una persona interpreta mal un requerimiento, puede preguntar, discutir o apoyarse en la experiencia del negocio; la IA también puede preguntar, pero si no se lo pedimos, muchas veces completa el vacío por su cuenta.\nPor eso empieza a tener sentido trabajar con piezas más estructuradas. No documentos enormes ni burocráticos, sino algo claro que indique el objetivo de la funcionalidad, el problema que se quiere resolver, el alcance y lo que queda fuera, las reglas de negocio, los criterios de aceptación, el impacto en datos y APIs, las consideraciones de seguridad, las reglas de arquitectura, los casos borde y las pruebas esperadas. No es volver a procesos pesados ni a documentos eternos que nadie lee; es entender que, si vamos a pedirle a una IA que nos ayude a construir software, tenemos que darle mejores instrucciones que un simple \u0026ldquo;hacelo\u0026rdquo;. En proyectos chicos, un prompt alcanza. En proyectos grandes, necesitamos contexto versionado, reglas y acuerdos.\nLa arquitectura como baranda # Me gusta pensar la arquitectura como una baranda: no está para frenar al equipo, sino para evitar que cada uno se caiga por cualquier lado. Cuando sumamos IA al desarrollo, esa baranda se vuelve todavía más importante. Si el proyecto tiene una arquitectura clara, la IA trabaja mejor porque hay límites; si las responsabilidades están bien separadas, es más fácil pedirle cambios concretos; si hay patrones repetibles, puede imitarlos; si hay tests, puede validar; si hay documentación, entiende mejor el contexto. Pero si el proyecto ya es caótico, la IA copia ese caos muy rápido, y además lo hace con mucha prolijidad visual. Ese es un riesgo interesante: el código generado puede verse ordenado y estar conceptualmente mal integrado.\nPor eso, antes de pensar en \u0026ldquo;usar más IA\u0026rdquo;, algunos equipos harían bien en preguntarse si su arquitectura está suficientemente clara, si tienen convenciones documentadas, si los módulos tienen responsabilidades entendibles, si los tests protegen el comportamiento que de verdad importa, si saben qué partes del sistema son críticas y si tienen criterios para aceptar o rechazar código generado. La IA no elimina la necesidad de arquitectura; la vuelve más necesaria.\nMás código también puede ser más deuda técnica # Uno de los efectos secundarios de la IA es que baja el costo de generar código. Suena muy bien, y en parte lo es, pero también significa que podemos generar más código innecesario, más rápido. Y en software el costo real no siempre está en escribir la primera versión: muchas veces está en mantenerla, entenderla, probarla, modificarla, operarla y corregirla cuando falla. Un equipo puede empezar a producir más pull requests, más archivos y más soluciones alternativas, pero sin revisión, estándares y criterio, ese aumento de velocidad se transforma en más superficie de mantenimiento.\nLa deuda técnica no aparece solo por escribir mal; también aparece por escribir de más: por duplicar lógica, por resolver rápido sin entender, por aceptar código que nadie termina de comprender, por sumar dependencias innecesarias o por dejar decisiones importantes escondidas dentro de una respuesta generada. La IA puede ser una gran aliada para reducir deuda si la usamos para refactorizar con cuidado, documentar, detectar duplicaciones, escribir tests y analizar impacto. Pero también puede crear deuda nueva si la tratamos como una fábrica automática de código sin control.\nEl rol del senior cambia, pero no desaparece # A veces se plantea que la IA va a reemplazar programadores. Es probable que transforme muchos roles, no lo dudo, pero mirando el desarrollo de software real —el que vive en producción— me cuesta pensar que el criterio técnico vaya a perder importancia. Más bien lo contrario: el rol del desarrollador con experiencia se vuelve más relevante para definir buenos límites, revisar soluciones generadas, detectar errores sutiles, cuidar la arquitectura, pensar en seguridad, priorizar simplicidad, evitar sobreingeniería, enseñar al equipo a usar la IA sin depender ciegamente de ella y convertir requerimientos ambiguos en instrucciones claras.\nLa IA puede escribir una función, pero alguien tiene que saber si esa función tiene sentido. Puede proponer una arquitectura, pero alguien tiene que saber si encaja con el negocio, el equipo, los tiempos y la realidad del sistema. Puede generar tests, pero alguien tiene que distinguir si protegen algo importante o solo están ahí para decorar el coverage. En ese sentido, la IA no reduce la necesidad de experiencia: la cambia de lugar.\nUsarla bien también es una habilidad de equipo # Otra cosa que me parece importante es que el uso de IA no debería quedar solo en decisiones individuales. Si cada desarrollador usa una herramienta distinta, con criterios y prompts distintos y sin acuerdos comunes, el equipo empieza a trabajar desordenado sin darse cuenta. No digo controlar todo ni matar la experimentación, pero sí tener algunas conversaciones sanas: para qué tareas usamos IA, qué tipo de código no aceptamos sin revisión humana, qué información sensible no se puede pegar en una herramienta externa, cómo documentamos decisiones tomadas con su ayuda, qué nivel de test exigimos al código generado, qué reglas de arquitectura se respetan siempre y qué hacemos cuando la IA propone algo que no entendemos. La IA no debería ser una práctica clandestina dentro del equipo; debería incorporarse con responsabilidad, como cualquier otra herramienta potente.\nUna forma práctica de trabajar con IA en proyectos reales # Si tuviera que describir una manera razonable de usar IA en desarrollo, la pensaría más o menos así: primero entender el problema, después escribir el objetivo y el alcance, definir reglas de negocio y criterios de aceptación, darle a la IA contexto del proyecto y sus restricciones, pedirle una propuesta antes que código, revisar esa propuesta, recién entonces pedir la implementación, exigir tests, revisar manualmente el resultado y validarlo contra arquitectura, seguridad y operación.\nParece más lento que pedir directamente \u0026ldquo;haceme esto\u0026rdquo;, pero en la práctica puede ser más rápido si nos ahorra tres rondas de errores, código mal ubicado, decisiones incorrectas y refactors posteriores. La velocidad buena no es escribir más rápido; es llegar antes a una solución que se pueda mantener.\nLa IA como acelerador, no como piloto automático # Me gusta pensar la IA como un acelerador, pero un acelerador necesita dirección, freno y alguien mirando el camino. Usada bien, mejora mucho la forma de trabajar: reduce tareas repetitivas, abre caminos, explica código, genera alternativas y nos deja más tiempo para los problemas de mayor valor. Usada como piloto automático, corremos el riesgo de dejar que tome decisiones que después no vamos a saber defender. Y en software profesional cada decisión técnica, tarde o temprano, pide explicaciones: por qué se hizo así, por qué se eligió esa dependencia, por qué este servicio llama directamente a este otro, por qué ese dato se guarda duplicado, por qué este proceso no tiene retry, por qué este endpoint no valida permisos, por qué este cambio rompió producción. La IA puede ayudarnos a construir, pero seguimos siendo nosotros los responsables de lo que integramos, desplegamos y mantenemos.\nSi un equipo quiere empezar a usar IA para programar sin caer en el caos, yo arrancaría por algo bastante simple: definir reglas mínimas de uso, crear guías de arquitectura y estilo que también puedan leer las herramientas, usar archivos de contexto por proyecto, pedir propuestas antes que código, no aceptar código que nadie entiende, exigir tests útiles y no decorativos, revisar seguridad y permisos desde el inicio, medir si realmente mejora el flujo o solo genera más revisión, y documentar los aprendizajes para ajustar sobre la marcha. No se trata de frenar la IA, sino de usarla mejor, porque lo más probable es que la programación asistida no sea una moda pasajera: va a seguir evolucionando e integrándose cada vez más en editores, repositorios y pipelines.\nPor eso la pregunta no es si vamos a usar IA para programar, sino cómo vamos a hacerlo sin perder calidad, criterio y responsabilidad. Puede hacernos más rápidos, ayudarnos a aprender, acompañarnos en análisis, documentación y pruebas; pero no deberíamos confundir velocidad con excelencia. El buen software no nace de escribir código rápido, sino de entender problemas, diseñar soluciones, tomar decisiones conscientes, cuidar la arquitectura, probar bien, operar con responsabilidad y aprender de lo que pasa en producción. La IA puede ser una gran compañera en ese camino, siempre que no apaguemos el criterio justo cuando la herramienta empieza a responder más rápido. Porque, al final del día, el código puede haberlo sugerido una IA, pero la responsabilidad de ponerlo en producción sigue siendo nuestra. Y esa, me parece, es la parte que conviene seguir pensando: no cuánto código más podemos generar, sino qué tipo de criterio queremos conservar a medida que la herramienta se vuelve cada vez más capaz.\nFuentes consultadas # Stack Overflow, \u0026ldquo;2024 Developer Survey — AI\u0026rdquo;, resultados publicados en julio de 2024 sobre uso de herramientas de IA por desarrolladores. GitHub, \u0026ldquo;Welcome to the Copilot-native developer environment\u0026rdquo;, 29 de abril de 2024. OpenAI, \u0026ldquo;Introducing OpenAI o1-preview\u0026rdquo;, 12 de septiembre de 2024. ","date":"18 de septiembre de 2024","externalUrl":null,"permalink":"/blog/post-programar-con-ia-mas-velocidad-no-siempre-mejor-software/","section":"Blog","summary":"La IA puede ayudarnos a escribir código más rápido, pero la velocidad por sí sola no garantiza buen software. El verdadero valor aparece cuando la usamos con criterio, contexto, reglas claras, revisión técnica y una arquitectura que la guíe.","title":"Programar con IA: más velocidad no siempre significa mejor software","type":"blog"},{"content":"","date":"12 de agosto de 2024","externalUrl":null,"permalink":"/tags/ciberseguridad/","section":"Tags","summary":"","title":"Ciberseguridad","type":"tags"},{"content":"","date":"12 de agosto de 2024","externalUrl":null,"permalink":"/tags/crowdstrike/","section":"Tags","summary":"","title":"Crowdstrike","type":"tags"},{"content":"Hay una idea con la que convivo hace años y que cada tanto la realidad se encarga de subrayar: solemos creer que tenemos todo bajo control hasta que una sola pieza se corre de lugar. Vivimos rodeados de capas que nos dan tranquilidad —sistemas, automatizaciones, plataformas cloud, monitoreo, actualizaciones automáticas— y esa tranquilidad funciona bien hasta que algo que instalamos para protegernos se convierte, aunque sea por error, en el origen del problema. Eso fue, en buena parte, lo que dejó el incidente de CrowdStrike de julio. No escribo esto para señalar a una empresa ni para caer en el \u0026ldquo;alguien se equivocó\u0026rdquo;, porque en tecnología todos convivimos con errores tarde o temprano. Me interesa otra cosa: usar el caso para pensar qué tan preparados estamos de verdad para resistir, recuperarnos y seguir funcionando cuando una dependencia crítica falla. Porque la resiliencia no se demuestra cuando todo anda bien, sino el día que algo se rompe.\nPara ubicarnos: qué es CrowdStrike # Para quien no esté tan metido en el mundo de la ciberseguridad, CrowdStrike es una empresa estadounidense especializada en seguridad informática, y su producto más conocido es Falcon: una plataforma que se instala en equipos y servidores para detectar, prevenir y responder ante amenazas. Dicho de forma simple, ayuda a proteger computadoras y entornos empresariales contra ataques, malware y comportamientos sospechosos.\nNo hablamos de una herramienta menor ni de una app que alguien usa suelta en su notebook. Es software de seguridad que vive en ambientes corporativos: bancos, aerolíneas, hospitales, organismos públicos, medios, organizaciones críticas. Y ahí aparece el primer punto que me parece importante. Cuando una herramienta así funciona bien, casi nadie la ve; está corriendo en silencio, protegiendo. El problema es que el día que falla, queda en evidencia lo profundamente integrada que estaba en la operación diaria.\nQué pasó en julio # El 19 de julio, una actualización de contenido de CrowdStrike para sistemas Windows generó fallas masivas. Muchos equipos empezaron a mostrar la famosa pantalla azul y quedaron sin poder iniciar correctamente. Microsoft estimó que el incidente afectó alrededor de 8,5 millones de dispositivos Windows, lo que en porcentaje representaba menos del 1% del total. Y sin embargo el impacto fue enorme, porque esos equipos estaban dentro de organizaciones que prestan servicios críticos.\nEse contraste me resulta revelador. A veces miramos los porcentajes y pensamos que menos del 1% es poco, pero en tecnología el impacto no se mide solo por cantidad: se mide por ubicación, criticidad, dependencia y capacidad de recuperación. No es lo mismo que falle una computadora personal a que falle un equipo dentro de un aeropuerto, un hospital o una sala de control. El problema de fondo no fue \u0026ldquo;se rompieron muchas máquinas\u0026rdquo;, sino que muchas de esas máquinas formaban parte de procesos que el mundo necesita que sigan funcionando.\nEl alcance: de lo global a lo cercano # El impacto fue global y muy visible. Hubo aerolíneas afectadas, vuelos demorados y cancelados, problemas en bancos, hospitales y medios, equipos técnicos corriendo para recuperar máquinas una por una. En Europa también se sintió, sobre todo en aeropuertos, servicios internacionales y empresas con infraestructura compartida; en España el evento se vivió principalmente como parte de esa afectación global, a través de aerolíneas y proveedores que operan de forma distribuida. En América Latina apareció de manera directa e indirecta: muchas empresas regionales no tenían todo su stack afectado, pero dependían de una aerolínea, un banco, una pasarela de pago o una herramienta SaaS que sí lo estaba.\nY este punto me parece clave: en 2024 ya casi ninguna organización es una isla. Incluso una empresa mediana, con sistemas relativamente simples, está conectada a decenas de proveedores —correo, CRM, facturación, pagos, analytics, cloud, seguridad, monitoreo, CI/CD— y cuando una pieza importante de ese ecosistema falla, el efecto llega aunque el problema no haya nacido dentro de tu propia infraestructura.\nPor qué vale la pena detenerse acá # Porque el caso deja una pregunta más profunda que \u0026ldquo;¿qué pasó con CrowdStrike?\u0026rdquo;. La pregunta real es qué tan preparada está una organización para seguir operando cuando falla una dependencia crítica. Y esa pregunta no distingue tamaños: vale igual para una multinacional, una startup, una pyme, un SaaS o un equipo interno de tecnología. Todas dependen de piezas, externas e internas, que pueden afectar el negocio si se caen.\nHablamos mucho de innovación, inteligencia artificial, automatización y transformación digital, y bastante menos de continuidad operativa, recuperación, planes de contingencia, pruebas de restauración o límites razonables para las actualizaciones automáticas. Sin eso, la innovación queda coja. Una organización puede acumular tecnología, pero si no puede resistir un incidente, esa misma tecnología termina siendo una forma de fragilidad.\nLa falsa sensación de control # Uno de los problemas más grandes en tecnología es justamente esa: la falsa sensación de control. Tenemos dashboards, alertas, backups, pipelines, monitoreo, tickets, reuniones, proveedores y contratos. Todo eso ayuda, claro, pero no garantiza que estemos preparados.\nSabemos que un proceso existe, pero no siempre qué pasa si falla. Usamos un proveedor, pero no siempre tenemos claro cuántos procesos dependen de él. Tenemos backups, aunque rara vez probamos restaurarlos bajo presión. Hay monitoreo, pero no siempre alerta sobre lo que de verdad importa. Existe un plan de contingencia, y tal vez nadie lo ejecutó nunca en una crisis real. En un incidente, la distancia entre \u0026ldquo;creemos que estamos preparados\u0026rdquo; y \u0026ldquo;estamos preparados\u0026rdquo; puede ser enorme, y normalmente se descubre en el peor momento.\nNo todo riesgo viene de un atacante # Cuando hablamos de ciberseguridad solemos imaginar ataques: ransomware, phishing, robo de credenciales, intrusiones. Pero lo de CrowdStrike no fue un ciberataque, sino una falla asociada a una actualización, y eso lo vuelve todavía más interesante para analizar, porque nos recuerda que el riesgo tecnológico no siempre tiene un atacante del otro lado.\nTambién hay riesgo en una actualización mal validada, en una dependencia demasiado extendida, en un despliegue sin control gradual, en una configuración incorrecta o en una integración crítica que no tiene alternativa. Lo hay en un proveedor que cambia algo sin suficiente visibilidad, en una automatización que ejecuta rápido lo que no debería ejecutarse tan rápido, o en un proceso de recuperación que depende de tocar equipo por equipo a mano. La seguridad no es solo evitar que alguien entre; también es asegurarnos de que aquello que instalamos para protegernos no pueda tumbar la operación completa ante una falla propia.\nLa importancia de los despliegues graduales # Uno de los aprendizajes que más se repite después de incidentes así es el valor de los despliegues graduales. En desarrollo de software hablamos seguido de canary releases, feature flags, staging, despliegues progresivos, rollback y monitoreo posterior al release. El detalle es que muchas veces aplicamos esos conceptos a nuestro propio código y pensamos mucho menos en las herramientas de terceros que viven dentro de nuestra infraestructura.\nUna actualización global, rápida y automática puede ser muy útil para responder ante amenazas reales; en seguridad la velocidad importa. Pero esa velocidad también necesita controles. La pregunta no es si hay que actualizar, sino cómo actualizar sin convertir una corrección en un incidente masivo. En algunos contextos tendrá sentido permitir actualizaciones inmediatas; en otros convendrá escalonar, segmentar o probar primero en grupos reducidos. No hay una respuesta única, pero sí una idea central: cuanto más crítica es una herramienta, más importante se vuelve entender cómo se actualiza, cómo se prueba y cómo se revierte.\nDependencias invisibles # Toda organización tiene dependencias visibles e invisibles. Las visibles las reconoce cualquiera: la base de datos principal, el proveedor cloud, el sistema de pagos, el CRM, el repositorio, el servidor de correo. Las invisibles son más peligrosas, porque suelen aparecer recién cuando fallan: un agente de seguridad instalado en miles de equipos, un servicio DNS, una política de autenticación, un certificado, una librería compartida, una cuenta de servicio o ese script que corre desde hace años y que \u0026ldquo;siempre funcionó\u0026rdquo;.\nLa resiliencia tecnológica empieza, en buena medida, por hacer visibles esas dependencias. No se puede proteger lo que no se conoce, recuperar lo que no está mapeado ni priorizar lo que no se entiende. Y esto no se resuelve solo comprando herramientas; se resuelve también con cultura técnica, documentación viva, conversaciones entre equipos y una mirada honesta sobre cómo funciona realmente la operación, más allá del diagrama.\nContinuidad operativa no es solo backup # Cuando hablamos de continuidad operativa aparece casi por reflejo la palabra backup. Los backups son fundamentales, no lo discuto, pero no alcanzan. La continuidad operativa abre muchas más preguntas: qué servicios son realmente críticos, cuánto tiempo podemos estar caídos, qué procesos tienen alternativa manual, quién toma decisiones durante un incidente, cómo se comunica el problema hacia adentro y hacia los clientes, qué proveedores hay que contactar y si alguna vez probamos el plan de recuperación.\nUn backup sin proceso de restauración probado es casi una promesa. Un plan de contingencia que nadie conoce es casi un documento decorativo. Un monitoreo que alerta tarde es apenas una explicación posterior. La resiliencia no se construye el día del incidente; se construye antes, en los días en que parece que no hace falta.\nEl costo de recuperar a mano # Uno de los aspectos más duros del incidente fue la recuperación. En muchos casos, los equipos afectados necesitaban intervención técnica directa para volver a funcionar, y ese detalle debería prender una alarma en cualquier organización. Cuando recuperar depende de tocar máquina por máquina, el tiempo de respuesta se vuelve mucho más difícil de controlar: no es lo mismo recuperar un servicio centralizado que intervenir cientos o miles de endpoints distribuidos.\nAhí aparecen preguntas incómodas. Si tenemos inventario actualizado de equipos y sabemos cuáles son críticos. Si podemos acceder de forma remota cuando el sistema operativo ni siquiera arranca. Si hay personal suficiente para una recuperación masiva, o si dependemos de soporte local en ciertas sedes o países. Qué pasa si el incidente ocurre fuera del horario laboral, o si afecta también las herramientas que usamos para coordinarnos entre nosotros. Muchas veces el problema técnico inicial dura poco; lo que se estira es la recuperación operativa. Y para el negocio, esa diferencia se siente.\nProveedores críticos: confianza, pero también control # Usar proveedores es parte normal de la tecnología moderna. No tiene sentido construir todo internamente: sería caro, lento y muchas veces peor. Pero tercerizar no significa dejar de gestionar el riesgo. Cuando una organización adopta una herramienta crítica, debería entender lo básico: qué nivel de acceso tiene, qué componentes puede afectar, cómo se actualiza, cómo se desactiva en una emergencia, qué alternativas existen, qué SLA ofrece, qué soporte hay durante un incidente y qué controles conserva la propia organización sobre los cambios.\nLa confianza en un proveedor no debería reemplazar el diseño de resiliencia. Podemos confiar en una empresa, en su trayectoria y en su equipo, y aun así asumir que algún día algo va a fallar. No porque el proveedor sea malo, sino porque los sistemas complejos, simplemente, fallan.\nLa resiliencia también es arquitectura # A veces se trata la resiliencia como un asunto de infraestructura u operaciones, pero también es una cuestión de arquitectura. Una arquitectura resiliente no es solo una que escala; es una que tolera fallos, que se degrada de forma controlada y que permite recuperarse. Eso implica pensar en aislamiento, segmentación, redundancia, observabilidad, rollback, circuit breakers, colas, reintentos, prioridades y modos degradados.\nNo todo tiene que seguir funcionando perfecto durante un incidente, pero sí deberíamos saber de antemano qué puede seguir funcionando, qué se degrada y qué se apaga para proteger al resto. En una organización real esto es decisivo, porque no todos los sistemas tienen la misma criticidad ni todas las funcionalidades valen lo mismo en una emergencia. Buena parte de la resiliencia consiste, justamente, en saber priorizar antes de que la urgencia decida por nosotros.\nEl rol del liderazgo técnico # En eventos como este, el liderazgo técnico ocupa un lugar enorme. No alcanza con que los equipos sepan mucho; hace falta alguien que ordene, priorice, comunique y decida bajo presión. Durante un incidente pasan muchas cosas a la vez: equipos investigando, áreas de negocio pidiendo información, clientes afectados, proveedores comunicando avances, directivos necesitando estimaciones, soporte recibiendo consultas y operaciones tratando de sostener lo que se pueda. Sin liderazgo, todo eso se convierte en ruido. Y el ruido, durante un incidente, también es un problema técnico.\nLiderar en tecnología no es solo definir arquitecturas o aprobar herramientas; es preparar a la organización para los momentos difíciles, lo que significa procesos claros, responsabilidades definidas, comunicación ordenada y capacidad de aprender después. Un buen postmortem vale oro, pero solo si se hace con honestidad: no para buscar culpables, sino para entender qué falló, qué no vimos y qué asumimos mal.\nLas preguntas que conviene hacerse # Más allá del caso puntual, el incidente deja una buena lista de preguntas para cualquier equipo de tecnología. Cuáles son nuestras dependencias críticas y qué herramientas tienen acceso profundo a nuestros sistemas. Si tenemos control real sobre sus actualizaciones y si podemos segmentarlas por grupos. Si mantenemos un inventario actualizado de servidores y endpoints, y qué sistemas pueden seguir operando en modo degradado. Cuánto tiempo podemos funcionar sin cada proveedor crítico. Si tenemos procedimientos de recuperación documentados, y —la más incómoda— si alguna vez los probamos. Cómo nos comunicamos durante una crisis, quién decide las prioridades, y si hacemos postmortems de verdad o solo cerramos tickets.\nSon preguntas que no resultan cómodas, pero son necesarias. Muchas veces la madurez tecnológica de una organización no se mide por la cantidad de herramientas que usa, sino por la calidad de las preguntas que se anima a hacerse.\nAlgunas ideas para avanzar # Si tuviera que aterrizar todo esto en acciones concretas, empezaría por mapear las dependencias críticas. No hace falta un documento perfecto desde el primer día; alcanza con empezar a identificar qué servicios, proveedores, agentes e integraciones son indispensables para operar. A partir de ahí, clasificar criticidad, porque no todo tiene la misma prioridad: hay cosas que pueden esperar, otras que pueden degradarse y otras que necesitan recuperación inmediata.\nDespués, revisar las políticas de actualización, sobre todo en herramientas con acceso profundo al sistema operativo, la red, la identidad o la infraestructura. Y probar la recuperación, porque tener procedimientos no es lo mismo que saber que funcionan; aunque sea en ejercicios pequeños y controlados, conviene ensayarlos. A eso le sumaría mejorar la comunicación de incidentes definiendo canales y responsables, hacer postmortems sin castigo —buscar culpables rara vez mejora un sistema, entender causas sí— y pensar de antemano en modos degradados, porque muchas veces operar parcialmente es bastante mejor que quedar completamente detenidos.\nEl caso CrowdStrike no debería dejarnos solo miedo a las actualizaciones automáticas ni desconfianza hacia una herramienta de seguridad. Debería dejarnos algo más útil: conciencia. Conciencia de que vivimos sobre sistemas cada vez más conectados, de que una dependencia pequeña en apariencia puede tener un impacto enorme, de que lo que instalamos para protegernos también puede introducir riesgos operativos, y de que la continuidad no se improvisa. Si la transformación digital no viene acompañada de resiliencia, lo único que conseguimos es construir organizaciones más modernas y, a la vez, más frágiles.\nQuizá ahí esté lo más valioso para llevarse. No alcanza con digitalizar, automatizar ni proteger: también hay que diseñar para fallar, recuperarse y aprender. La tecnología real no vive en los diagramas perfectos, vive en producción, con usuarios, proveedores, horarios, urgencias y decisiones humanas. Y ahí, tarde o temprano, algo se rompe. La diferencia está en si ese día nos encuentra improvisando o preparados para responder. Me quedo dando vueltas a una pregunta que cada uno puede llevarse a su propio contexto: si mañana cae una de tus dependencias más invisibles, ¿cuánto de la respuesta está diseñada y cuánto quedaría librado a la improvisación del momento?\nFuentes consultadas # Microsoft, \u0026ldquo;Helping our customers through the CrowdStrike outage\u0026rdquo;, 20 de julio de 2024. CrowdStrike, \u0026ldquo;Falcon Content Update Preliminary Post Incident Report\u0026rdquo;, 25 de julio de 2024. Reuters, \u0026ldquo;Microsoft says about 8.5 million of its devices affected by CrowdStrike-related outage\u0026rdquo;, 20 de julio de 2024. Reuters, \u0026ldquo;CrowdStrike says over 97% of Windows sensors back online\u0026rdquo;, 25 de julio de 2024. CrowdStrike, \u0026ldquo;External Technical Root Cause Analysis — Channel File 291\u0026rdquo;, 6 de agosto de 2024. ","date":"12 de agosto de 2024","externalUrl":null,"permalink":"/blog/post-resiliencia-tecnologica-despues-de-crowdstrike/","section":"Blog","summary":"El incidente de CrowdStrike no fue solo una falla técnica. Fue una demostración global de lo conectados, dependientes y frágiles que pueden ser nuestros sistemas cuando una pieza crítica falla.","title":"El día que una actualización frenó al mundo: resiliencia tecnológica después de CrowdStrike","type":"blog"},{"content":"","date":"12 de agosto de 2024","externalUrl":null,"permalink":"/tags/incidentes/","section":"Tags","summary":"","title":"Incidentes","type":"tags"},{"content":"","date":"12 de agosto de 2024","externalUrl":null,"permalink":"/tags/tecnologia/","section":"Tags","summary":"","title":"Tecnologia","type":"tags"},{"content":"","date":"6 de julio de 2024","externalUrl":null,"permalink":"/tags/datos/","section":"Tags","summary":"","title":"Datos","type":"tags"},{"content":"Quiero empezar por algo simple que, sin embargo, solemos pasar por alto: vivimos rodeados de tecnología y todavía nos cuesta entender cómo usarla realmente a nuestro favor. Tenemos sistemas, automatizaciones, inteligencia artificial, datos, plataformas e integraciones por todos lados, y eso no significa que estemos trabajando mejor, decidiendo mejor o viviendo mejor con todo eso. En este artículo voy a surfear un poco entre pensamientos y experiencias que fui juntando en este tiempo de convivir con la tecnología, peleándome y enamorándome de ella por partes iguales. No busco escribir un tratado eterno ni bajar una verdad absoluta; la idea es dejar algunos puntos de vista, ordenados por temas, para que cada quien pueda llevarse algo, cuestionarlo, discutirlo o usarlo como disparador.\nLa transformación digital es uno de esos conceptos que se repiten tanto que terminan perdiendo fuerza. Aparece en presentaciones, planes estratégicos, reuniones de producto, consultorías y hasta en charlas donde no queda claro qué significa realmente. Pero cuando uno trabaja en tecnología, lidera equipos, mantiene sistemas en producción y ve cómo una organización intenta mejorar sus procesos, se da cuenta de que transformarse digitalmente no es simplemente \u0026ldquo;usar más tecnología\u0026rdquo;.\nPara mí es un camino, no un destino ni un proyecto que se cierra en una fecha. Es una forma de repensar cómo trabajamos, cómo decidimos, cómo usamos los datos, cómo automatizamos tareas y cómo generamos valor real para las personas que usan nuestros productos o servicios.\nNo se trata solo de herramientas # Uno de los errores más comunes es creer que transformarse digitalmente significa comprar una herramienta nueva, migrar algo a la nube, sumar inteligencia artificial o automatizar un proceso aislado. Todo eso puede ayudar, claro, pero si la organización sigue pensando, trabajando y decidiendo igual que antes, la tecnología termina siendo una capa nueva sobre problemas viejos. La transformación digital necesita tecnología, pero también cultura, liderazgo, método y una buena dosis de paciencia.\nPodemos hablar de IA, machine learning, análisis de datos, automatización, IoT o cloud computing, pero el punto importante es entender para qué usamos todo eso. La pregunta no debería ser solamente qué tecnología podemos implementar, sino qué problema real queremos resolver y qué cambio necesitamos producir. Ahí es donde la tecnología empieza a tener sentido.\nEl cambio empieza en los procesos # Muchas organizaciones tienen procesos que crecieron con el tiempo. Algunos nacieron como una solución rápida, otros se fueron armando para apagar incendios y otros simplemente quedaron porque \u0026ldquo;siempre se hizo así\u0026rdquo;. El problema aparece cuando esos procesos empiezan a limitar el crecimiento: tareas manuales, controles repetidos, información duplicada, planillas que circulan por todos lados, decisiones tomadas sin datos claros, sistemas que no se hablan entre sí. Todo eso genera fricción, y la fricción, en una empresa, se paga: con tiempo, con errores, con frustración y con oportunidades que se pierden.\nLa transformación digital permite revisar esos procesos y hacerse preguntas honestas: si esto sigue teniendo sentido, si se puede automatizar, si estamos midiendo lo correcto, si hay datos suficientes para decidir mejor, si el equipo invierte su tiempo en tareas de valor o en tareas repetitivas. Automatizar por automatizar no sirve, pero automatizar lo que realmente molesta, lo que se repite y lo que genera errores puede cambiar muchísimo la dinámica de trabajo.\nLos datos como parte central del camino # Hoy casi todas las organizaciones generan datos; el problema es que no siempre los usan bien. Tener datos no es lo mismo que tener información útil, y tener dashboards tampoco garantiza tomar mejores decisiones. Para que los datos aporten valor tienen que ser confiables, accesibles y estar conectados con preguntas reales del negocio.\nUn buen uso de datos ayuda a entender mejor a los clientes, detectar patrones, anticipar problemas, medir el impacto de una decisión o descubrir oportunidades que antes no se veían. Ahí es donde tecnologías como la inteligencia artificial y el análisis avanzado pueden sumar mucho, pero de nuevo: la clave no está solo en la herramienta, sino en la pregunta que queremos responder. Un modelo, un reporte o un dashboard no reemplazan el criterio; lo potencian, siempre que estén bien diseñados y alimentados con datos confiables.\nLa experiencia del cliente como brújula # La transformación digital también tiene que mirar hacia afuera. No alcanza con mejorar procesos internos si eso no se traduce, de alguna forma, en una mejor experiencia para el cliente o el usuario final. La tecnología nos permite personalizar interacciones, responder más rápido, reducir pasos innecesarios, integrar canales y ofrecer servicios más simples.\nEl problema es que, desde adentro de una organización, nos acostumbramos a la complejidad: sabemos dónde hacer clic, qué planilla mirar, a quién preguntarle o qué workaround aplicar. El cliente no. Para el cliente, cada fricción cuenta. Una buena transformación digital debería reducir esa fricción y hacer que las cosas sean más claras, más rápidas y más simples.\nLiderazgo en la era digital # Ningún proceso de transformación funciona solo por decisión técnica; hace falta liderazgo. Y liderazgo no es únicamente aprobar presupuestos o pedir resultados, sino acompañar el cambio, comunicar bien, ordenar prioridades, aceptar que habrá errores y ayudar a que los equipos aprendan durante el proceso. Los líderes tienen que poder conectar la tecnología con la estrategia: entender qué aporta cada iniciativa, qué riesgo reduce, qué oportunidad abre y qué impacto tiene en la operación. También tienen que generar un ambiente donde probar, medir y ajustar sea parte normal del trabajo, porque la transformación digital necesita equipos que aprendan rápido, y para aprender rápido hay que aceptar que no todo sale perfecto al primer intento.\nCultura, habilidades y aprendizaje continuo # Uno de los desafíos más grandes no es técnico, sino cultural. La tecnología cambia rápido, pero las organizaciones no siempre cambian a la misma velocidad, y entonces aparecen resistencias, dudas, miedo a perder el control, miedo a la automatización o simple cansancio frente a tantos cambios. Por eso conviene trabajar también en las habilidades digitales de los equipos: no para que todos sean programadores o especialistas en IA, sino para que cada uno entienda mejor cómo usar la tecnología en su trabajo diario. Capacitar, acompañar, documentar, explicar y dar contexto es parte del proceso. Una organización que aprende de forma continua está mucho mejor preparada para adaptarse.\nAgilidad, pero con sentido # Las metodologías ágiles pueden ayudar mucho en este camino, siempre que se usen con criterio. Scrum, Kanban o cualquier otra no son soluciones mágicas, sino herramientas para organizar mejor el trabajo, entregar valor de forma incremental y adaptarse al cambio. El problema aparece cuando se implementan como una ceremonia vacía: reuniones, tableros, puntos, dailies y retrospectivas que no mejoran realmente la forma de trabajar. La agilidad bien entendida permite aprender antes, corregir antes y evitar grandes apuestas a ciegas, y eso en transformación digital es clave, porque casi nunca sabemos de entrada cuál será la mejor solución. Conviene avanzar en pasos chicos, validar, medir y ajustar.\nSistemas heredados y deuda técnica # Otro desafío habitual son los sistemas heredados. Casi toda organización con algunos años de funcionamiento tiene sistemas viejos, integraciones complejas, procesos que dependen de conocimiento tribal o piezas críticas que nadie quiere tocar demasiado, y la transformación digital no puede ignorar esa realidad. Modernizar no siempre significa tirar todo y empezar de cero; muchas veces implica convivir con lo existente, reducir riesgos, crear capas de integración, migrar gradualmente y mejorar la arquitectura sin romper el negocio. La deuda técnica no desaparece por decisión: se gestiona. Y gestionarla también es parte de la excelencia tecnológica.\nSeguridad y privacidad desde el inicio # A medida que digitalizamos procesos y conectamos más sistemas, también aumentan los riesgos, y la seguridad no puede quedar para el final. Cada automatización, integración, API, base de datos o herramienta nueva debería pensarse considerando seguridad, privacidad, permisos, trazabilidad y cumplimiento. No se trata de frenar la innovación, sino de construir con responsabilidad. Una organización que transforma digitalmente sus procesos también tiene que madurar en cómo protege la información y cómo gestiona sus riesgos tecnológicos.\nExcelencia tecnológica como mejora continua # Me gusta pensar la excelencia tecnológica como una búsqueda constante. No es tener la última tecnología, ni usar IA porque todos hablan de IA, ni migrar a la nube para poder decir que estamos en la nube. Excelencia tecnológica es usar bien la tecnología para resolver problemas reales: tener equipos preparados, procesos claros, datos confiables, arquitectura sostenible, seguridad bien pensada y capacidad de adaptación. También es saber decir que no, porque no toda moda merece implementarse, no toda herramienta nueva resuelve algo y no todo problema necesita una solución compleja. A veces, la mejor decisión tecnológica es simplificar.\nSi tuviera que resumir un camino posible para impulsar la transformación digital, lo pensaría más o menos así: entender bien la situación actual antes de moverse, detectar dónde hay fricción real, priorizar problemas en lugar de herramientas, automatizar las tareas repetitivas que tengan impacto claro, mejorar la calidad y disponibilidad de los datos, formar a los equipos, medir resultados, ajustar de forma continua, cuidar la seguridad desde el diseño y sostener una visión de largo plazo. No hace falta hacerlo todo de golpe; de hecho, intentar todo al mismo tiempo suele ser una mala idea. Lo importante es avanzar con dirección.\nPorque la transformación digital no es una carrera por implementar la última tecnología disponible, sino un proceso de evolución: revisar cómo trabajamos, cómo decidimos, cómo colaboramos y cómo entregamos valor. La tecnología es una parte fundamental del camino, pero no alcanza por sí sola; necesita personas, cultura, liderazgo y una estrategia clara. En definitiva, transformarse digitalmente es aprender a mejorar de forma continua usando la tecnología como aliada. Y en un mundo que cambia cada vez más rápido, esa capacidad de adaptación quizá sea una de las ventajas más importantes que una organización puede construir. Lo dejo abierto como pregunta para seguir pensando: si miramos nuestra propia organización, ¿cuánto de lo que llamamos \u0026ldquo;transformación\u0026rdquo; es cambio real en cómo trabajamos y decidimos, y cuánto es apenas una capa nueva de herramientas sobre las mismas costumbres de siempre?\n","date":"6 de julio de 2024","externalUrl":null,"permalink":"/blog/transformacion-digital-excelencia-tecnologica/","section":"Blog","summary":"La transformación digital no se trata solo de sumar herramientas. Es un camino de mejora continua donde tecnología, cultura, datos, procesos y liderazgo tienen que avanzar juntos.","title":"El viaje de la transformación digital: un camino hacia la excelencia tecnológica","type":"blog"},{"content":"\nSoy Hernán Rocca. Llevo más de 25 años metido en la tecnología: escribiendo código, diseñando arquitecturas, integrando sistemas que no fueron pensados para hablarse entre sí y, sobre todo, trabajando con los equipos que los sostienen. Soy argentino, vivo en Valencia y todavía necesito un mate cerca para pensar bien ☕🧉.\nHoy trabajo como Head of Technology Department en Doppler, donde dirijo el área de desarrollo e innovación —unas 15 personas— y acompaño la transformación del equipo hacia la IA y los agentes. En el fondo, mi trabajo es el mismo de siempre: convertir necesidades reales del negocio en decisiones técnicas que se sostengan en el tiempo, y hacer de puente entre la dirección, el producto y la gente que escribe el código.\nMe interesa la tecnología que sirve, no la que impresiona. Más de una vez la mejor decisión fue simplificar en lugar de sumar, y me cuesta entusiasmarme con la moda de turno sin antes preguntarme qué problema real resuelve.\nEn qué ando # Dirección y arquitectura de software: .NET, C#, microservicios, APIs, integraciones y bases de datos relacionales y no relacionales, siempre adaptado al tamaño real de cada organización. IA aplicada de verdad: asistentes, agentes conectados a herramientas, MCPs e inteligencia artificial dentro del propio proceso de desarrollo. No como demo, sino como capacidad que queda instalada en el equipo. Puente entre negocio y tecnología: ayudar a que la tecnología deje de ser un gasto difícil de explicar y se vuelva una herramienta concreta para vender, atender, operar o decidir mejor. Escribiendo en este blog: ensayos sobre IA, desarrollo, resiliencia y liderazgo técnico. No busco contar la última novedad, sino pensar en voz alta sobre lo que perdura cuando pasa el ruido. ¿Querés conocerme un poco más? # Armé un perfil profesional en PDF con mi experiencia, las tecnologías con las que trabajo y las formas concretas en que puedo ayudar a una empresa o a un proyecto. Es la versión corta y ordenada de todo esto.\n📄 Descargar mi perfil profesional (PDF)\nDónde encontrarme # GitHub: RockBanzai LinkedIn: Hernan Rocca Email: hola@hernanrocca.com ","externalUrl":null,"permalink":"/bio/","section":"Hernan Rocca","summary":"\nSoy Hernán Rocca. Llevo más de 25 años metido en la tecnología: escribiendo código, diseñando arquitecturas, integrando sistemas que no fueron pensados para hablarse entre sí y, sobre todo, trabajando con los equipos que los sostienen. Soy argentino, vivo en Valencia y todavía necesito un mate cerca para pensar bien ☕🧉.\n","title":"Bio","type":"page"},{"content":"","externalUrl":null,"permalink":"/categorias/","section":"Categorias","summary":"","title":"Categorias","type":"categorias"}]