IA en desarrollo de software: decisiones estratégicas, y algunas preguntas incómodas

La nueva narrativa en ingeniería de software es bastante clara: dejemos de escribir código, empecemos a escribir especificaciones; la IA se encarga del resto, y nosotros solo “supervisamos”.

Suena eficiente, moderno y muy bien en un slide con fondo oscuro. Pero antes de rediseñar cómo trabaja un equipo alrededor de esa idea, vale la pena hacer una pausa y plantearnos algunas preguntas que no entran en la demo de 10 minutos.

El nuevo cuello de botella ahora se llama “especificación”

El cuento es simple: si escribimos buenas especificaciones, la IA genera buen código. Problema resuelto.

Pero hay un detalle menor: una “buena especificación” no la escribe cualquiera. Hace falta alguien que entienda el dominio (business), conozca la arquitectura, sepa dónde están los “esqueletos ocultos” del sistema y que haya sufrido suficientes salidas a producción como para anticipar los casos borde. Es decir, la misma gente que podría resolver el problema de punta a punta sin necesidad de usar IA.

Entonces vale la pena preguntarse: Si necesito a mis perfiles más caros para escribir specs ultra detalladas…

• ¿En qué punto deja de ser más rápido que esa misma gente escriba directamente el código crítico?
• ¿Si la IA va a necesitar definiciones detalladas para hacer el trabajo no es eso lo mismo que ya hacemos con los desarrolladores juniors?
• ¿Qué tanto es más eficiente y qué tanto retorno de inversión me reportarían estos agentes vs darle a un junior las mismas especificaciones detalladas?

Si la respuesta es “no lo tenemos claro, pero hay un gráfico que muestra 3x productividad”, quizá todavía no estamos ante una decisión basada en datos, sino ante un deseo.

Productividad: ¿medimos valor entregado o solo código producido?

Muchas historias de éxito con IA muestran la misma escena: un agente genera una feature entera en minutos y todos aplauden.

Pero la realidad de un sistema en producción tiene algunos pasos más:

• Entender el problema (muchas veces la parte difícil)
• Decidir la solución (evaluar sus trade‑offs y prepararse para cambios en el futuro)
• Implementar, Revisar, Probar, Integrar, Desplegar
• Operación y mantenimiento (más conocido como arreglar cuando algo falla a las 3 AM)

Acelerar brutalmente solo la implementación sin tocar nada de lo demás suele traer un efecto colateral bastante predecible: Aumentan la cantidad de cambios por semana, crece el volumen de código por revisar y aparecen más errores sutiles que no se ven en la happy path.

Resultado: el cuello de botella se mueve a code review, QA y mantenimiento. El equipo se siente “más productivo” porque pasa más cosas por el repo, pero el negocio sigue esperando el mismo release que no termina de estabilizar.

Al final terminamos con estas preguntas que no suenan tan bien en marketing, pero que si te tienes que hacer antes de comprar la idea:

• ¿El tiempo real desde “tuvimos la idea” hasta “el cliente lo usa” va a bajar … o solo baja el tiempo de escribir el código?
• ¿Qué pasa con la corrección de errores, re-trabajo y manejo de incidencias después de introducir agentes?
• ¿Estamos midiendo la productividad real de la empresa o solo celebrando que ahora hay más PRs por semana?

Si la métrica estrella es “líneas de código generadas por IA”, ya sabemos quién está ganando dinero de verdad, y no necesariamente es la empresa.

¿Los estudios que nos muestran se parecen al trabajo que hacemos … o a un laboratorio?

Los números de “+50% de productividad” suelen venir de escenarios muy controlados: tareas acotadas, requisitos claros, código limpio, sin política interna, ni legacy, ni “esto no lo documentamos nunca pero no lo toques”.

Mientras tanto, muchos equipos viven en un mundo donde: hay sistemas con 10 años de historia y 0 años de documentación, participan varios equipos y proveedores que no se hablan tanto como deberían, las reglas de negocio completas están repartidas entre código, slides y la memoria de dos personas.

Pregunta básica, pero que se salta a menudo:

¿El tipo de trabajo medido en esos estudios se parece al que hace mi organización… o solo se parece a la demo que vimos en la conferencia?

