La IA abarata la ejecución. El criterio sigue siendo escaso.

11 min de lectura

La historia de la sustitución ignora la decisión

Imagine que ventas promete a los clientes conocer el estado de sus pedidos en tiempo real, pero operaciones solo actualiza el sistema de origen una vez al día. Otro desarrollador puede construir un panel. Un agente de IA puede preparar uno antes del almuerzo. Ninguno convierte la promesa en realidad. Alguien debe reunir a ventas, operaciones, producto y desarrollo, decidir qué puede significar «en tiempo real» sin engañar a nadie y cambiar la promesa o el flujo de trabajo.

Ese es un problema de criterio. Si se trata como un problema de capacidad, la empresa obtiene una pantalla impecable con los datos de ayer.

Más o menos desarrolladores no es una estrategia

El sueño recurrente de sustituir a los desarrolladores ha llevado muchos disfraces. Lenguajes más legibles, generadores de código, herramientas visuales, plataformas de bajo código y ahora IA han eliminado fricciones reales. Ninguno ha eliminado la necesidad de razonar sobre reglas de negocio, excepciones y consecuencias.

La respuesta opuesta resulta igual de tentadora: cuando la entrega se frena, contratar a otro desarrollador. Una historia propone prescindir de desarrolladores; la otra, contratar más. Ambas pueden esquivar la pregunta incómoda de por qué está atascado el equipo actual.

Si el trabajo está claro y el equipo puede integrar a otra persona, más capacidad ayuda. Si una tarea delimitada tiene comprobaciones claras, la IA puede acelerarla. Use ambas donde correspondan.

Pero ninguna de las dos es un diagnóstico. Pregunte primero:

• ¿Está el resultado lo bastante claro como para que alguien lo implemente?
• ¿Entienden lo mismo por ese requisito los equipos de negocio y tecnología?
• ¿Puede el sistema sostener la promesa después del lanzamiento?

Si faltan esas respuestas, cambiar entre personas y agentes no resuelve nada. Solo cambia la velocidad a la que la ambigüedad se convierte en código.

Los agentes autónomos hacen que la vieja promesa parezca definitiva

Un agente de IA puede explorar una base de código, planificar un cambio, editar archivos, ejecutar pruebas y volver a intentarlo. Eso amplía de verdad su alcance técnico. La palabra autónomo sugiere que el sistema también puede asumir el criterio que da sentido a la tarea.

No puede. Como explica Qué es realmente un agente de IA, un agente es un modelo dentro de un bucle de software con herramientas, permisos y una condición de parada. La autonomía describe cuántos pasos puede dar entre decisiones humanas. No convierte el bucle en responsable del producto.

La fantasía de que la IA dirigirá sola la empresa tiene el mismo fallo a mayor escala: las acciones se pueden delegar, pero la responsabilidad permanece en quienes diseñaron y autorizaron el sistema.

Pídale que construya el panel y quizá lo construya. Pídale que cuestione el encargo y quizá detecte que los datos de ayer no sostienen una promesa de información en tiempo real. Bien. Ventas, operaciones y producto todavía deben decidir qué promesa mantener. El agente no puede asumir esa decisión.

Pero la velocidad local no demuestra que el sistema tenga coherencia. Una empresa ya puede producir cinco implementaciones plausibles antes del almuerzo y seguir sin saber cuál tiene sentido en el producto.

La conversación de Lenny Rachitsky con Elizabeth Stone, directora de Producto y Tecnología de Netflix plantea la misma distinción: la IA multiplica los resultados, pero hace falta pensamiento sistémico para no perder calidad ni rumbo entre tantos resultados.

Cuanto más rápido avanzan las piezas, más daño hacen las conexiones equivocadas:

• una promesa comercial se convierte en requisito sin responsable del dominio
• dos equipos resuelven la misma necesidad con modelos incompatibles
• un prototipo hecho con IA se convierte en software de producción sin dueño
• un atajo cambia lo que la empresa puede prometer con seguridad a sus clientes

El cuello de botella se ha desplazado. Teclear nunca fue todo el trabajo, pero ahora cuesta hasta mantener la ficción. Lo escaso es decidir qué merece existir, cómo encaja, quién se hace cargo y con qué tendrá que convivir la organización después del lanzamiento.

Eso es pensamiento sistémico.

Dominar el stack no equivale a conectar dominios

