Sobre automatización, gobernanza técnica y la responsabilidad de no delegar criterio profesional en una herramienta que sólo recibió ambigüedad.

Hay algo que esta experiencia me ha hecho reflexionar sobre el liderazgo técnico y la incorporación de la inteligencia artificial en los equipos de desarrollo.

No me interesa plantear esto como una queja contra la inteligencia artificial. Tampoco como una defensa romántica de la forma “tradicional” de programar, lo que sea que eso signifique. El problema no es que los equipos usen IA. El problema aparece cuando se incorpora una herramienta con capacidad de interpretar, completar y proponer soluciones sin haber definido antes qué esperamos de ella, qué puede decidir y qué sigue siendo responsabilidad del ingeniero.

Con frecuencia escuchamos frases como “automatizar el proceso”, “usar ChatGPT”, “usar Claude Code” o “dejar que la IA lo haga”. Sin embargo, rara vez se define qué significa exactamente cualquiera de esas expresiones. Parecen conceptos evidentes, pero no lo son. Si dos desarrolladores reciben la instrucción de “automatizar” una tarea, es muy probable que cada uno entienda algo diferente.

Para algunos, automatizar significa ejecutar un script sin intervención manual. Para otros, significa orquestar un flujo completo de trabajo. Otros lo entienden como delegar la generación de código a un modelo de lenguaje. Sin una definición compartida, la instrucción deja de ser técnica y se convierte en una interpretación personal.

Ese problema se vuelve más evidente cuando se introduce inteligencia artificial generativa en un equipo.

La IA no elimina la ambigüedad. La procesa. Y cuando no hay suficiente contexto, la completa de la manera más razonable que puede construir a partir de lo que recibió. Ese es precisamente el riesgo: muchas veces no falla de forma obvia. Produce algo coherente, funcional e incluso elegante, pero alineado con una interpretación que quizá nunca fue validada por el equipo.

Por eso no basta con decir “usen ChatGPT” o “usen Claude”. También es necesario definir para qué se utilizarán, qué tipo de decisiones pueden delegarse al modelo, cuáles requieren revisión humana y qué estándares debe cumplir el resultado antes de integrarse al producto.

Antes de definir cómo utilizar una herramienta de este tipo, un líder técnico debería comprender quién integra su equipo. No todos provienen de la misma disciplina ni poseen el mismo modelo mental del desarrollo de software. Hay personas cuya formación principal es la ingeniería de software; otras vienen de matemáticas, economía, análisis de datos u otras áreas, y aprendieron Python como una herramienta para resolver problemas específicos. Ninguno de esos perfiles es incorrecto, pero sus necesidades de formación y la manera en que interpretan una misma instrucción son diferentes.

Precisamente por eso considero importante que un líder conozca el nivel técnico de las personas con las que trabaja. No para clasificarlas ni establecer jerarquías, sino para construir un lenguaje común. No tiene sentido explicar principios de composición, inversión de dependencias o diseño modular a alguien que todavía concibe un programa como un único script. Tampoco es razonable asumir que todos poseen experiencia desarrollando sistemas distribuidos, plataformas de alta concurrencia o aplicaciones que deben sostenerse durante años.

La diferencia no está en si una persona es capaz o no. La diferencia está en cuál es su modelo mental del software.

• Un script resuelve una tarea.
• Un sistema sostiene comportamiento.
• Un producto acumula decisiones.
• Y una plataforma, además, tiene que sobrevivir al cambio.

Cuando un equipo no distingue entre esas capas, la IA puede convertirse en una forma muy rápida de producir código y, al mismo tiempo, en una forma igual de rápida de degradar la intención del sistema. No porque la herramienta sea mala, sino porque nadie definió qué debía conservarse, qué podía modificarse y qué estaba fuera de discusión.

Con la inteligencia artificial, este problema se vuelve todavía más importante.

Un desarrollador con experiencia suele usar la IA para acelerar decisiones que ya sabe tomar. Puede pedirle una implementación, revisar la salida, detectar supuestos incorrectos, ajustar el diseño y rechazar lo que no corresponde. En ese caso, la IA funciona como un amplificador de criterio.

Pero un desarrollador con poca experiencia puede usar la IA para sustituir decisiones que todavía no sabe evaluar. Puede aceptar una solución porque compila, porque parece correcta o porque el modelo la explicó con seguridad. En ese caso, la IA no está acelerando el criterio técnico; está ocupando el lugar donde ese criterio todavía no existe.

Desde fuera, ambos casos se ven iguales: “están usando IA”. Pero no son iguales. Uno está delegando trabajo. El otro está delegando juicio. Y esa diferencia debería importarnos mucho más de lo que parece.

La IA no elimina la necesidad de liderazgo técnico. Al contrario, la incrementa.

Paradójicamente, cuanto más capaces se vuelven estas herramientas, más importante resulta establecer procesos, criterios y responsabilidades. La pregunta deja de ser qué modelo utiliza el equipo y pasa a ser mucho más básica: qué esperamos exactamente que haga la IA y qué decisiones siguen siendo responsabilidad del ingeniero.

Mientras esa pregunta permanezca sin responder, hablar de “automatizar” seguirá siendo insuficiente. Automatizar no es un objetivo técnico por sí mismo. Es una consecuencia de haber definido previamente el problema, los límites del sistema, las responsabilidades y los criterios bajo los cuales la automatización debe operar.

La inteligencia artificial puede ayudar a programar mejor. Puede acelerar exploración, documentación, pruebas, refactors y análisis. Puede incluso ayudar a descubrir caminos que el equipo no había considerado. Pero no debería convertirse en el lugar donde arrojamos ambigüedades esperando que regresen convertidas en arquitectura.

Porque cuando eso ocurre, el problema no es la IA. El problema es que nadie gobernó su uso. Y en ingeniería, cuando una herramienta empieza a tomar decisiones que nadie definió, el fallo no está en la herramienta. Está en el proceso que permitió que eso ocurriera.