Pionero de DevOps advierte: la adopción de agentes de IA requiere cambios a nivel de sistema, no solo herramientas

No sigas arreglando el código generado por el agente; arregla el sistema que genera ese código.

Autor y fuente del artículo: InfoQ

Si un desarrollador no puede usar bien el Agente, el problema probablemente no esté en el desarrollador, sino en que la empresa no ha preparado un sistema funcional para el Agente.

Muchas empresas denominan "transformación de IA" simplemente comprar herramientas como Cursor o Claude Code para desarrolladores, organizar algunas capacitaciones y dejar que todos exploren por su cuenta. Si finalmente los agentes no funcionan bien, la responsabilidad recae nuevamente sobre los usuarios.

Pero Patrick Debois, el creador del término DevOps, cree: “Los desarrolladores necesitan realizar un cambio de mentalidad importante: cuando el agente no complete la tarea según lo esperado, no debes modificar el código que generó, sino mejorar todo el sistema, no solo el Prompt.”

Para Debois, este es un cambio inherente que debe ocurrir cuando la ingeniería de software pasa de sistemas deterministas a sistemas no deterministas, probabilísticos y flujos de trabajo. No solo implica tecnología, sino que también redefinirá la forma en que los desarrolladores, los equipos y toda la organización trabajan. Pero este cambio no puede lograrse solo por un ingeniero ni limitarse al nivel de un solo equipo. Al igual que DevOps, solo se logra realmente cuando se implementa a escala.

El núcleo del problema no es solo si los desarrolladores usarán Agent, sino si la empresa puede reorganizar a los equipos, la plataforma y los métodos de colaboración en torno a Agent.

Los puntos clave son los siguientes:

• No sigas arreglando el código generado por el agente; arregla el sistema que genera ese código.
• Si aún hay alguien en tu equipo que use ese enfoque salvaje de "YOLO" para hacer vibe coding, debes detenerlo inmediatamente. Las prácticas de ingeniería son cruciales no solo para mantener tu sistema, sino también para que el Agente siga mejorando constantemente.
• La fábrica oscura puede no estar completamente oscura, sino que conserva algo de luz tenue (dim factory), lo que significa que debes decidir qué funciones asumirán qué nivel de riesgo, ya que no todas las funciones son adecuadas para la autonomía total.
• La persona que buscas es alguien que pueda utilizar AI al máximo, tenga una sólida base en ingeniería y esté dispuesto a compartir y colaborar.
• Tu ventaja competitiva es capturar el conocimiento acumulado, aquel que ahora estás incorporando en skill, Context y hasta en las restricciones de Harness.

En 2009, un montón de personas me dijeron que la idea de entrega continua era una locura.

Nota del traductor: En 2009, la industria adoptaba comúnmente un modelo de lanzamiento concentrado de grandes versiones cada varios meses; se asumía que cuantas más publicaciones se realizaran, mayor sería el riesgo. Además, existían barreras estrictas entre desarrollo y operaciones, las infraestructuras automatizadas como contenedores y nube aún no estaban maduras, y faltaban herramientas estandarizadas para pipelines. Al mismo tiempo, los mecanismos tradicionales de pruebas y aprobación de cambios buscaban eliminar tantos defectos como fuera posible antes del lanzamiento, mientras que la entrega continua introdujo la idea de lanzamientos frecuentes, incrementales y siempre disponibles, desafiando la percepción convencional sobre el riesgo y el control de procesos en el lanzamiento de software, por lo que, para la mayoría de las empresas, parecía una locura o algo imposible.

Y ahora, Dark Factory se encuentra con exactamente la misma resistencia.

Translator's note: The Dark Factory refers to an AI-driven autonomous software production model in which humans input only the SPEC, and AI autonomously completes coding, testing, and deployment without requiring human review of each line of code, differing from traditional software factories that still require substantial engineer involvement in the process.