El regreso del generalista suele describirse como una expansión técnica. Quienes trabajan en frontend aprenden backend. Quienes trabajan en backend se ocupan de infraestructura. Todos aprenden a manejar herramientas de IA con soltura peligrosa antes del desayuno.

Útil, pero insuficiente.

Las fronteras difíciles están entre el comportamiento del cliente, las promesas comerciales, las reglas del dominio, las decisiones de producto, la arquitectura, las operaciones y la forma en que se toman decisiones.

Piense en una automatización supuestamente simple. El ticket pide un paso de aprobación.

Quien solo ejecuta puede implementar la transición de estado.

Quien piensa en el sistema pregunta otra cosa:

• ¿Quién tiene autoridad para aprobar y de dónde sale esa autoridad?
• ¿Qué ocurre si esa persona no está?
• ¿La aprobación hace que la acción sea definitiva, reversible o simplemente apta para el siguiente paso?
• ¿Qué pruebas necesitarán después operaciones, finanzas o un cliente?

No son interrupciones antes del trabajo de verdad.

Son el trabajo de verdad.

El código vuelve ejecutables las respuestas. No las vuelve correctas. La entrega suele fallar al traducir entre casillas: un supuesto del dominio pierde su condición, una fecha límite se convierte en decisión arquitectónica o un desarrollador resuelve el ticket al pie de la letra mientras el flujo sigue roto. Los generalistas adaptables siguen esa decisión a través de las fronteras y detectan dónde cambia de significado.

Esa amplitud no es falta de especialización. Conectar dominios es la especialización.

Por qué los líderes ven el dolor, pero no el patrón

El CEO ve iniciativas retrasadas, costes crecientes y compromisos que se mueven a través de resúmenes que omiten las conexiones incómodas. El CTO ve más detalle, pero un incidente interrumpe una decisión de arquitectura, un problema de contratación interrumpe una conversación de producto y una urgencia de un cliente interrumpe el trabajo que evitaría la siguiente.

El equipo ve las causas locales: un requisito inestable, un despliegue frágil, personas que no se ponen de acuerdo, un parche que se vuelve permanente. Nadie tiene a la vez el mandato y el tiempo para seguir el patrón de punta a punta.

A la organización no le falta inteligencia. La tiene distribuida, ocupada y atrapada en funciones separadas.

El criterio útil permanece lo bastante cerca del trabajo para inspeccionar la realidad sin perder la independencia necesaria para cuestionar las explicaciones de costumbre. Su ventaja es la atención dedicada: seguir un problema por decisiones, código, traspasos y lanzamientos hasta que el obstáculo se vuelva visible.

Por qué sobrevive la historia de la sustitución

La historia de la sustitución halaga un viejo deseo directivo: separar pensar de hacer, abaratar el hacer y dejar intactas las decisiones existentes. Si el software sigue sin encajar con el negocio, se culpa a la ejecución y se busca a alguien que ejecute mejor.

Contratar a otro desarrollador puede servir para esquivar lo mismo. Parece una medida concreta sin admitir que el encargo está mal planteado, que existen tres versiones incompatibles del producto o que una promesa comercial no tiene responsable en operaciones.

El encuadre determina lo que pueden hacer las personas y las herramientas. Pídales que ejecuten el ticket y eso harán. Pídales que examinen sus supuestos y quizá encuentren por qué la entrega vuelve una y otra vez al mismo punto.

La segunda petición incomoda más. Cruza ventas, producto, desarrollo y operaciones. Puede revelar que un equipo esperó días para recibir decisiones y después recibió la culpa por tardar semanas en entregar.

Por eso la empresa pide una implementación más rápida.

Después compra un taller de alineación.

Al parecer, la ironía tiene su propio código presupuestario.

El criterio debe permanecer cerca del trabajo

Quien conecta esos ámbitos puede ser un desarrollador experimentado, un responsable de producto o el CTO. Importa menos el cargo que el mandato: seguir un problema por los dominios que lo moldean y cuestionar un encargo que no resiste el contacto con la realidad.

Ese criterio se manifiesta al:

• detectar que varios retrasos aparentemente independientes comparten el mismo cuello de botella en las decisiones
• rastrear un fallo recurrente hasta un problema de responsabilidad o del dominio
• distinguir una limitación arquitectónica de una de coordinación
• ver cuándo el equipo resuelve el problema pedido mientras el negocio necesita que se resuelva otro

La capacidad técnica permite inspeccionar el código en vez de fiarse de una presentación y comprobar si una explicación resiste el contacto con el sistema. La IA puede acelerar esa inspección. Ni conocer el código ni producir resultados con IA aportan por sí solos el contexto de negocio o la autoridad para decidir.