Si la respuesta es “no mucho, pero el número queda lindo en la estrategia”, entonces estamos comprando narrativa, no evidencia.

Capacidad interna: ese activo que es fácil erosionar sin darse cuenta

Cuando el código lo empieza a escribir casi siempre una IA, ocurren algunas cosas silenciosas:

• Tus devs dejan de ejercitar la habilidad de navegar y modificar sistemas complejos sin muletas.
• El reflejo automático ante cualquier cambio pasa a ser “pedírselo al agente”.
• Cada vez hay más partes del sistema que nadie del equipo escribió realmente de punta a punta.

En términos de negocio, esto se puede leer así:

• Bajamos resiliencia: si la herramienta cambia de precio, de condiciones o simplemente deja de ser competitiva, la capacidad interna no está donde estaba.
• Acumulamos deuda técnica menos visible: funciona hoy, pero nadie quiere ser el que toque eso mañana.
• Nos atamos no solo a un proveedor, sino a un estilo de trabajo difícil de revertir sin coste serio.

Pregunta que conviene hacerse mirando dos o tres años hacia adelante, no el próximo Q:

Si mañana tuviera que reducir drásticamente el uso de estos agentes por coste, regulación o estrategia: ¿Mi equipo podría seguir entregando con velocidad y calidad razonables… o tendría que reaprender a programar bajo presión?

Si la imagen mental da un poco de vértigo, el riesgo ya está ahí aunque el dashboard diga “todo verde”.

Los incentivos: quién necesita que esto sea una revolución sí o sí

No hace falta conspiración cuando los incentivos están tan alineados:

• Los proveedores de modelos necesitan historias de “transformación radical” para justificar rondas y valuaciones.
• Las herramientas de IA para devs necesitan que reorganizar el proceso alrededor suyo parezca inevitable, no opcional.
• Las consultoras viven mejor cuando el proyecto se llama “transformación” que cuando se llama “ajuste incremental”.

Y, por supuesto, dentro de las empresas hay carreras personales atadas a “liderar la adopción de IA” y nadie quiere ser el que en la reunión diga “esperemos a ver datos” mientras el resto habla de “no quedarnos atrás”.

Un filtro sano antes de comprar cualquier plan es reformularlo mentalmente:

Si quien me propone esto no tuviera ninguna exposición financiera ni reputacional a que la IA sea “revolucionaria”, ¿recomendaría exactamente lo mismo, con la misma agresividad?

Si la respuesta es “probablemente no”, ahí aparece el conflicto de interés, aunque nadie lo escriba en el slide.

Entonces, ¿dónde tiene sentido apostar fuerte hoy?

Nada de esto implica que la IA no sirva. Implica que no todo lo que podemos hacer con ella tiene el mismo perfil de riesgo vs retorno.

Los casos con mejor relación costo/beneficio suelen ser:

• Acelerar a los devs en tareas repetitivas: tests, refactors mecánicos, documentación, ejemplos.
• Hacer trabajo que nunca entraba en el backlog porque el coste no cerraba: scripts internos, automatización menor, limpieza incremental.
• Explorar más opciones de diseño antes de comprometerse con una sola, sin multiplicar el esfuerzo manual.

Ahí, si algo sale mal, el impacto es acotado. Si sale bien, el beneficio es claro.

En cambio, reorganizar el modelo de trabajo completo bajo la premisa de que:

• “la IA va a escribir la mayor parte del código”
• “los devs serán productores de especificaciones”
• “y la supervisión alcanzará para mantener la calidad”

es una apuesta de alto impacto con evidencia todavía limitada a escala real.

La pregunta de fondo no es si la IA “es el futuro”; esa está resuelta desde marketing hace rato.

La pregunta que sí puede ayudarte a tomar decisiones es otra:

¿Estamos integrando IA en desarrollo de una forma que mejora el retorno del sistema completo sin degradar capacidades clave del equipo ni atarnos a una dependencia difícil de revertir?

Si la respuesta es sí, adelante: usa todo lo que tengas a mano.

Si la respuesta es “no estoy seguro, pero el mercado parece moverse”, el siguiente paso no es reestructurar el equipo. Sino empezar a diseñar experimentos pequeños sin dejar que el entusiasmo vaya por delante de los números.