He escuchado una y otra vez la misma frase en diversos contextos: “Esto no funciona aquí”. Pero la información real que transmite esta frase no es que la tecnología no funcione, sino que “aún no estamos preparados”. No es que no quieran implementar esto, sino que la estructura actual de la organización no puede respaldar este modelo.

Mucha gente hoy en día habla sobre cómo optimizar Agentes con ciclos o cómo configurar Harnesss, lo cual es excelente. Pero quiero decir que, eventualmente, todos alcanzaremos ese nivel tecnológico, y algún día se convertirán en productos estándar, incluso serán empaquetados y ofrecidos como servicios por algún laboratorio de vanguardia. En ese momento, ya no habrá barreras tecnológicas. La verdadera diferenciación estará en cómo tu organización reestructura sus formas de colaboración en torno a esto.

Entonces asumo que todos estamos avanzando hacia la fábrica oscura. Lo que he observado en Tessl y en otras empresas es que, cuando las personas comienzan a adoptar estas tecnologías, la dinámica de colaboración cambia por completo. Si están familiarizados con la ley de Conway, saben que existe una relación de mutua influencia entre la organización y las herramientas: cómo organizas a las personas determina qué tipo de sistemas creas. Pero hoy no voy a hablar sobre cómo hacer que tus Agentes sean mejores; voy a hablar sobre cómo esto cambia la dinámica de tu equipo, tu plataforma y toda tu organización.

Supongo que la mayoría de ustedes aquí trabajan en un equipo, no de forma individual; trabajar en equipo es completamente diferente a sentarse y escribir código frente a Claude Code.

Ahora todos hablan de esta idea: los desarrolladores finalmente se convertirán en un director de orquesta, un organizador de Agentes. Creo que esta afirmación no tiene nada de malo; realmente es el camino en el que nos encontramos. Nos estamos volviendo cada vez más como administradores de Agentes, y debemos gestionar la relación con ellos.

Pero el problema es que he escuchado a muchos desarrolladores decir en privado: No entramos a esta industria para hacer esto, no pensamos que tendríamos que dedicar mucho tiempo a optimizar prompts o escribir mejores especificaciones. Somos ingenieros, trabajamos con tecnología, y esto nos genera una sensación de conflicto identitario, preguntándonos constantemente: ¿Este es realmente el rol que quiero desempeñar?

Luego surgió el concepto de "ingeniería de contexto", que ofreció a los desarrolladores una especie de salida. Este concepto sostiene que no se trata solo de llamar a los prompts; también debes probar, evaluar, distribuir y optimizar los prompts, por lo que realmente tiene un cierto aire de ingeniería. Pero, francamente, muchos desarrolladores aún sienten que trabajar únicamente con prompts y SPEC es vacío, y se sienten como si hubieran pasado de ser ingenieros a ser "administradores de prompts".

Pero en la práctica observé un giro muy interesante: cuando comenzamos a introducir Harness, ciclos e incluso a llevar a toda la organización hacia un mayor grado de autonomía, se abrió una nueva vía técnica. De repente, los desarrolladores necesitaban construir herramientas para los Agentes, y esto reavivó de inmediato a un grupo de personas. Aquellos que antes pensaban “esto no es cosa mía” de pronto se entusiasmaron. Decían: ¡sí, podemos hacer esto! ¡Tenemos este conocimiento! Podemos mejorar este sistema mediante programación. Así que es interesante: mientras continuábamos hablando de “abstracción, abstracción, más abstracción”, el sentido de “artesanía” resurgió en otro lugar, creando un nuevo espacio para trabajos de ingeniería más técnicos.

A menudo me preguntan: ¿Cómo convences a las personas escépticas? Mi respuesta siempre es: estas personas son en realidad tus tesoros. Tienen una gran cantidad de conocimientos implícitos y juicio que necesitas incorporar en el Agente. Puedes decirles: “Por favor, saca todo tu conocimiento y tu escepticismo”, lo que hará que el Agente y Harness sean mejores. Si te encuentras con alguien que se resiste y se queja constantemente: “La calidad del código generado es demasiado baja”, puedes usarlo como combustible: convierte esa ira y escepticismo en impulso para mejorar el sistema.

