Hay una idea instalada que me hace ruido hace rato: que la IA en programación sirve, sobre todo, para ir más rápido. Tirar código a la velocidad de la luz, cerrar tickets en la mitad de tiempo, despachar features. Y sí, sirve para eso, y es algo que con mis equipos tratamos de hacer cada día, lo mejor posible. Pero lo más interesante que me pasó usando estas herramientas no fue ir más rápido. Fue, paradójicamente, empezar a ir más despacio y a validar mucho mejor los componentes y la arquitectura.
De acelerador a revisor
Leí hace poco un post de Nolan Lawson que puso en palabras algo que yo venía sintiendo sin terminar de ordenar. Él cuenta cómo usa la IA no tanto para generar, sino para revisar: corre varios modelos en paralelo —un subagente de Claude, Codex, un bot de revisión— sobre un mismo pull request, junta lo que cada uno encuentra, filtra los falsos positivos y se queda con los problemas que importan, rankeados por severidad.
Lo honesto del planteo es que esto no te hace más rápido. Al contrario: muchas veces te frena, porque saca a la luz bugs que ya estaban y que ahora hay que arreglar. Pero ahí está la apuesta: si vas un poco más lento, pero con un proceso de desarrollo serio y un flujo que se respete —uno pensado para que la IA juegue a favor y no alucine ni se vaya por las ramas—, terminás con algo muchísimo más sólido. Es una decisión deliberada a favor de la salud del proyecto por encima de la métrica de velocidad. Y todo esto —el proceso, el flujo, cómo lograr que la IA sume en serio— es exactamente lo que vamos a ver en el AI-First Builders Lab. Para mí, ese es el cambio de mentalidad que vale la pena.
Lo que cambió en mi forma de trabajar
Yo arranqué, como casi todos, usando la IA para escribir más rápido. Autocompletar, generar el boilerplate, resolver la función tediosa. Pero con el tiempo el uso que más valor me da es otro: pedirle que sea el abogado del diablo de mi propio código. «Buscame los bugs de este PR, rankeados por crítico/alto/medio/bajo». «Decime qué edge cases no estoy contemplando». «¿Dónde se me puede romper esto en producción?». «¿Estoy siguiendo las prácticas recomendadas para este tipo de software?». «¿Cómo resuelven esto los proyectos serios del ecosistema, qué patrón se usa hoy?».
Y ahí aparecen cosas que se me habrían pasado: una política de seguridad mal puesta, un caso límite que no estaba cubierto, un problema de performance latente. Cosas que no atrapa un test que escribí yo mismo con los mismos supuestos con los que escribí el bug.
Velocidad no es lo mismo que valor
Acá está, para mí, el malentendido grande de esta etapa. Medimos a los equipos por velocidad —líneas, commits, features— como si fuera lo único que importa. Pero el código que escribís rápido y mal después lo pagás caro: en bugs, en deuda técnica, en incidentes a las tres de la mañana. Ir un poco más lento para entregar algo más sólido casi siempre es el mejor negocio, solo que es un negocio que no se ve en el dashboard de la semana.
La IA, usada como revisor, te empuja justo para ese lado: te obliga a mirar lo que preferirías no mirar. Es incómodo, porque te frena. Pero es el tipo de fricción que querés tener.
La herramienta amplifica al que la maneja
Al final, creo que estas herramientas no te hacen mejor ni peor programador por sí solas: amplifican la intención con la que las usás. Si las usás solo para ir rápido, vas a producir más código —bueno y malo— más rápido. Si las usás para pensar mejor, para revisar, para cuestionar tus propias decisiones, te vuelven un programador más cuidadoso.
Yo elijo, cada vez más, la segunda. Prefiero ir un poco más lento y dormir tranquilo. Y si algo aprendí en estos meses es que la pregunta correcta no es «¿cuánto más rápido voy con IA?», sino «¿qué calidad puedo alcanzar ahora que antes no me daba el tiempo?«. Y creeme una cosa: con el proceso bien armado, igual vas a terminar tirando código a la velocidad de la luz, cerrando tickets en la mitad de tiempo y despachando features. La diferencia es que ahora, además, vas a estar tranquilo de lo que entregás.
