Esta semana no pude evitar hacerme una pregunta incómoda mientras miraba cómo un agente le cerraba un PR a un colega sin que él tocara una línea: ¿en qué momento pasamos de programar a simplemente aprobar?
No es una queja. Es una pregunta genuina que creo que vale la pena hacerse antes de que la respuesta nos la den otros. Porque si algo aprendí en 15 años de desarrollo es que las transiciones grandes en esta industria no llegan con un anuncio — llegan silenciosamente, un workflow a la vez, hasta que un día mirás para atrás y no reconocés cómo trabajabas antes.
Creo que estamos en uno de esos momentos.
De «completame el if/else» a «tomá la oficina»
Android Studio anunció soporte nativo para Gemma 4 corriendo en local. Lo que antes era autocompletado hoy es un agente que lee el ticket de Jira, abre la rama, escribe los tests y manda el PR. Solo le falta pedir el café.
Cuando lo vi funcionar por primera vez, mi reacción honesta fue una mezcla de asombro genuino y algo parecido al vértigo. Asombro porque técnicamente es impresionante — el agente no solo escribe código, entiende contexto, interpreta intenciones, anticipa casos borde. Vértigo porque me pregunté: ¿qué queda para nosotros en ese flujo?
Y acá viene mi problema personal con todo esto. Si lo único que hacemos es darle al botón «Aprobar», en dos años nadie va a saber por qué el sistema funciona. O peor, por qué se rompió. Porque el conocimiento no está en el código — está en las decisiones que se tomaron para escribirlo. En por qué se eligió esta arquitectura y no aquella. En por qué ese módulo está separado. En el contexto que vive en la cabeza de quien lo construyó.
La IA genera código. No genera criterio. Y cuando el sistema falle a las 2 a.m. — y va a fallar — alguien va a tener que entender qué está pasando. Ese alguien no puede ser otro agente.
Meta y el modelo que nadie esperaba
Zuckerberg lanzó Muse Spark esta semana y rompió con el patrón que Meta venía sosteniendo. A diferencia de la familia Llama, este modelo es cerrado, al menos por ahora. Lo cual ya dice algo sobre hacia dónde van las apuestas estratégicas de la empresa.
Pero lo que más me llamó la atención no fue el anuncio sino el detalle técnico detrás: Muse Spark es multimodal nativo con capacidad de razonamiento en tiempo real, y está diseñado específicamente para «ver» a través de cámaras e interactuar con redes sociales de forma fluida. No es un modelo de propósito general adaptado. Fue construido desde cero con ese caso de uso en mente.
Para los que estamos construyendo productos que tocan el mundo físico — apps con visión por computadora, integraciones con hardware, experiencias que mezclan lo digital con lo real — esto es importante. Hoy puede parecer otro lanzamiento más en un año lleno de lanzamientos. Pero la infraestructura que Meta tiene para distribuir esto, combinada con la escala de sus plataformas, hace que sea muy difícil ignorarlo en doce meses.
Lo tengo en el radar. Les recomiendo hacer lo mismo.
La deuda técnica que nadie está midiendo
Esto es lo que más me preocupa, y no lo digo como ejercicio teórico — lo veo en proyectos reales, semana a semana.
Hay una narrativa instalada que dice que la IA genera código más limpio, más consistente, más libre de errores humanos. Y en parte es verdad. Pero hay otra cara que no se habla tanto: la IA también genera código a una velocidad que ningún equipo puede auditar en tiempo real. Y cuando la presión es entregar, cuando el cliente quiere el deploy para ayer, la tentación de aprobar sin entender del todo es enorme.
El resultado es una deuda técnica nueva, diferente a la de antes. Antes acumulabas deuda porque ibas rápido y tomabas atajos conscientes. Ahora podés acumular deuda sin siquiera saber que lo estás haciendo, porque el código se ve prolijo, los tests pasan, y todo parece en orden hasta que no lo está.
Lo sé porque me pasó, con código mío, sin IA de por medio. Imaginate la escala del problema cuando el generador trabaja diez veces más rápido que cualquier desarrollador.
La pregunta que me hago — y que les propongo hacerse — es simple: ¿estamos midiendo el éxito por velocidad de entrega o por mantenibilidad? Porque son dos métricas muy distintas, y optimizar solo para la primera es una decisión que se paga cara, siempre, pero siempre más tarde de lo que uno espera.
Cosas que tengo en el radar
Anthropic bloqueó un lanzamiento. Detectaron miles de vulnerabilidades externas en un modelo nuevo y decidieron no lanzarlo. La noticia pasó relativamente desapercibida en medio del ruido de la semana, pero me parece una de las decisiones más importantes que vi tomar a un laboratorio de IA en mucho tiempo. En una industria donde la presión por ser el primero es constante, elegir no lanzar es una señal que vale la pena notar. «Más potente» no siempre significa «listo para producción.»
Gemini 2.5 Pro sigue siendo mi favorito para razonamiento pesado. Probé varias alternativas este mes y para algoritmos complejos, análisis lógico profundo y casos donde necesito que el modelo realmente piense antes de responder, todavía no encontré nada que lo supere en ese caso de uso específico. Para otras cosas hay mejores opciones, pero para eso, sigue siendo mi elección.
¿Ustedes dónde están parados en todo esto? ¿La IA ya toma decisiones de arquitectura en sus proyectos, o todavía mantienen el control total del proceso? No es una pregunta retórica — genuinamente me interesa saber cómo lo están manejando equipos de distintos tamaños. Los leo abajo.
Deja una respuesta