Ahora, permíteme dar una sugerencia a los desarrolladores de la empresa: realizar un cambio mental significativo: ya no arreglen el código generado por el Agente, sino arreglen el sistema que produce ese código. Como alguien dijo hace unos años: "No construyas la cosa, construye la cosa que puede construir esa cosa". Actualmente estamos en este nivel de abstracción, creando "la cosa que puede construir cosas" a través de Contexto, Harness y ciclos. Muchos que aún se encuentran en la etapa de "Human in the Loop", completado automático o ajuste de prompts, necesitan reflexionar sobre cómo elevarse al pensamiento sistémico.

Lo que realmente debemos hacer es minimizar la cantidad de intervención humana mediante buenas prácticas de ingeniería. Al principio, todos pensaban que el “vibe coding” era genial: lanzar un Prompt, obtener un resultado y seguir adelante sin preocuparse. Pero ahora es cada vez más claro que no solo estamos dando instrucciones al Agente mediante Prompts; en realidad estamos diciendo: por favor, escribe con pruebas, actualiza la documentación, sigue las normas de código. Todo lo que antes decíamos a un buen ingeniero, ahora lo decimos exactamente igual al Agente. Si aún hay alguien en tu equipo que usa ese enfoque salvaje de “YOLO (primero haz que funcione)” para hacer vibe coding, debes detenerlo inmediatamente. Las prácticas de ingeniería no solo son cruciales para mantener tu sistema, sino también para que el Agente siga mejorando constantemente.

En algunos equipos más avanzados, he comenzado a ver un nuevo ritual: aún realizan reuniones de planificación y retrospectivas, pero el contenido de las discusiones ha cambiado por completo. En lugar de preguntar “¿Qué salió mal con el código?”, ahora preguntan “¿Qué salió mal con el sistema?”.

También observé una división interesante en la reunión de planificación. Las tareas definidas con mucha claridad y con un alcance suficientemente preciso se pueden asignar directamente a los Agentes, ya que Harness mejora constantemente y puede manejar este tipo de tareas claras. Mientras tanto, los asuntos con límites borrosos que requieren discusión siguen siendo responsabilidad de los humanos. Así, surgió una división natural en la reunión: estas tarjetas van directamente por la línea de Agentes, esas otras tarjetas las discutimos nosotros.

Los desarrolladores suelen atravesar un ciclo de aprendizaje: primero aprenden sobre Prompt, luego sobre mejores SPEC, seguido de Context, Harness y ciclos, y toda la industria está ascendiendo por este ciclo. Pero lo que puede hacer el líder del equipo es establecer el ritmo y las restricciones para este proceso, por ejemplo, decirles: “Dejen de ajustar el Prompt y hagan que el Context sea reutilizable.” “Bien, esta etapa ya está terminada, pasemos a la siguiente.” El valor del líder del equipo radica en establecer este ritmo; si simplemente dices “descúbrelo por tu cuenta”, no funcionará.

También hay un efecto secundario: una vez que la productividad de tu equipo comience a aumentar drásticamente, las personas aguas abajo, como las encargadas de GTM (Go to Market), no podrán seguir el ritmo, e incluso los usuarios podrían quedar atrás. Por lo tanto, necesitas utilizar la automatización para ayudarlos; tu marco no debe detenerse en la codificación, sino extenderse hasta ellos. Lo mismo se aplica a las entradas de requisitos aguas arriba: si los requisitos no llegan lo suficientemente rápido, el equipo se estancará, y estos eslabones también deben integrarse en este nuevo flujo de trabajo.

