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.
Vengo 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.
No 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.
Una 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.
Maganti 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.
Con 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.
Lo 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.
Pero 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.
Entonces tomó una decisión dolorosa y sana: tiró ese primer mes de trabajo y empezó de nuevo.
Para 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.
Cuando 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.
Esa 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.
Esto 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.
Pero 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í.
Ahí 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.
Por 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.
El 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.
Ahora 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.
El 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.
Esa 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?
La 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.
Maganti 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.
Ese 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.
Escribir 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.
La 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 “‘Tokenmaxxing’ 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.
La 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.
Con 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.
El 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.
Dicho en criollo: se mueve más la máquina, pero no necesariamente se aprovecha mejor la energía.
No 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.
The 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.
Las 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.
No 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.
Y cuando el uso se vuelve un símbolo, el criterio se corre del centro.
El 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.
La 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.
Por 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.
Ese 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.
La 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.
Usarla 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.
Y cuando no hay acuerdos, la IA completa los huecos. Igual que completa código.
Los 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.
No 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.
Esto 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.
La 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.
La 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.
Esa 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.
El 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.
Quizá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.
Lo 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.
Entender 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.
Me 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.
La IA no nos saca de esa historia. Nos pone una versión más rápida enfrente.
Por 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.
Fuentes 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, “‘Tokenmaxxing’ 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.