Trabajar cerca de la realidad mantiene honesto el juicio. La independencia y el tiempo protegido hacen visible el patrón.

Por qué importa económicamente

Un CEO debería desconfiar de un plan que presume de resultados de agentes o de puestos eliminados mientras el trabajo rehecho y los tiempos de entrega no cambian. Hay que concretar el resultado operativo.

La empresa debería ver:

• menos iniciativas bloqueadas entre las decisiones de negocio y el trabajo técnico
• menos capacidad pagada que se pierde en trabajo rehecho y requisitos mal entendidos
• promesas que el sistema de entrega no puede sostener detectadas antes
• software funcional que llega antes a clientes y operaciones

Es fácil contar los puestos eliminados y los resultados que producen los agentes. Ninguna cifra demuestra que hayan mejorado los tiempos de entrega, la confianza en los lanzamientos o los resultados para los clientes.

La diferencia económica es sencilla. Más personas o más automatización aumentan lo que puede intentar el sistema de entrega actual. Mejor criterio puede cambiar la razón por la que ese sistema pierde tiempo una y otra vez.

El CTO sigue siendo el líder técnico

La ficción del agente autónomo tienta a confundir una larga secuencia de acciones con una transferencia de responsabilidad. La organización eligió la tarea, conectó las herramientas, otorgó permisos y decidió dónde debía detenerse el bucle para una revisión.

El CTO sigue siendo responsable de la organización técnica y su rumbo. Los expertos del dominio responden por la realidad de su área. Los responsables de producto responden por sus decisiones. Los desarrolladores responden por la calidad de lo que crean.

El CTO no tiene que aprobar cada llamada a una herramienta. Sí debe fijar permisos, puntos de control y pruebas exigibles, y dar espacio al equipo para señalar contradicciones. Cuando un agente detecta un supuesto falso, las personas responsables deben decidir qué cambia. Se trata de hacer visible esa decisión y actuar sobre ella en el propio trabajo.

Diagnosticar antes de sumar o sustituir

Contrate a otro desarrollador cuando el trabajo esté claro y el equipo pueda convertir capacidad adicional en resultados útiles. Use un agente cuando la tarea esté delimitada, sus resultados puedan verificarse y sus permisos y condiciones de parada estén claros. Son usos reales, no respuestas universales.

El criterio dedicado que cruza dominios se vuelve más valioso cuando:

• sumar personas no ha mejorado el tiempo de entrega ni la confianza en los lanzamientos
• los líderes manejan versiones distintas del problema
• los lanzamientos críticos dependen de heroicidades, recuerdos o intervenciones manuales
• no puede explicar si el obstáculo es de capacidad, decisiones, arquitectura, responsabilidad o forma de trabajar

Personas y agentes pueden trabajar juntos. A veces lo sensato es descubrir primero el verdadero obstáculo, reparar el camino de entrega y después sumar personas o automatización donde por fin sirvan.

Si todavía no entiende por qué se atasca la entrega, ni una nueva vacante ni una demostración con agentes son la opción prudente.

Ambas pueden convertirse en formas de aplazar la pregunta difícil.

El criterio necesita acceso

Si solo quiere ejecución técnica, defina la tarea, sus comprobaciones y quién responde por ella. Después elija las personas y herramientas adecuadas. No hay nada malo en llamar a la necesidad por su nombre.

Si quiere que alguien mejore la entrega entre negocio, dominio, producto, tecnología y operaciones, no lo encierre en la casilla técnica. Dele acceso a los supuestos, a los expertos del dominio, a los incentivos enfrentados y a las decisiones que moldean el trabajo antes de que llegue al backlog.

Después mida el resultado a escala del sistema:

• menos trabajo rehecho por necesidades mal entendidas
• menos tiempo entre la decisión y el software útil
• lanzamientos más seguros y recuperación más rápida
• mejor adopción porque el software encaja con el flujo real

La IA seguirá poniendo más resultados al alcance de todos. Eso no significa que la organización sepa decidir, conectar y asumir responsabilidades mejor.

Las empresas que entiendan la diferencia no se limitarán a entregar más artefactos. Construirán sistemas que sigan teniendo sentido después de que todos hayan trabajado a toda velocidad.

Eso exige capacidad técnica.

Y también el criterio para reconocer cuándo la tecnología no es el único dominio en la mesa.