Actualmente hay una gran cantidad de indicadores en el mercado, como el gasto en tokens, etc. Pero cada vez confío más en dos indicadores reales que miden la productividad. El primero: cuenta cuántas intervenciones humanas aún necesitas para que un agente realice correctamente una tarea. Este número debe disminuir constantemente. Cuanto mejor sea tu Harness, mejor tu contexto y más clara tu guía, más bajo será este número. El segundo indicador es que, al pasar de trabajar de forma individual a un sistema compartido, se produce un efecto multiplicador. Cuando arreglas algo en un lugar, todos se benefician. No se trata de que una persona se vuelva diez veces más eficiente, sino de que una optimización en el sistema de agentes genera un efecto multiplicador en todos.

Puedes comenzar en un repositorio o dentro de un pequeño equipo, compartir el Contexto y mejorar conjuntamente el Harness. Pero lo que realmente deseas hacer es extender este efecto a toda la organización. En este punto, tenemos que hablar sobre los equipos de plataforma.

El equipo de plataforma es típicamente una organización compartida, y actualmente podrían estar enfocándose en infraestructura, servicios en la nube, puertas de enlace MCP, etc., sin prestar mucha atención al área de Agentes. Sin embargo, están surgiendo una serie de nuevos elementos que necesitan ser asumidos por ellos, como un registro de habilidades (no se puede permitir que cada uno invente sus propias habilidades en su rincón), un sistema de evaluación de contexto (¿este contexto realmente tiene utilidad? ¿Se puede cuantificar?), y controles y gestión de identidad específicos para agentes de programación (¿con qué identidad envía el agente el código? ¿Cuáles son los límites de permisos?). Por lo tanto, el equipo de plataforma necesita alguien que los ayude a crecer y asumir este nuevo rol central.

Esto es difícil; necesitas un propietario claro que lo impulse. ¿Pero quién debería ser? ¿El equipo de plataforma? ¿El equipo de experiencia del desarrollador? El primero normalmente no toca cosas a nivel de desarrollo, y el segundo no suele tocar infraestructura, por lo que se necesita alguna forma de fusión, pero esta fusión no ocurre automáticamente. Debes asegurarte de que haya un responsable que impulse este trabajo centralizado; de lo contrario, tu equipo simplemente se dedicará a trabajar en su propio ámbito, sin que aparezca una “Paved Road”.

¿Por qué cada equipo tiene que inventar su propio método de integración para el sistema de autenticación? Esto es un componente compartido y debería incorporarse al registro. ¿Por qué cada uno construye su propio Harness? Si todos usáramos el mismo linter y las mismas herramientas de escaneo de seguridad, esto se convertiría en un componente reutilizable. Creo que esto se consolidará gradualmente en el registro de la plataforma, al igual que ocurrió con la implementación de la infraestructura en la nube.

Pero el problema es que si cualquiera puede agregar cosas al repositorio central sin restricciones, se volverá rápidamente desordenado. Por ejemplo, si alguien sube una skill, ¿quién la mantiene? Si otra persona hace una bifurcación de una skill similar, ¿cuál debería elegir? Por lo tanto, debe haber alguien que posea claramente un dominio específico y se asegure de que el elemento sea testeable y modular, permitiendo que otros amplíen la parte de escaneo de seguridad en el Context o el Harness. Debes hacerlo de forma centralizada, no simplemente pasándolo de forma aleatoria dentro de la organización.

Construir consenso es difícil. No es tan famoso como la disputa entre tabs y espacios, pero a veces se siente igual. Si intentas que dos equipos de desarrollo lleguen a un acuerdo sobre cómo trabajar, requiere una gran cantidad de comunicación y mediación. Por lo tanto, al final, es probable que no tengas solo un camino pavimentado, sino tres o cuatro, de los cuales puedan elegir. Si deciden crear su propio sistema, también pueden hacerlo, pero eso estará dentro de su propio presupuesto. El camino con mantenimiento centralizado es el “camino fácil”, diseñado para atraer a todos hacia él.

Si la gente usa ciegamente estas capacidades compartidas, debes hacerles ver los costos. Tan pronto como visualices los gastos, ellos mismos buscarán optimizarlos. Es responsabilidad del equipo de la plataforma hacer que los gastos sean transparentes: ¿cuánto se gastó? ¿Cuánto ayudó? Si puedo reducir el número de iteraciones del Agente, eso es una optimización. Pero si no veo esta métrica y solo veo el resultado final, no puedo actuar; la visualización es la base de toda optimización.

Entonces, mi afirmación central es: debemos pasar de desarrolladores que trabajan de forma aislada a un nivel de equipo con contexto y componentes compartidos, y finalmente a un "sistema de juego multijugador" dentro de toda la organización. El efecto multiplicador explotará allí, porque tendrás una rueda de impulso en la que las mejoras pueden irradiarse simultáneamente en múltiples direcciones.

En el siguiente nivel, ¿cómo piensa el VP de Ingeniería sobre esto? Puedo predecir aproximadamente la historia que ocurrirá en su organización: un hackathon o una sesión de almuerzo informativa, compartir casos de éxito, crear un canal compartido en Slack, implementar un programa de campeones. Todos son tácticas genéricas de transformación. Así se hizo durante la transformación Agile, así se hizo con DevOps, nada nuevo bajo el sol.

Por otro lado, también sabemos que la estrategia de “emitir licencias, organizar capacitaciones, permitir que todos actúen libremente y hacer que mil flores florezcan” nunca ha tenido éxito. El resultado de mil flores suele ser mil malas hierbas: flores que se despliegan pero ninguna da fruto. Por eso abogo por que, desde el lado organizacional, se otorgue autorización clara a los Lead de equipo y al equipo de plataforma para que lleven a cabo esta tarea. No se trata de algo que un solo individuo sobresaliente pueda lograr por sí solo; debe haber alguien formalmente autorizado para impulsarlo.

Buscar ayuda también es un dolor de cabeza. Los títulos de puestos actuales son un desastre: ingeniero de producto de IA, ingeniero desplegado hacia adelante, ingeniero agente, ingeniero de IA... Estos términos en realidad no tienen significado sustancial. No puedes juzgar la madurez de una persona por su título, porque toda la industria aún no es madura. Sin embargo, al publicar una oferta de empleo, estos términos sí generan ciertas señales y atraen a personas con intención de postularse, pero en sí mismos no garantizan que el candidato posea las habilidades correspondientes. También he escuchado historias aún más extrañas: algunos candidatos usan IA en sus auriculares para recibir respuestas en tiempo real durante las entrevistas; cuando el entrevistador hace una pregunta, la sugerencia de la IA llega directamente a los AirPods.

Entonces he escuchado que cada vez más empresas adoptan este tipo de entrevista. En el primer paso, se les da un ejercicio para que resuelvan utilizando IA sin restricciones, aprovechándola al máximo. Si la IA les ayuda a resolverlo, eso justamente demuestra que son hábiles para utilizarla. En la segunda etapa, se les pide que revisen su solución y expliquen: “¿Por qué elegiste esta aproximación? ¿Cómo validaste que era correcta?”. En este momento, estás evaluando su capacidad de prueba y su juicio técnico. La primera parte prueba la habilidad para utilizar IA; la segunda, la solidez técnica. Por último, también debes observar cómo colaboran: si están dispuestos a compartir o si prefieren trabajar solos. Algunas personas tienen gran habilidad técnica pero quieren controlar todo por sí mismas; en la era de los Agentes, este tipo de personas puede convertirse en un cuello de botella.

La persona que buscas es aquella que combina estas tres cosas: utilizar el AI al máximo, tener una sólida base en ingeniería y estar dispuesta a compartir y colaborar. No se trata de alguien que solo haya estudiado ML o AI, ni de un experto en descifrado, sino de una mezcla específica. Es probable que no encuentres a alguien que cumpla perfectamente con las tres, y no importa: por ejemplo, un candidato podría ser extremadamente fuerte en un área pero necesitar orientación en otra. Además, no mezcles estas habilidades etiquetándolas como “principiante” o “avanzado”; son dimensiones distintas de habilidades, y una persona puede tener una capacidad de uso de AI “avanzada” pero una disposición a colaborar “principiante”.

El departamento de ingeniería aún debe rendir cuentas a la dirección. Compramos tantas licencias, ¿podemos demostrar el retorno de la inversión? ¿La entrega se aceleró? Podría haber promesas, pero es difícil probarlo. ¿La calidad mejoró? También es difícil afirmarlo. Pero volviendo a los dos indicadores que mencioné antes, puedes mostrar cuánto se redujeron los intentos de intervención, cuánto se mejoraron y cuánto aumentó la tasa de reutilización. Esto es mucho más fácil y convincente que comparar la productividad de codificación “con y sin Agent”.

Entonces, cuando alguien se queje de que el Agente gasta demasiado y proponga limitar el presupuesto, tu reacción instintiva no debería ser “eliminemos todos los gastos”, sino “cómo podemos optimizar los gastos”. La forma más sencilla es elegir el modelo adecuado: no todas las tareas requieren el modelo más potente; algunas pueden resolverse perfectamente con modelos más económicos. Educa a los desarrolladores sobre qué modelo usar en cada escenario, y, además, proporcionales mejores Contextos y Harnesses; esto ayudará al Agente a evitar caminos erróneos y reducirá drásticamente los costos.

También hay un tema sobre el tamaño del equipo. Que una sola persona versátil haga todo es el sueño final. Pero si lo analizas detenidamente: esa persona generalmente necesita complementarse con habilidades complementarias, como un product manager o un diseñador. Luego debes considerar personal de respaldo (backup), ¿qué pasa si alguien se toma vacaciones? Ya vuelves a tener tres personas. Después, quizás necesites a alguien que supervise la producción y los tickets; si eres extremadamente eficiente, podría ser la misma gente haciendo ambas cosas a tiempo parcial. Pero tan pronto como empiezas a arreglar bugs, la velocidad con la que implementas nuevas características disminuye. Y luego están los nuevos miembros: debes guiarlos para que entiendan qué significa “bueno”. Por eso sigo creyendo que, dentro de una organización, no es posible realmente reducir cada equipo a una o dos personas.

Finalmente, la fábrica oscura podría no estar completamente oscura, sino que conservar cierta luz tenue (dim factory), lo que significa que debes decidir qué nivel de riesgo asumir para cada función, ya que no todas las funciones son adecuadas para una autonomía total. Puedes invertir más en auditoría, como rastrear quién modificó el código: ¿una persona o un agente? Añadir validadores para verificar si el código realmente es útil, e invertir en capacidad de contexto cuando los procesos automáticos fallen. Desde una microgestión completa (cada línea de código revisada por una persona) hasta una aprobación completamente autónoma (asumiendo que todos los resultados del agente son correctos), existe todo un espectro. Lo que debes hacer es seleccionar el nivel de automatización adecuado para cada tipo de cambio según su nivel de riesgo.

Y creo que tu ventaja competitiva radica en capturar el conocimiento acumulado, esos contextos empresariales que ahora inyectas en Skill, Context e incluso en las restricciones de Harness. Para mí, esto lleva la entrega continua hacia el aprendizaje continuo. Pregúntate: ¿qué tan rápido podemos introducir una nueva cosa en el sistema y retirar una antigua? Esa es tu capacidad de reacción. Si puedes mejorar continuamente esta capacidad, la cuestión clave ya no será “quiero hacer que todo el sistema sea más confiable”, sino “¿puedo mantener su confiabilidad mientras cambio cada vez más partes del sistema?”.

Si solo te llevas una frase, debería ser: Los ganadores no serán los jugadores supersolitarios, sino aquellos que saben cómo mejorar las organizaciones en múltiples niveles.