Raif Agentic Development: transformación de IA del desarrollo en Raiffeisenbank

Hola a todos. Me llamo Andrey Usavka. Dirijo el área de desarrollo de financiación del negocio corporativo en Raiffeisenbank.

Mi foco principal ahora es la transformación de IA de nuestra unidad de negocio.

Esto implica rediseñar los procesos de producción y operativos. Esto implica comprender qué tecnologías debemos implementar y dónde, cómo revisar la estructura y el contenido de los roles, y muchas otras cosas que necesitamos hacer para alcanzar los ambiciosos objetivos de los que hablaré un poco más adelante.

Tres ideas clave que quiero que se lleven de este encuentro.

• La primera es que, la mayoría de las veces, no hace falta implementar IA en los procesos existentes; hay que reconstruir los procesos en torno a la IA.
• La segunda es el dilema de Output y Outcome. Se trata de cómo elegir objetivos que los impulsen a rediseñar los procesos existentes.
• Y la tercera es el error del agente. No es motivo para terminar manualmente el trabajo por él. Es motivo para ajustar más el sistema.

¿Cómo es la implementación típica de tecnologías GenAI en 2025–2026?

La mayoría de las veces tomamos, por ejemplo, un equipo de desarrollo de producto y damos a cada rol su propio agente de IA.

• El product manager obtiene ChatVRD,
• el backender obtiene Codex o Claude, y cada rol ve de inmediato que puede generar un Output multiplicativamente mayor por unidad de tiempo. El product manager tendrá muchas más specs por esa unidad de tiempo; el backender, mucho más código. Y parece que cada paso se ha acelerado.

Pero las aceleraciones locales no se suman para producir un efecto que perciba el negocio, que perciba el cliente. ¿Por qué sucede esto? Porque entre roles, entre personas, existen colas, esperas y transferencias que distorsionan y pierden parte de la información, y llevan a retrabajo. Y por eso nuestra eficiencia global no crece.

Si miramos las estadísticas macroeconómicas, podemos ver que la producción por hora aumenta, mientras que la productividad total, que es esencialmente la eficiencia por encima del capital y las personas añadidos, crece aproximadamente en la zona cero, al nivel de los años previos a la crisis. Y a finales de los años 80 del siglo pasado, el economista Robert Solow observó que la era informática se veía en todas partes salvo en las estadísticas de productividad laboral. Así apareció la paradoja de Solow, y ahora estamos observando, en esencia, su segunda reencarnación.

Es interesante examinar uno de los casos de ingeniería de procesos también de principios de los años 90 del siglo pasado. IBM Credit, financiación de compras para clientes de IBM. Un proceso crediticio clásico: registro de una solicitud de crédito, análisis crediticio, establecimiento de condiciones, etcétera. Varios departamentos, varios roles clave. En consecuencia, los investigadores analizaron cuánto trabajo real, sumado entre todos los empleados, se realiza durante ese proceso. Resultó ser apenas una hora y media. Sin embargo, el cliente espera 144 horas desde la presentación de la solicitud hasta recibir el resultado. Es casi una semana. Y resultó que, si se aceleraba dos veces a cada empleado, el ahorro para el cliente sería de apenas 45 minutos, lo cual, estarán de acuerdo, es insignificante frente a 144 horas. Y, en general, uno de los investigadores que trabajó en este caso formuló una idea interesante: se intenta automatizar con computadoras procesos que simplemente deberían abolirse y someterse a un rediseño total, total. Y, en general, en IBM Credit lograron hacerlo incluso sin computadoras. Allí, esencialmente, todos los roles implicados en el proceso se redujeron a uno solo. Aquí aludo al product engineer de la reunión anterior. Y, en general, esto hizo que 144 horas se convirtieran en 4 horas para el cliente.

De aquí se desprende que la unidad de transformación de IA no es un empleado, ni un rol, ni un agente. La unidad de transformación es un proceso end-to-end en torno a un resultado medible. ¿Qué posibilidades tenemos ahora, en comparación con los años 90 del siglo pasado? Además de lo obvio, que es que han ocurrido muchas iteraciones de la revolución informática, podemos observar que cualquier proceso de negocio en cualquier empresa es, en esencia, un viaje de información entre nodos de toma de decisiones. Una parte de ellos es software clásico estándar; otra parte son personas.

¿Por qué personas? Porque antes solo una persona era capaz de recibir información no estructurada, aplicar su experiencia y algún conocimiento acumulado que no está digitalizado en ninguna parte, y obtener una decisión.

Con la aparición de los grandes modelos de lenguaje, también se ha hecho posible automatizar esos nodos de toma de decisiones, porque los LLM realizan bastante bien este trabajo. Y por ello ahora tenemos la posibilidad de transformar procesos de negocio no solo con ayuda de la IA, sino también en torno a la IA.

Sin embargo, surge una pregunta: ¿cómo sabremos que la transformación que llevamos a cabo es efectiva y útil? Aquí recordaré el clásico dilema de gestión entre output y outcome. ¿Cuál es la diferencia? Output son determinados indicadores, evidencias de que el trabajo está avanzando. Pueden ser sensaciones subjetivas de aceleración tras recibir un agente de IA. Puede ser el número de merge requests, pull requests, líneas de código escritas por el agente. Todo esto es necesario como condición de que el trabajo se esté realizando, pero no garantiza que el trabajo realizado sea útil y genere un efecto útil para el cliente. Por otro lado, outcome es precisamente el efecto que buscamos obtener, por ejemplo, cuando escribimos código. Son ciertos cambios que percibe nuestro cliente. A menudo este dilema se manifiesta al establecer un objetivo de la siguiente manera. Se puede ver que un equipo o una empresa entera se fija como objetivo implementar IA en todos los equipos. O, por ejemplo, construir un harness, construir una plataforma o añadir tal o cual capacidad a nuestra oferta de plataforma. ¿A qué lleva esto? Lleva a que efectivamente se implementó IA en todos los equipos, efectivamente se construyeron la plataforma, el harness, etcétera. Sin embargo, qué efectos produjo esto más allá de que construimos algo, la mayoría de las veces no está claro. La mayoría de las veces las métricas de negocio permanecen en el mismo nivel que antes de la construcción correspondiente.

Pero un objetivo de outcome se formula de otra manera. Por ejemplo, podemos decir que queremos que cualquier cambio, cualquier feature que solicita el cliente, el cliente la reciba en menos de 24 horas. Ese es el outcome al que, por ejemplo, apuntan nuestros equipos y nuestra empresa. Queremos que cualquier cambio que el cliente necesite pueda recibirlo en menos de 24 horas. Pero además, queremos que ese cambio se implemente de forma autónoma, sin participación de personas. Y queremos que la calidad y la fiabilidad no se resientan.

Calculamos nuestro time to market en la etapa actual, de manera simplificada, desde la creación de la tarea en Jira hasta el aterrizaje del cambio correspondiente en producción. Esto implica que este tramo del recorrido cubre parte del proceso de discovery. Sin embargo, una parte significativa del proceso de discovery sigue quedando fuera de esta medición. Nos centraremos en ella más bien después de automatizar por completo todo nuestro delivery pipeline. Y aquí tenemos buenos resultados en automatización. En particular, como resultado del rediseño de nuestro proceso de desarrollo, logramos reducir la mediana del time to market 36 veces y el percentil 85 más de 40 veces. Y ahora ya más del 50% de las tareas se realizan de forma autónoma en menos de 24 horas, y el 85% de todo el desarrollo de producto dentro del área de financiación pasa por el pipeline agéntico.

Llegamos a esto durante bastante tiempo, en mi opinión. Se puede ver en este gráfico. Por cierto, aquí la escala es logarítmica. Ya en 2025 teníamos acceso a modelos avanzados, teníamos agentes de IA. Sin embargo, como se puede ver, esto no llevaba a que nuestro time to market disminuyera radicalmente. Hasta agosto fue, esencialmente, una flatline. Y en agosto ocurrió algo, y nuestro time to market disminuyó dramáticamente.

Se puede observar una correlación con el gráfico de abajo: desde agosto aumentó bruscamente la proporción de tareas realizadas por el pipeline agéntico, y continúa creciendo. Espero que a final de año llegue al 100%. Uno puede preguntarse: quizá compramos velocidad a costa de la calidad o de que comenzamos a trocear las tareas de una forma especial. Sin embargo, no es así. Tenemos contramétricas para nuestro time to market. Por supuesto, también vigilamos la calidad, la fiabilidad y cómo se trocean nuestras tareas. Y es importante notar aquí que nuestro defect rate se mantiene aproximadamente al mismo nivel que antes. Los rollbacks y hotfixes incluso se redujeron dos veces. Desde el punto de vista del tamaño de los cambios, se puede medir, por ejemplo, en archivos, líneas de código, etcétera. Vemos que estas métricas también permanecen aproximadamente al mismo nivel que antes de implementar el pipeline agéntico.

Para entender qué sucedió tan importante para nosotros en agosto, por qué se produjo un efecto tan dramático, hay que explicar cómo vemos el concepto de harness y qué tipos existen para nosotros. A nivel global, de alto nivel, los dividimos, por ejemplo, en dos tipos. Son inner harness y outer harness. Inner harness es, en esencia, OpenCode, Codex, Claude Code, etcétera. Todo lo que pueden descargar, comprar, instalar localmente y usar.

Outer harness es algo que convierte a muchos agentes en un sistema de producción, en desarrollo industrial. ¿Qué es desarrollo industrial? Son prácticas de ingeniería, estilo, calidad, security, reliability. Es todo aquello que define cómo se acostumbra en su empresa a abordar el proceso de desarrollo. Esa experiencia no se puede comprar ni instalar. La tienen ustedes, y solo ustedes saben cómo debe funcionar para ustedes. Y nuestro outer harness, lo llamamos Atomic, implementa esencialmente toda esa experiencia como un proceso ejecutable. Es decir, no es un conjunto de handbooks, instrucciones, etcétera. Todo forma parte de una única máquina en movimiento. Y esta máquina, este outer harness, implementa esencialmente un contrato de producción. El contrato de producción son las respuestas a cinco preguntas clave:

• Quién establece el objetivo,
• cuáles son los límites de la autonomía,
• qué verificaciones son obligatorias durante el proceso y cómo se ejecutan,
• cuál es nuestra definition of done y, propiamente,
• cómo abordamos, cómo reaccionamos ante los errores que surgen durante la operación.

A continuación hablaré con más detalle de cada una de estas preguntas. Para nosotros, uno de los cambios clave es que sustituimos todos los roles especializados que teníamos en los equipos por un único rol de ingeniería. Es el product engineer.

Antes teníamos backenders, frontenders; hacía bastante tiempo que ya no teníamos testers ni analistas, pero, en principio, con la aparición de los LLM se hizo evidente que cualquier ingeniero puede ser generalista si posee suficiente experiencia de ingeniería y, como mínimo, en la parte de computer science. El product manager establece el objetivo. En esencia, esto significa que dice para quién y por qué lo hacemos, qué métrica queremos mover. Y el product engineer toma esa intención aportada por el product manager y, junto con el agente, la convierte en una especificación, la entrega al sistema agéntico para su implementación y realiza su aceptación. Multiplicamos la escala de nuestro ingeniero. Es decir, si antes, por ejemplo, dábamos a nuestro ingeniero backend Codex o Claude Code, se convertía, por así decirlo, en un ensamblador dotado de una potente herramienta eléctrica en una línea de producción, que junto con esa herramienta eléctrica realiza el ensamblaje de grandes módulos del producto final. Es decir, si le ocurre algo o si queremos escalar de alguna manera este proceso, seguimos encontrando un bottleneck que es la persona. En contraste, nuestro product engineer se centra en desarrollar y mejorar ese pipeline. Es decir, construye y mejora guardrails, define límites y reglas de aceptación, analiza casos nuevos y excepcionales, entrena al sistema.

¿Cómo tratamos las especificaciones y cómo establecemos en general objetivos para el sistema agéntico? Aquí nuestro enfoque de las especificaciones es que deben reducir la incertidumbre de la intención, no describir el plan de implementación. Probamos specs descriptivas, pero no nos funcionaron. Probamos diferentes especificaciones en el framework SDD, especificaciones en el framework de development driven. Sin embargo, al final llegamos a una versión bastante ligera, en la que contamos con un sistema mediante el cual el product manager y los ingenieros interactúan en la etapa de planteamiento de la tarea. En general, pasan mediante autocontrol. Tiene aproximadamente el siguiente aspecto. El product manager llega a un determinado chat con el agente. El agente tiene acceso al monorepositorio de producto. Y, en consecuencia, cuando la persona dice «quiero hacer tal feature», el agente tiene la posibilidad de comparar su intención con lo que ya funciona realmente como código ejecutable. Necesita mucho menos tiempo para construir cierto modelo del mundo. Después el product manager responde una serie de preguntas, da determinados comentarios, tras lo cual aparece una especificación de intención. Después toma el trabajo el product engineer y, nuevamente junto con el agente, diseña una solución de diseño. En gran medida, esto también se reduce a responder una serie de preguntas, dar algunas observaciones correctivas si es necesario y obtener como resultado un documento de diseño de producto. El documento de diseño no detalla qué archivos hay que cambiar, qué funciones hay que añadir, etcétera. No creemos en eso. Creemos que, en esencia, hay que establecer para el agente un goal claro, un objetivo claro, para el cual el agente pueda hacer Kill Clearance. Es decir, aquí están los requisitos funcionales, los requisitos no funcionales y los criterios de aceptación.

La propiedad, el acuerdo probablemente más importante, que nos permitió impulsar multiplicativamente nuestro time-to-market, es el acuerdo sobre cómo es nuestra definition of done.

Para nosotros, todo el código de producto típico debe escribirlo el agente. Si una persona commitea algo en un merge request que hizo el agente o hace el trabajo manualmente, en esencia deteriora nuestras métricas de rendimiento. Por eso tenemos determinados incentivos para que todo el trabajo lo realice el agente. Durante el diseño del pipeline agéntico tuvimos muchos intentos diferentes. Creo que construimos alrededor de cuatro versiones fallidas del pipeline y aprendimos varias lecciones. Una de las lecciones es que los pipelines SDLC basados en roles no funcionan. No funcionan, en mi opinión, tampoco en el desarrollo clásico con personas, y funcionan mal también en el desarrollo agéntico.

Parecía muy tentadora la idea de construir un pipeline con un planificador, un ejecutor, un tester, todo tipo de críticos, etcétera. Resultó que un pipeline así funciona mucho peor que un sistema monoagente. Aquí nuestra experiencia se correlaciona con una investigación de Google que estableció que, en tareas secuenciales, los sistemas multiagente dan peores resultados que los sistemas monoagente. Nosotros lo formulamos como «es importante asegurar continuidad cognitiva para el agente», para que pueda, como una persona, avanzar de forma bastante no lineal durante la implementación de una tarea, para que no tenga restricciones rígidas impuestas por una u otra etapa o por una máscara de rol concreta. Es decir, puede explorar el código, puede escribir código, ejecutar pruebas en cualquier orden, interactuar con el entorno, encontrar omisiones en el diseño. E incluso, en principio, lo entrenamos para que, si encuentra un defecto crítico en el establecimiento del objetivo o durante su intento, no trate de llevarlo a término a cualquier precio, sino que más bien se rinda y diga: «he fallado». Y así tenemos la posibilidad de eliminar el defecto crítico.

A alto nivel, nuestro sistema se ve de esta manera. Es decir, se puede ver que hay varias capas clave. Está la capa agéntica, que son esencialmente esas partes de Inner Harness. Hay un agente responsable del planteamiento de la tarea. Hay un agente responsable de la ejecución. Esta es la mayor parte precisamente de este componente Harness. Hay un agente Refine, cuya tarea es encontrar puntos de mejora en el estrato histórico de traces, comentarios, etcétera. Y tenemos una parte enorme, incomparablemente mayor. Es código determinista, lo llamo «sistema». Código clásico de Python. Allí existe, por ejemplo, una entidad como el controlador, responsable de muchísimas cosas muy importantes. Por ejemplo, se asegura de que el agente ejecutor realmente haya pasado, haya realizado todas las verificaciones de calidad que declara haber superado. Es decir, este sistema investiga las evidencias de trabajo que quedan tras el agente. Este sistema es responsable de la recuperación ante errores. Por ejemplo, parpadeó algún componente de infraestructura o, no sé, se cayó todo el sistema. En ese caso no perdemos el state ni el progreso acumulado. Nos recuperamos aproximadamente desde el punto donde fallamos. Esta misma parte es responsable de los presupuestos de error, del self-healing y de muchas otras cosas. Nuestro agente no crea ningún MR por sí mismo. Eso lo hace, de nuevo, un componente determinista. Es decir, en principio podemos ver que el sistema es una superestructura determinista sobre un componente estocástico no determinista. No creemos al agente simplemente por su palabra. A pesar de que el agente tiene la posibilidad de ejecutar todos los tipos posibles de pruebas que hay en el proyecto, ejecutar linters, checks, etcétera, estas verificaciones se volverán a ejecutar adicionalmente durante el pipeline CI/CD y por el propio controlador incluso antes de que se cree el merge request. Es decir, aquí intentamos, antes de entregar el cambio como merge request a revisión humana, realizar todas las verificaciones automatizadas que tenemos disponibles. Y al final tenemos la revisión. Y, naturalmente, cuando impulsamos de forma tan multiplicativa el rendimiento de nuestro pipeline, tenemos mucho más código que revisar. Y está claro que el foco de los ingenieros se desplaza a asegurar esa revisión.

Y se vuelve imposible revisar tales volúmenes de código de la manera anterior. Por eso nuestros ingenieros no se centran en revisar el diff en sí. Añadimos una capa que convierte estos diffs en un conjunto de decisiones que tomó el agente durante el proceso. Es decir, esencialmente un informe con algunas visualizaciones, tal vez, que una persona puede revisar. Si lo necesita, profundizará y verá el diff concreto. Pero, en principio, la revisión del diff directamente también la realiza nuestro sistema agéntico.

Así se ve nuestro dashboard operativo, con el que nuestro equipo empieza y termina el día. Aquí se ve que ya más de 900 tareas en agosto pasaron por el sistema agéntico. Es una captura de pantalla bastante antigua. En realidad hay bastante más de mil. Y tenemos un success rate acumulado de alrededor del 70%. Esto es para un período de 90 días. Aquí se ve una métrica importante: aceptación a la primera. Pass at one, 31%. Es, en esencia, la proporción de tareas en las que el agente resolvió de manera perfecta, de modo que el revisor no encontró sobre qué dejar comentarios y simplemente aceptó la solución. Esta proporción está creciendo. ¿Qué nos ayuda en general a asegurar, por así decirlo, el crecimiento de las métricas clave para nosotros? Varios cambios clave en los procesos. Por ejemplo, antes era habitual que guardáramos servicios, frontends, pruebas, etcétera, en repositorios separados. Bueno, así se había formado históricamente. Por ello, cuando hay que hacer una feature, hay que hacer varios merge requests y orquestar la incorporación de esos merge requests en los masters correspondientes y el deploy. Pasamos al concepto de monorepositorio. Es decir, tomamos un contexto de producto acotado y reunimos todos sus servicios, frontends, pruebas, wikis, lo que sea, en un único monorepositorio. Esto nos permite, en primer lugar, añadir cualquier cambio de feature, cualquier feature nueva a este producto, a esta área de producto, con un solo merge request. Y, en segundo lugar, permite al agente, durante la investigación, el análisis y la ejecución, tener acceso al contexto más amplio posible para entregar soluciones de calidad, para comprender con qué mundo, con qué entorno trabaja.

Una de las lecciones más importantes que aprendimos de toda nuestra construcción de Harness es que la optimización prematura es el mal. No hay que intentar, en las etapas iniciales, cuando construyen el pipeline, ahorrar en minucias, ahorrar tokens, dólares, etcétera. Por desgracia, esto lleva a que simplemente desperdicien sus recursos. Empezamos, por supuesto, dándonos ese golpe. Empezamos tomando un modelo débil e intentando construir a su alrededor un Harness demasiado sofisticado que lo empujara en la dirección que queríamos. Y luchábamos contra una entropía que desapareció por sí sola, literalmente unos meses después, al lanzarse la siguiente versión del modelo de la misma familia. Es decir, simplemente gastamos muchos recursos en construir soluciones improvisadas que descartamos de inmediato. En general, desde entonces tratamos de no cometer esos errores. Tomamos una base de componentes preparada. Son frameworks agénticos; en nuestro caso, el ecosistema LangChain. Herramientas preparadas para workflow management. Observability tools, LLM gateways. Con ellas ensamblamos y modelamos nuestro proceso Outer Harness. Modelamos con estos bloques nuestro proceso interno de producción, que naturalmente no podemos tomar ya preparado y comprar.

Otra lección importante aquí es cómo inculcar en el equipo una mentalidad tal que, si el agente se equivocó o no logró resolver algo, no tengas el deseo de hacer el trabajo manualmente por él. Este deseo surge de forma natural, especialmente cuando el agente no resuelve alguna tarea muy sencilla; es decir, hizo una tarea compleja y se atascó en una pequeña, y naturalmente parece que ahora la terminaré manualmente y listo. Ese instinto, por supuesto, es totalmente poco constructivo, porque lleva a que el problema no se resuelva de forma sistémica. La solución sistémica consiste en preguntarse: ¿qué puedo cambiar en el contexto de producto, qué conocimiento, qué información, qué verificación puedo dar al agente para que la próxima vez razone como yo y aplique la misma solución que yo? Por eso también miramos a través de esta lente lo que sucede en la revisión. Naturalmente, los ingenieros revisan el código con bastante atención, sobre todo en las primeras etapas de introducción del pipeline agéntico, y encuentran muchísimas observaciones.

El agente suele ser verboso, suele hacer pruebas que comprueban más la forma que el contenido; comprueban la forma, no el comportamiento. Y tales pruebas, por sí solas, tienen un valor muy bajo. Y para solucionar este problema de una manera sistémica, desarrollamos un ciclo autónomo de auto-mejora. Se lanza cada cierto período, lee todos los comentarios de desarrolladores previamente no revisados sobre MR en el monorepo de producto y luego el agente analiza, intenta identificar algunos episodios típicos recurrentes y formular hipótesis sobre cómo podría solucionarse esto de forma sistémica. Después de formular estas hipótesis, propone en forma de merge request cambios en el monorepo de producto, en el monorepo del propio pipeline agéntico, si, por ejemplo, parece que el problema puede solucionarse modificando el prompt del sistema.

Ya se formularon y aceptaron por el equipo más de 60 propuestas de este tipo, y esto llevó a un crecimiento bastante agradable de la métrica de resolución al primer intento.

Para que la velocidad de entrega se convierta en la norma, es necesario centrarse en cuatro áreas clave.

• La primera y probablemente una de las dos más importantes es la calidad del planteamiento en upstream. Es decir, con qué planteamiento, con qué nivel de incertidumbre llega la tarea al agente para ser trabajada. Aquí es importante eliminar toda incertidumbre significativa en la etapa inicial.
• La segunda es un entorno de verificación estable, un entorno estable en el que trabaja el agente. Es necesario que las pruebas no sean flaky, que la infraestructura no parpadee, que haya capacidad de mockear las dependencias, etcétera. Es decir, en principio, todas las prácticas estándar de ingeniería son aplicables aquí.
• La tercera: el agente no puede leer sus pensamientos. Por ello, los acuerdos del equipo no deben vivir en las cabezas de las personas, sino que deberían migrar, por ejemplo, a skills, prompts, a algo a lo que el agente pueda acceder y que use como guía al resolver.
• La cuarta: todas las verificaciones que sean posibles deben integrarse en el proceso. Las verificaciones deterministas son extremadamente importantes. Las prácticas clásicas de ingeniería nos ayudan a establecer límites adecuados entre productos, entre sistemas. Aquí el domain-driven design funciona bien. Hay que tener un nivel bastante alto de cobertura con pruebas de integración, unit tests, etcétera. Conectar análisis estático, etcétera.

Es decir, todo esto les permite ampliar gradualmente la autonomía del agente, porque la autonomía del agente no se amplía por fe, sino gracias a que tienen la posibilidad de verificar automática y autónomamente la calidad de su trabajo. Si pensamos por qué transformaciones como la que ocurre con nosotros pueden estancarse a menudo, es sencillo: de una forma u otra, todo se reduce a la persona. Es obvio que cualquier ingeniero, incluido yo, nos apegamos al modo de trabajo que dominamos durante años. Me gusta escribir código, no me gusta entregar el trabajo a los agentes. Y de una manera u otra esta resistencia surge en cada uno de nosotros.

Creo que la manera de solucionarlo aquí se reduce a trabajar con la mentalidad del equipo, a trabajar en la implicación del equipo en los cambios que les parecen estratégicamente importantes. Y, naturalmente, al nivel de definition of done también pueden decir que el trabajo se considera aceptado únicamente si lo hizo el agente. No hace falta ir full-in; pueden aplicar un cambio así en una zona bastante limitada. Por ejemplo, empezamos esta transformación haciendo que un equipo concreto de cinco pasara completamente a la nueva forma de trabajar.

Es importante que exista precisamente un elemento completo de transformación, que no haya algo como: esta parte del trabajo la haré con agentes y esta otra parte la haré como antes. Si les queda esa opcionalidad, esa opcionalidad siempre se realizará en perjuicio de la transformación. En gran parte porque las personas temen los errores y, en mi opinión, los errores, primero, son inevitables durante esta transformación, y, segundo, son necesarios, porque gracias a esos errores el sistema acaba aprendiendo.

Por eso, las decisiones clave que debe tomar un líder durante una transformación así son, primero, formular el objetivo como outcome, es decir, como algo que el cliente pueda percibir, que pueda sentir. Formular para ese objetivo una ambición tal que sea simplemente inalcanzable con la forma antigua de trabajar. Revisar la estructura de personal, es decir, qué roles tienen en el equipo, si no tienen una cadena de roles, transferencias entre distintas etapas. Si la tienen, es mejor hacer que haya un único propietario de los cambios en el proceso. Hay que trabajar para que aparezca un control automatizado, para que todas las verificaciones estén integradas y automatizadas en los procesos. Y eliminar la trampa de la demo. Llamo así a la situación en la que el equipo se presenta ante management con una bonita demostración de un agente que realiza el trabajo autónomamente, maqueta una presentación, escribe código, etcétera, y luego miras cómo trabaja el equipo y todo ocurre igual que antes, con tracción manual. Esta trampa de la demo debe eliminarse. Y, probablemente, uno de los puntos importantes que nos funcionó bien es que toman su métrica North Star, para nosotros es Time to Market, y distintos componentes de ella, la ponen en un dashboard que siguen literalmente en tiempo real y empiezan cada día laborable con ese dashboard.

Aquí creo que el líder es responsable de la estrategia y hace una apuesta estratégica. Pero sin que el equipo compre esa estrategia, la entienda y comparta sus valores, esta transformación no funcionará. Porque precisamente el equipo determina de qué manera concreta llegaremos al objetivo. Por eso, para terminar, quisiera recordar la lección principal de los años 90: antes las personas intentaban automatizar con tecnologías informáticas procesos que deberían haber abolido y rediseñado por completo. Ahora, la mayoría de las veces, utilizamos la inteligencia artificial exactamente de la misma manera y, por supuesto, tendemos a buscar píldoras mágicas, herramientas que se puedan descargar, instalar y obtener la solución a todos nuestros problemas. No existen tales herramientas; habrá que tragarse la píldora amarga y emprender el difícil trabajo de rediseñar los procesos existentes. Y para empezar de una manera clara, recomendaría elegir aquel proceso sin el cual ya es imposible imaginar el trabajo de su empresa y hacerse una pregunta sencilla: ¿cómo obtener el mismo resultado sin realizar todo este trabajo? Ese será el punto de partida para su transformación de IA. Eso es todo por mi parte. Gracias.

Q1: Escucha, Andrey, dijiste que tienes un monoagente, pero al mismo tiempo revisa una persona. ¿No existió la idea, por ejemplo, de sustituirlo por paneles, paneles orquestados de agentes independientes de diferentes modelos, para que revisaran el código? Y si revisa una persona, ¿el bottleneck no se convirtió en un nuevo bottleneck?

• Speaker 1: Bueno, sí, por supuesto, la persona se convirtió en un nuevo bottleneck, pero la persona no es nuestro único revisor. De una u otra forma tenemos un agente revisor que proporciona feedback adicional y se lo entrega primero a la persona, no al agente ejecutor, porque de lo contrario surgen loops adversariales y el trabajo puede entrar en un ciclo y no dar resultado. En cuanto a los paneles, probablemente para nosotros, primero, esto no funcionó en nuestras primeras iteraciones, cuando construíamos algunos sistemas multiagente, multirrol. No nos llevaba al resultado requerido. Y decidimos seguir el camino de añadir complejidad solo cuando esté justificada. Es decir, si vemos que el agente ejecutor no cumple con su trabajo, solo entonces añadiremos roles adicionales, etapas, etcétera.

Q2: Andrey, hablando de unidades de negocio y desarrollo agéntico, ¿a qué escala empezaron a aplicar precisamente el desarrollo agéntico? ¿A escala de qué servicios?

• Bueno, aquí probablemente intervienen varias cosas. Primero, si hablamos de la escala de nuestra unidad de negocio, son alrededor de 170 personas en total. Incluye equipos agile y soporte operativo. Si hablamos de la cantidad de servicios que el pipeline agéntico desarrolla de una forma u otra, teníamos más de 200 repositorios de producto y de servicios. Los reunimos en 10 monorepos de producto. Por eso nuestra escala es bastante grande. Todos esos servicios también se escribieron durante años. El volumen de código es colosal. Aquí probablemente no existe una respuesta universal a la pregunta de cómo dar al agente la capacidad de manejar el código. Son prácticas de ingeniería: cómo está diseñado el código, cómo están escritas las pruebas. Es, de nuevo, una cuestión de las herramientas que proporcionan al agente para explorar la base de código. Por ejemplo, hace algún tiempo, cuando teníamos modelos algo más débiles y una arquitectura un poco distinta de nuestro agente, hacíamos búsqueda semántica en el código. Es decir, lo indexábamos, etcétera. Después la abandonamos porque en la etapa actual, para los modelos actuales, ripgrep da resultados comparables y no requiere ninguna indexación upfront. Es decir, todo esto es bastante cíclico. Me parece que la cuestión es más bien que hay que probar cosas diferentes. Con el paso del tiempo, volver repetidamente a las prácticas que no funcionaron. Quizás funcionen en una nueva versión del modelo o del framework que usan.

Q3: ¿Hay algún ejemplo de un proceso que el agente haya desarrollado por completo? Si no es una idea.

• Bueno, probablemente no hablaré directamente aquí sobre el proceso de negocio. Tenemos muchos servicios diferentes que implementan este proceso de negocio. En esencia, nuestros equipos agile se dedican a automatizar el proceso crediticio de financiación corporativa. Allí hay cosas diferentes. Emisión de poderes, certificación, es decir, autenticación de la firma de personas autorizadas, etcétera. Es decir, hay sistemas muy distintos. Y, en gran medida, si la pregunta se reduce a qué tan complejos son los cambios que hace el agente en relación con los que hace una persona, entonces el agente hace exactamente el mismo trabajo que hacía la persona. Es decir, no tenemos algo como dejar al agente una parte del trabajo y hacer nosotros las tareas más complejas. No es así; lo tenemos simplemente escrito en la definition of done.

Q4: Hola, soy tester. Vi en la diapositiva que abandonaron las verificaciones manuales, las pruebas manuales. Y las trasladaron a autotests: end-to-end, integración, etcétera. Me interesa cómo determinan ahora la escala necesaria de validación y verificación. Suena en un contexto extremadamente radical, como si tuvieran muchísimos end-to-end para cada corner case. ¿Cómo lo resuelven?

• Tuvimos algún trabajo preparatorio para preparar la pirámide de pruebas, para asegurar una pirámide de pruebas óptima para nuestros proyectos. Nos ocupamos de ello durante todo 2025, incluso antes de implementar agentes de forma masiva. En el momento en que llegamos a los product engineers, etcétera, se nos hizo evidente que necesitábamos unificar de algún modo las prácticas de pruebas. Por eso aquí se realizó cierto trabajo preparatorio. Decir que existe un enfoque científico que permita entender que tal proporción de pruebas end-to-end, tal proporción de pruebas UI, tal proporción de unit tests hará que todo esté bien, no conozco tal enfoque. Aquí actuamos más bien históricamente. De una u otra forma la persona permanece, y en la etapa actual una proporción significativa de usuarios de nuestros sistemas son personas. Y aun así, la persona como product engineer revisa estos MR. Todavía no hemos pasado el punto en que sea físicamente imposible hacerlo. Por eso, de una u otra forma, probablemente tanto con los ojos como mediante el feedback de los usuarios, que pueden proporcionarnos directamente en chats, además de a través de algunos SDK, etcétera, vemos si existen señales que indiquen que se produjo una caída de calidad. Hasta ahora no tenemos esas señales.

Q5: Ajá, entonces, ¿entiendo correctamente que a nivel de equipo se decide que quien revisa MR individuales mira y comprueba qué tipo de pruebas se escribieron, que todas resuelvan suficientemente bien, respectivamente, la intención de negocio planteada inicialmente?

• Bueno, de forma muy condicional, sí. Y es la misma persona que, en principio, aprobó el diseño de producto de esa intención de negocio. Es decir, no tenemos una separación en la que una persona aprueba el diseño de producto, luego el agente lo hace y luego una tercera persona lo revisa. Abandonamos esa práctica. Ahora no tiene mucho sentido. Eso es lo primero. En segundo lugar, ya tenemos cierto conjunto de skills desarrollados, por decirlo así, prácticas de ingeniería digitalizadas en forma de skills, que recomiendan qué tipo de pruebas esperamos ver para nuestros cambios. Es decir, aquí también hemos recorrido cierto camino. Naturalmente, en la primera etapa los ingenieros miran una gran cantidad de este slop que generan los sistemas, se disgustan, dejan comentarios, reescriben skills. Es inevitable; no se puede configurar de otra manera.

Q6: Una ponencia muy interesante. Dos preguntas. Una breve y la otra para reflexionar. Hay procesos que son importantes según la letra de la ley. Compliance, diversos tipos de regulación. ¿Tienen éxitos allí o no?

• Es una gran pregunta, gracias. Aquí realmente todavía encontramos un límite. Es inevitable, nos encontraremos con la rigidez de esa parte del sistema. Cambiará más lentamente que todo lo demás. Pero, de una forma u otra, creemos que también aquí hay cierta... Primero, vemos avances entre los colegas en cuanto a cambiar, introducir algunas tecnologías aquí. Segundo, nuestra empresa es, en principio, API First. Toda nuestra interacción entre departamentos tiende en su diseño hacia API. Y creemos mucho en ello. Y, tercero, pienso que también la legislación, algunos estándares regulatorios, irán cambiando gradualmente según qué tecnologías estén disponibles y qué habiliten en términos económicos.

Q7: Ahora la pregunta difícil. En general, nos agentizamos, trasladamos nuestra mecánica de gestión del conocimiento. Uno de los problemas es el pip punto 0, cuando hay suficiente conocimiento para hacer un cambio, para dar contexto al agente. Me pareció que, cuando trasladaron todo a un monorepositorio, en realidad retiraron de la mesa la tesis de que el código es un commodity. Para ustedes se convirtió en una fuente de verdad utilizada como parte de la base de conocimientos en el contexto para que el agente haga algo. ¿Es correcta mi tesis?

• La tesis es correcta, sí.

Q8: Buenas tardes. Tengo una pregunta lacónica. En la ponencia contaron que pudieron acelerar el desarrollo varias veces o incluso decenas de veces. ¿Cómo pudieron acelerar a sus productos en cifras análogas para que prepararan los objetivos descritos sin incertidumbre y su desarrollo no se iniciara ya desde el principio? Porque su pipeline debe empezar con la misma velocidad desde el comienzo, con los product managers.

• Sí, es una gran pregunta. También hice la salvedad de que una parte del discovery está en la etapa actual. Es decir, nos centramos en delivery; una parte significativa del discovery queda por ahora fuera del alcance. El ejemplo de la interfaz que mostré es un cierto prototipo de cómo el producto planteará una tarea. Intentamos expandir gradualmente hacia la izquierda esta parte del sistema para cubrir al máximo, incluido el discovery. Por ejemplo, es obvio que aquí tuvo lugar simplemente la cualificación de la intención, para que el agente entendiera lo que quiero decir. Pero antes de que apareciera esa intención también ocurrió algún trabajo. Creemos que ese trabajo también debe suceder dentro de este sistema mediante distintos conectores: algún scouting de la coyuntura externa, análisis de clientes, etcétera. Debe suceder precisamente en esta superficie. Y todavía no hemos entrado muy profundamente ahí. Es decir, en principio, en la empresa también se trabaja en esta dirección fuera de las business units. Tenemos, por ejemplo, un acuerdo para repartir zonas de influencia y zonas de foco. Por ahora nos centramos más en la parte de delivery. Pero, de nuevo, en principio sabemos bien qué hacer. Este backlog se acumuló durante años. Primero tenemos que procesarlo.

Q9: Arquitecto TMS. Antes existía una historia en la que se generan los TMS y luego todo se automatiza. ¿Dónde queda todo eso, permanece este rastro y quién analiza después las quejas de soporte técnico y todo lo demás?

• En nuestro caso, esta responsabilidad se asume precisamente por cómo abordamos aquello de lo que es responsable un equipo en un proyecto. Nunca tuvimos esta responsabilidad estrictamente en los autotests. En cuanto a TMS, el año pasado todavía teníamos el dilema de si mantener el comp divide tml que teníamos, meter allí todo esto o no. Escribimos algunos handbooks, instrucciones, para que los ingenieros también pudieran hacerlo. Los ingenieros lo miraron, dijeron que era una tontería y lo abandonaron. Empezaron a hacer este trabajo sin TMS. En nuestro caso, no digo que sea una receta universal aplicable a todos, abandonamos tanto TMS como esta parte súper formal del trabajo del autotester. En cuanto a los testers, tenemos un dilema simple: el tester debe convertirse en product engineer.

Q10: Pero, supongamos que se forma una especificación técnica, hay una descomposición y, en general, podemos evaluar el volumen de la especificación técnica para cubrirlo con documentación de pruebas, para comprender y hablar de calidad y evaluarla también desde el punto de vista de las pruebas.

• Sí, entiendo a qué se refiere. Yo también trabajé en una empresa que tenía un enfoque waterfall, pero ahora nuestra empresa es agile, es decir, no tenemos algo como llevar, escribir y actualizar una especificación técnica. Es decir, nuestro proceso está organizado de otro modo y, en gran medida, con agentes; tenemos otro enfoque de desarrollo, no tenemos especificación técnica. Incluso ahora, cuando existe el pipeline agéntico, no escribimos una especificación técnica detallada, un cierto volumen de pruebas, testing.... Tenemos una spec. Hay una spec. Tal vez sustituye el papel que usted atribuye a la especificación técnica. Y la spec para nosotros responde a preguntas clave.. De nuevo, existen muchos formatos para llevarla; puede ser una especificación técnica, PRD, ADR, SDD y otras prácticas. Todos lo hicieron y lo hacen de manera distinta, pero tenemos una spec bastante simple: requisitos funcionales y no funcionales, non-goals, criterios de aceptación. Pero no describimos en la spec qué pruebas hay que hacer: el agente elige por sí mismo, dentro de su trayectoria de ejecución, qué hacer. En general, ahora estamos satisfechos con la elección, dado que también está escrito en los skills qué es exactamente necesario cubrir, en qué volumen, etcétera.

Q11: Tengo una última pregunta. Si la tarea es muy compleja y afecta varios productos, servicios, etcétera, es decir, debe refinarse mucho y, en general, es por sí misma proveedora de un gran backlog. En ese caso, el agente puede no ser capaz de manejar una historia tan grande, en la que hay que hacerlo todo de una vez. ¿Hace falta conectar a algún solution architect o a quien sea responsable de este rol en su caso?

• En nuestro caso los desarrolladores siempre son responsables de ese rol; no teníamos solution architects. Tenemos enterprise architects de la empresa, pero su foco está completamente en otra área. Si hablamos de cómo se resuelven solicitudes similares con nosotros, dentro del sistema que mostré existe la posibilidad de descomponer. Allí se mostró un happy pass, es decir, una tarea simple que se crea, se hace y ya está. Pero para tareas complejas existe la posibilidad de descomponer, respectivamente, dentro del delivery workflow que teníamos. Es decir, todo puede hacerse allí, porque el agente tiene acceso a todos los monorepos de producto. Es decir, si la tarea surge en la intersección de productos, puede explorar todos los productos.

Q12: Pero en ese caso debe preparar un backlog y distribuir propietarios de las soluciones dentro de su delivery. ¿Y quién debe controlar esta historia? Es decir, ¿esto es ejecución en su caso?

• El propio agente ejecuta todos estos cambios. El agente hace MRs en todos los monorepositorios de producto. De nuevo, controla todo el contexto. De una u otra manera, tenemos enfoques. Ahora cualquier harness que utilicen, Claude Code, Codex, etcétera, todos los buenos harnesses controlan todo el contexto de todo el código para entender qué hacer. Además, el contexto cambia dinámicamente: se carga algo, se descarga algo. La ventana de contexto es, en esencia, el elemento clave de estabilización en cualquier caso.

Q13: ¿Utilizan algunas herramientas, por ejemplo subagents, que realizan tareas estrechas?

• En este momento no estamos seguros. Tenemos una herramienta de subagents; habría que mirar las trayectorias, estudiar los traces para saber cuánto se utiliza activamente. Al principio nos funcionaba bastante mal. En la industria existe, en principio, una visión polarizada sobre los subagents, si soy sincero. Al principio adoptamos una polaridad: ningún subagent. Luego lo fuimos relajando gradualmente y dijimos que el agente, a su discreción, puede, por ejemplo, cargar actividades read-only a un subagent. En principio puede usarlo. No realizamos experimentos que mostraran cómo era antes y cómo pasó a ser para ver si ayuda o no ayuda.

Q14: ¿Existe en general una práctica para trabajar con tareas largas, por ejemplo, varias horas de trabajo?

• Sobre las tareas largas: no tenemos tareas largas que terminen después de más de unas horas. Es decir, siempre menos de cuatro horas.

Q15: ¿Puedo preguntar sobre las pruebas, más precisamente sobre las tecnologías de prueba? ¿Las pruebas funcionales se construyen en algún framework en el que realmente se escriben los autotests y se ubican en el monorepo? ¿O el agente toma por sí mismo, no sé, algún Playwright y lo ejecuta?

• Aun así, la mayoría de las veces se produce una mejora de algún producto existente, y en él ya hay prácticas de pruebas establecidas. No le permitimos ponerse a reinventar la rueda, tocar todos los frameworks posibles y traerlos. No tenemos eso. Teóricamente podría ocurrir. Podemos, por ejemplo, crear una tarea si entendemos durante algún análisis postmortem que nos sería útil un tipo adicional de prueba que ahora no se puede implementar dentro de los frameworks disponibles. Creamos una tarea de cobertura y después el agente, en principio, también puede resolverlo autónomamente.

Q16: El agente, tipo, si no encuentra un elemento aparte del driver: «Bueno, haz un botón en el smartphone», ¿así?

• Sí, tenemos relativamente pocas pruebas UI, están en minoría simplemente porque el proceso en sí no es UI-heavy. Hay una interfaz, por así decirlo. Algo más ligera que, convencionalmente, si fuera una interfaz front-heavy de banca móvil para un cliente retail. Aquí tendríamos que invertir bastante más en esa parte.

Q17: La pregunta es cómo es un día laboral habitual de tal ingeniero. Desde un punto de vista cotidiano. Está claro que construye esta envoltura de agentes y su valor está en construirla. ¿Solo hace eso o algo más?

• Aquí, en general, hay que decir que el product engineer como rol resultó ser para nosotros un objetivo móvil. Es decir, por ejemplo, a finales del año pasado, cuando lo implementábamos, esencialmente nos respondíamos a la pregunta: ¿es relevante el modelo de roles existente —backenders, frontenders, testers— en el mundo donde GenAI ha triunfado? Decidimos que no era relevante, que se necesitaban ingenieros generalistas que entendieran todo el stack. Y, en gran medida, los ingenieros generalistas se convirtieron en product engineers. Pensábamos que se ocuparían principalmente de escribir funcionalidad manualmente o con agentes de coding. Al final ahora nuestros ingenieros escriben muy poco código. Cuando apareció el pipeline agéntico, en gran medida dejaron de escribir código, salvo escribir el código del propio pipeline. Por eso, probablemente el 70% de su tiempo se dedica a elementos bastante clásicos de trabajo e interacción en equipo. Qué hacemos, para quién, para qué, cómo, por qué, etcétera. Después, naturalmente, el establecimiento de objetivos y la revisión consumen un foco significativo. Ahora en mayor medida, probablemente la revisión, porque el volumen de código es bastante grande. Nos esforzamos a toda costa por impulsar cambios en menos de 24 horas. Por eso es importante que dediquen más atención a la calidad de lo que reciben. En consecuencia, cuando lo hacen, dejan comentarios. Enseguida pueden ir a mejorar los proyectos y skills a partir del feedback. Enseguida pueden ir a hablar con el equipo de Harness, pensar qué capacidades se pueden dar a los agentes del pipeline. Es decir, fluctúa. Q18: Si todo funciona así, ¿deben vigilar que los cambios introducidos no rompan los proyectos anteriores?
• ¿Quieres decir que las nuevas modificaciones, los nuevos skills, no se contradigan? Sí. Entendimos que esto nos ocurre, que hay drift. Elaboramos un sistema que analiza y detecta estos drifts. Y, propiamente, esto también sucede dentro de ese ciclo de auto-mejora agéntica. Es decir, realmente encuentra contradicciones en los skills. Q19: Se producen regresiones y en una nueva tarea puedes obtener problemas que antes resolvía. ¿Y ahora comienza a degradarse?
• Es peor: pueden detectarse párrafos mutuamente excluyentes en el código del skill, porque, por ejemplo, distintas personas escribieron este skill en distintos momentos. Diferentes agentes lo analizaron desde diferentes ángulos. Ahora detectamos y corregimos esas cosas para que sean integrales. Que el skill de cierta experiencia esté digitalizado y no sea contradictorio.

Q20: Bien, tomaron y transformaron el equipo. Eliminaron los roles, convirtieron a todos en product engineers. Después resulta que hay una feature compleja. Según entendí, la descomponen por áreas de dominio. Y se cristaliza bastante finamente. Porque si doy una feature grande a un equipo, tendré en el canal un flujo de estos product engineers. Ellos mismos tendrán que ponerse de acuerdo e interactuar entre sí de alguna manera. Saldrá exactamente lo mismo que antes existía entre roles. Es decir, entre esta gran cantidad de product engineers también empezará la interacción y ocupará cierto tiempo. Porque están en el contexto de su propia área de dominio y, posiblemente, con su propio background. Es decir, ¿trocean las tareas tan finamente, luego las distribuyen entre esos cinco ingenieros de una en una, después ellos de alguna forma se comunican y al final revisan sus MRs? ¿Así funciona?

• No funciona así con nosotros. Pero, probablemente, simplemente aún no llegamos a cambios tan grandes que afectaran de inmediato a más de tres monorepos de producto, a algunos sistemas relacionados. De una u otra forma, probablemente los product managers ni siquiera llegan a nosotros en delivery con algo así. Ellos mismos intentan de alguna manera descomponer esos cambios.

Q21: ¿El trabajo se descompone para que quepa exactamente en un ingeniero? ¿Se cristaliza al mínimo?

• No se cristaliza. Es decir, tenemos un agente responsable de la planificación. Puedes llegar a él con una intención. Esta intención puede fragmentarse en partes constituyentes si parece demasiado compleja. Incluso con independencia de si es compleja o no, no podemos evaluarlo en la entrada. Más bien lo entendemos por la cantidad y composición de los repositorios, es decir, cuántas tareas de cierto nivel debe haber, por ejemplo. La mayoría de los trabajos, por diseño, suele caber dentro de los límites de un monorepositorio de producto. Si aparece algo en la intersección, es decir, un trabajo grande en varios productos, entonces se fragmentará, por ejemplo, en dos o tres tareas. El mismo ingeniero que planifica este cambio junto con el agente será responsable de ellas. Es decir, no distribuimos esto entre tres agentes. Un ingeniero es responsable de una tarea grande. Un cambio, una persona. La persona debe ser responsable end-to-end de los cambios, por grandes que sean. Pero simplemente intentamos reducir esa magnitud. Q22: Entonces debe ser una súper planificación, es decir, la tarea siempre debe ser tal que una persona pueda responder por ella end-to-end. Alguna interacción y ejecución pequeña, por decirlo así. ¿Hay que realizar simplemente una planificación ideal?
• Bueno, sinceramente no oí que los equipos sufrieran por eso con nosotros. Probablemente lo vencimos en etapas todavía anteriores. Pero tenemos una cultura más... En resumen, no tenemos waterfall, tenemos una cultura muy agile. E intentamos, en principio, bueno, ¿cómo se llama?... ¿Tareas de las que no está claro en absoluto cómo hacerlas, sí? Quiero alguna cosa así, no sé cómo debe funcionar, pero la pondré en su backlog y ustedes después arréglenselas como quieran. ¿Es un story point o un millón de story points? Pero esas tareas simplemente no llegan a nuestro backlog. Mis product managers y el equipo abordan esto de forma bastante adecuada y eliminan la incertidumbre en la etapa de discovery, antes de delivery. Todo esto es sobre discovery. Q23: En resumen: llega una tarea de algún cliente y está relacionada con cinco clientes. Hay que ir al cliente, averiguar qué ocurre con el segundo, ir a diseñadores, analistas, productos, reunir todo esto y vencer esta feature. ¿Y de verdad se ocupa de esto una sola persona?
• Bueno, sí, una sola persona realmente puede ocuparse de esto con nosotros, pero, en principio, antes también era así. Una persona puede analizar todo esto.

Q24: Sobre los diseñadores. Tampoco vi diseñadores en esta conexión. Si hay algún deseo, hay que rehacer, crear un nuevo diseño con componentes nuevos, etcétera, ¿cómo sucede toda esta historia?

• Lo atribuimos más bien a la parte de discovery, en su mayor parte. Tenemos un sistema de diseño implementado como algún kit, que está disponible para el agente. Es decir, en principio el agente ya puede ensamblar una interfaz a partir del UI Kit.

Q25: Bueno, ¿debería revisarlo un diseñador?

• Bueno, resulta que en la etapa de discovery puede aparecer un mockup de diseño. De nuevo, tenemos relativamente poco UI. Especialmente del que requeriría revisión minuciosa, porque tenemos muy pocas pantallas expuestas directamente al cliente. La mayor parte de nuestras pantallas son interfaces para empleados. Siendo sinceros, no estamos preparados para gastar el recurso de un diseñador en revisar interfaces para empleados.

Q26: La demo ahora cambió para los clientes, según recuerdo. ¿Y empezaron a recalcular el pago por cada feature realizada?

• Probablemente es que simplemente no somos outsourcing en este sentido, ¿sí? Es decir, no vendemos tiempo y experiencia de desarrollo in-house. Desde el punto de vista de las demos para clientes internos, en gran medida se ven de manera bastante parecida a antes. Seguimos mostrando algunas features. Se añadió una sección del equipo de harness, que muestra, bueno, como los éxitos del proceso de producción.

Q27: ¿Al negocio y a los empleados les gustan estos cambios?

• Nuestro negocio está literalmente mezclado, cada mes nos lanza tareas, registra inversiones, programas de crédito, nuevas pensiones. Por eso aquí el trabajo llega mucho menos, todo está cerca. Primero, desde este punto de vista. Segundo, nuestros propios empleados operativos de línea. Están incentivados, motivados. Perciben a las personas de manera más activa. Todos tenemos objetivos comunes. Probablemente para nosotros esto es un problema algo menos pronunciado. Intentamos hacerlo todo por completo.

Q28: ¿En qué forma recibe la tarea la persona que después la ejecuta? ¿Alguna descripción elaborada de quién quiere qué, o son literalmente un par de líneas tipo «haz un botón bonito»?

• Antes teníamos un gran problema de variabilidad: cuando las personas recopilaban las tareas manualmente, las creaban en Jira, todo dependía de la velocidad de la persona. En algunos casos había incluso one-liners, un par de líneas sobre la tarea, etcétera. Por eso desarrollamos este sistema, para que minimizara esa variabilidad. Por eso del product manager recibimos intenciones totalmente concretas: qué, por qué, qué métrica, qué mecánica se espera. El product manager, junto con el agente, aclara y elabora todo esto. Y, en consecuencia, después el ingeniero lo toma en esta forma. Y simplemente junto con el agente ya hace brainstorming sobre cómo implementarlo mejor

Q29: ¿Qué modelos usan? Ahora todos se están pasando a los chinos, ¿no?

• Bueno, probamos distintos; probamos ChatGPT, Kimi, Qwen, y los peores probablemente son Qwen, pese a que se usan con más frecuencia. Ahora Kimi K3 se comporta bien para nosotros. Simplemente nos satisface, incluso en comparación con ChatGPT proporciona un código más agradable. Sin alguna diarrea verbal de la que tenemos con ChatGPT. Ellos no

Q30: A mí me resultó que para desarrollo uso DeepSeek 4.1 y GLM 5.3 lo verifica. Y sucede que últimamente, en verdad, dejaron de entenderse entre sí. Bueno, no es fácil.

• Todos ellos, tipo, tienen esto, ject, intelligence, es decir, fortalezas y debilidades. GLM puede encontrar lo que Kimi no encontró y pasar por alto lo que GPT encontrará fácilmente. Es decir, todos deben complementarse entre sí.

Q31: Segunda pregunta: ¿qué equipo hizo el Harnes, y la pregunta que se deriva es cómo consiguió hacerlo? Es decir, pensé precisamente que empezaron con laboratorios, no de inmediato, sino por turnos, ¿y cómo se equipó después este proceso?

• Bueno, el desarrollo mismo lo logró un equipo de unas 4 personas, más yo; había diferentes ingenieros, dos ingenieros generalistas clásicos, dos ingenieros NLP. El trabajo se llevó a cabo durante alrededor de medio año, probablemente con disponibilidad parcial; es decir, en medio año construimos cuatro prototipos de harness que no funcionaban, luego en un mes construimos uno que sí funcionaba y en agosto empezamos a trasladar a todos a él. Y tenía una heurística bastante simple: simplemente entendí que funcionaba. Cuando entendí que funcionaba, usando como ejemplo a mí mismo con el equipo, probamos muchas cosas que imitaban aquello con lo que habitualmente nos encontramos en distintos equipos. Cuando entendí que funcionaría bien, pero inevitablemente nos encontraríamos con algunos errores, que sin esos errores simplemente no mejoraríamos el sistema agéntico, a pesar de que conté que hay que actuar de manera limitada, fuimos all-in. Es decir, todos los equipos recibieron, por decirlo así, el incentivo de que todo el desarrollo se hiciera mediante el pipeline agéntico, de no escribir código manualmente. Tuvimos algunas excepciones. Primero excluimos un proyecto que estaba en el camino crítico de delivery, una migración general, tipo worldwide, que tenía un deadline estricto. Es decir, no queríamos mostrar algo allí, obtener algunos errores. Era literalmente un equipo de seis. Y había un sistema, lo mantenían y mantienen dos personas, había comisiones, cosas antiguas, Windows y demás. Simplemente no queríamos, por decirlo así, lidiar con el sandbox. Lo apartamos y dijimos: chicos, lo resolveremos después. Y eso fue todo, todos los demás entraron en esta historia.

Q32: ¿Tienen algunos frameworks para organizar el contexto y la memoria?

• Entiendo. Caramba, nosotros también, en resumen, sobre este tema; precisamente hablaba de reinventar la rueda. Al principio empezamos a inventar, pensamos: habría que organizar de alguna manera el contexto de nuestros productos en la forma en que el agente pueda entenderlo mejor. Empezamos a diseñar nuestra propia implementación de Deep Wiki. No salió muy bien. Y en el momento en que entendimos que no salía muy bien, Lang Chain lanzó OpenWiki y pasamos en todas partes a OpenWiki. Es decir, simplemente tenemos pipelines que por las noches analizan las Wiki de los monorepos de producto. Esto está disponible para el agente. Y en cuanto a alguna memoria propiamente dicha, todavía no llegamos al punto de que algunas... Es decir, no está claro para qué sirve ahora esta memoria. ¿Qué decisiones concretas debería recordar?

Q33: Es decir, por ejemplo, empezamos a crear cursos de aclaración para roles. Y esto se volvió más realista. (inaudible)?

• No, no creo en absoluto en ese paradigma. Vi los resultados. Bueno, vi cómo las personas intentaron probarlo en vivo. Usarlo, implementarlo. Y no funcionaba. Y sobre esa base llegamos a la conclusión de que no funciona. Además, nuestros fracasos con los pipelines de roles me llevaron a pensar que algo así funcionaría bastante mal.

Q34: ¿Podrían compartir la experiencia? Llegaron a un equipo y dijeron... Ya no eres backend ni frontend. Ahora eres simplemente ingeniero. ¿Cómo trabajaron con la resistencia? ¿Cómo reaccionaron los equipos? ¿Y cómo reestructuraron en general este entorno?

• Bueno, nos llevó mucho tiempo. Más tiempo que el propio Harnes engineering. Es decir, avanzamos hacia ello. Pero probablemente desde el verano pasado fui preparando el terreno. Y empezó con algunas presentaciones sobre hacia dónde va la industria, qué sucede en ella, por qué, por qué por el trabajo que hacen probablemente no les pagarán dinero dentro de dos años.

Q35: Eso está claro. ¿Pero cuando llegó directamente el momento de los cambios?

• Dimos ese paso mucho antes que todas las demás empresas. En otoño del año pasado dijimos: chicos, por ejemplo testers, frontends, ops, tendrán que hacer plataformas de producto. Estamos preparados para proporcionarles la formación necesaria. Sentémonos ahora todos juntos, tomemos lo que falta en la descripción de algunos acuerdos de equipo, prácticas de ingeniería, etcétera, y estandaricémoslo. Y nos dedicamos a ese trabajo de estandarización. A través de él, esencialmente, algunos ingenieros, por ejemplo backenders, dominaron algunos matices de testing que antes no conocían, con los que no trabajaban. Ahora todo esto tomó cierto tiempo. En gran medida, al final descartamos todo este trabajo. Todos esos handbooks que escribimos, en las nuevas realidades algunos pasaron a los skills, otros simplemente ya no los usa nadie. Pero fue útil desde el punto de vista de la adopción gradual, para tranquilizar.

Q36: ¿Quedaron algunos expertos que, por ejemplo, revisen la arquitectura o igual no?

• Tuvimos casos muy desagradables: pensábamos que teníamos un experto, literalmente el puesto se llamaba experto, e incluso eran responsables de escribir algunos trendbooks, etcétera. Mientras escribían esos trendbooks y presentaban su experiencia, resultó que la profundidad de esa experiencia no era tan inalcanzable como creíamos antes. Es literalmente palpable y se transfiere fácilmente a roles de ingeniería clásicos normales. Tenemos expertos generalistas fuertes, tengo varios generalistas así que pueden hacer absolutamente cualquier trabajo, tienen un reasoning potente en cualquier área de computer science. Pero aparte de eso ya no nos quedan otros expertos, e incluso esos expertos no se usan para verificar decisiones de alguien, sino para resolver alguna tarea extremadamente atípica en la construcción del Harness o en la optimización de alguna de sus partes, algo que antes no hacíamos, RnD en resumen.

Q37: Última pregunta. Antes los equipos eran grandes, empezaron a hacer este trabajo; ¿qué porcentaje de reducciones u optimizaciones tuvieron? ¿O no ocurrió, encontraron a todos un nuevo lugar?

• En realidad, no buscábamos optimizar ni reducir costos; nuestro objetivo era y es TTM. Hubo ejemplos de personas que, por ejemplo, eligieron por sí mismas que esto no era para ellas. Yo trabajaré todavía como tester en la empresa N. O, caramba, no entiendo cómo pasaré de tester a ingeniero si ya no escribo código. Esas personas decidieron por sí mismas que no iban por el mismo camino que la empresa. No forzamos a nadie. Tenemos, esencialmente, probablemente un attrition rate de entre 5% y 8%. Es completamente normal, teniendo en cuenta cambios tan radicales.

Q38: Dijeron en la ponencia que ya no tenían análisis de sistemas desde hacía bastante tiempo. ¿Pero qué deben hacer las empresas donde el análisis de sistemas existe desde hace bastante tiempo? Y hay una enorme cantidad de lugares donde algo está escrito. BTS, FOD. No sé, alguna documentación de usuario. Y toda esta documentación se contradice entre sí. No hay una única fuente de entrada. Es bastante extensa. También hay muchísimo código, todo está en diferentes repositorios. En consecuencia, para construir un pipeline agéntico... Ahora tengo este problema: todos mis agentes se meten en un contexto no fiable. Me dicen algo, toman decisiones basándose en falsedades. ¿Cómo combatir esto?

• El funcionamiento del producto es más importante que una documentación exhaustiva. Telemetría simple. Lo más probable es que en la mayoría de casos así ocurra en nuestro mundo. Pero allí donde teníamos... conservamos contexto útil, por ejemplo, al nivel de la descripción de negocio. Por ejemplo, alguna regulación, normativa, descripciones de productos complejos permanecen inalterables. Esto se mantuvo y simplemente migró al monorepo de producto convencional. Sí, todo lo demás, estas tablas, esquemas, diseños. Pero siempre fue un problema. Simplemente quedaban obsoletos incluso antes de los agentes y demás. Y no había una solución normal para cómo... Bueno, había soluciones, intentos, como: hagamos una prueba arquitectónica, hagamos allí... En resumen, añadamos alguna capa de testing y verificación. Era difícil, muy caro. No nos dedicamos a ello. Simplemente descartábamos esas cosas y considerábamos que esto era la forma de resolver tareas.

Q39: ¿Qué incidentes graves tuvieron con los agentes?

• En general, antes de los agentes siempre había... No, si miramos la métrica incident rate, la que mostré: el defect rate se mantiene al mismo nivel que antes. Algún incidente realmente a gran escala, debido precisamente a las particularidades del negocio corporativo, del crédito corporativo, es bastante poco probable. Allí donde, en resumen, donde tenemos un blast radius potencialmente bastante significativo, hacemos double-check, triple-check. Es decir, lo intentamos. Allí realmente se puede cometer un error grave en algunos asientos financieros, tramos, etcétera. Aquí nuestros sistemas estaban, incluso antes de los agentes, rodeados de ciertas condiciones, pruebas, verificaciones de todo tipo. Y estaban tan bien diseñados, en mi opinión, nos esforzamos muchísimo en su rediseño, que ahora no ocurre ningún incidente allí. Bueno, quizás aún no es tiempo. Quizás llevamos aquí tres meses, tal vez mañana ocurra algo.

Q40: Pregunta sobre la métrica time-to-market. Modelos paralelos de desarrollo de diferentes dominios. Dicen que mejoraron time-to-market, pero la paralelización se mantuvo, especialmente conflictos de merge requests y todo ese tipo de cosas. Si entiendo bien, supongamos una modelo de dominio bien diseñada, sí, pero aun así el producto o su backlog puede cambiar el mismo dominio, ¿sí?, y hay que resolver conflictos. ¿Los resuelven a nivel de la capa agéntica, a nivel de planificación de productos, features, o cómo?

• Bueno, seguramente no se resuelven a nivel de planificación; al menos no conozco ese modo de resolverlos, quizá existe en algún lugar, simplemente no lo conozco. Todo se resuelve a nivel ya de.... Ahora recordaré cómo lo hicimos. Es decir, el propio agente hace rebase. Esencialmente tenemos trunk-based, tenemos una historia lineal, todos esos conflictos deben resolverse de alguna otra manera en el MR. Las personas ya no resuelven esos conflictos, en gran medida los agentes resuelven los conflictos y en la mayoría de los casos lo manejan.

Q41: ¿Y si sucede simplemente en paralelo, tipo uno ya fue revisado, ya está listo para producción, y el segundo en exactamente el mismo dominio también está listo para producción?

• Bueno, los agentes, propiamente... No son exactamente agentes, es un sistema complejo. Los enfoques, las estrategias se implementan a sí mismos.

Q42: ¿Y qué hacen con los blockers? Por ejemplo, bloquear un dominio. Tipo, no editamos dominios mientras se está editando otro dominio y no ocurre human approval.

• Sinceramente, no oí que tuviéramos tales conflictos...

Q43 ¿En el monorepo? En el monorepo siempre surgirán, ¿no? Bueno, cuando editas un dominio, un producto quiere la feature A, otro producto quiere la feature B.

• Ah, no, no tenemos varios productos de un mismo dominio. Es decir, resulta que a nivel de gestión hay una cola de decisiones estructurada y sensata. Se puede decir que correctamente. Y además, por cierto, hay un punto importante: durante el proceso que mostré, uno de los agentes también investiga si la feature que quieres no contradice lo que ya existe. Es decir, convencionalmente, si no quieres violar los límites de funcionamiento, añadir al sistema algunos párrafos mutuamente excluyentes que no deben estar. Ya funciona de otra manera by design. Intentas romper un comportamiento que las personas antes committearon. Eso es lo primero. Segundo. Esta misma cosa también escanea, en principio, las tareas existentes para asegurarse de que ya no haya contradicciones. Porque intentamos resolver directamente estas contradicciones ahora. Me olvidé de esta parte porque se hizo hace tiempo. Porque después se hizo muchísimo, muchas facetas en esta parte. Es decir, incluida la resolución de contradicciones puede realizarse aquí, en esta parte del sistema. De este modo, en el pipeline agéntico realmente te llega, en esencia, una cola de tareas preparada, en la que el pre-base es trivial y seguro.

Q44: Entiendo, porque pre-base es precisamente esa cosa en la que el agente se equivoca bien periódicamente. Y el segundo punto: ¿ajustaron modelos, infraestructura, temperatura, reasoning y todo lo demás?

• El año pasado jugamos activamente con temperaturas, reasoning. En el enfoque actual intentamos no hacerlo. Tratamos de usar los ajustes por defecto. Porque no está claro cómo comparar. Se necesitan inversiones bastante potentes en benchmarks, evals, jueces. Hay que dedicar más atención de los ingenieros a observar esa regeneración que los modelos comienzan a hacer. De nuevo, casi siempre son comparaciones que se cuantifican mal. Es una cuestión de gusto. Y no jugamos con ello. Intentamos que, a nivel de ciertas instrucciones, se llegue a un resultado aceptable para la persona.

Q45: Y después los modelos son independientes. Si, por ejemplo, en terceros modelos se obtiene debido a esto, en esencia no depender de quién sea. Si necesitaran hacer alguna iteración más.

• Aquí somos model-agnostic. Por ahora tratamos de no bajar y hacer downscaling a modelos simples. Por ahora tenemos dinero para no ocuparnos de ello. Y para hacerlo hay que invertir mucho también en benches. Pero, de una u otra manera, ahora tenemos mucho más material para el bench que antes. Antes había que recopilar del histórico tareas de distintos proyectos con diferentes prácticas de ingeniería. Ahora tenemos más o menos el funcionamiento de un sistema co-agéntico. Las prácticas de los proyectos, por ejemplo, se nivelaron algo. Los tamaños de las tareas se nivelaron más o menos. La descripción de las tareas es más o menos clara. Es igual en todas partes. Por eso ahora el material para el bench es más rico. Empezaremos a ocuparnos de ello, aparentemente, dentro de un tiempo.

Q46: Entonces, ¿SDD no se usa en absoluto aquí? ¿O como espejo?

• Bueno, OpenЦiki no es exactamente un espejo, lo llamo simplificación de la navegación para el agente. Reducir la cantidad de hops que necesita para entender, encontrar lo necesario. Se puede resolver de distintas maneras, pero no usamos Semantic Search, confiamos más en algún grep, ripgrep y demás. Por eso OpenWiki ayuda aquí. Pero si hablamos de SDD propiamente, es una entidad de otro orden. Probamos en nuestro desarrollo, todavía en vibe-coding, por ejemplo, usar algún OpenSpec, Spec Kit. Sinceramente, ya ni recuerdo qué resultados tuvimos con Spec Kit. Vivimos durante bastante tiempo dentro de OpenSpec precisamente en el equipo de Harness engineering. Pero a los chicos les gustaba, a parte de los chicos. Luego llegué, miré cómo se veía. Pensé: caramba, esto es complejo, sinceramente. Se puede lograr el mismo resultado con un proceso mucho menos redundante. Es ir y venir, en esencia. Sí, sí. La idea es clara: cuantos más tokens gastes en brainstorming dirigido, mejor resultado obtendrás probablemente dentro de algún rango probabilístico. Pero ahora abandonamos esta práctica y más bien hacemos una spec SDD muy ligera en el formato, bueno, como el Playbook que Anthropic publicó recientemente. Y publicaron ese Playbook en el que decían que tenían Intent.Markdown, Spec.Markdown, Design.Markdown, algo así. Y literalmente nuestro sistema está implementado de forma muy similar. Todo se commitea en el mismo repositorio Git que el código principal, pero sin algún workflow rígido, propio, por ejemplo, de OpenSpec, y ciertamente con un nivel de verbosidad menor que el suyo.

Q47: Entonces, ¿la spec sí está guardada de alguna manera?

• Sí, sí, claro. Es una parte importante.

Q48: Andrey, quizá no escuché bien. ¿Qué llaman exactamente grupo de equipos de roles y role policy? ¿Un agente analista, un agente desarrollador, un agente tester? Sí, dijeron que al principio se decepcionaron del pipeline de roles, y luego comenzaron a hacer lo que hacen ahora.

• Ah, sí, sí, sí. Había... Intento recordar qué teníamos. En realidad, me parece muy parecido. Algunos prompts como Codex Planning, por ejemplo. Teníamos un planificador que debía proporcionar un plan de implementación detallado. Teníamos un implementador que debía ejecutar el plan de implementación. Creo que no tenía derecho a escribir pruebas. Había adicionalmente un escritor de pruebas. Y, creo, para cada fase teníamos adversaries que debían asegurarse de reiniciar el trabajo si se detectaba algo impropio. Sí, no nos funcionó.

Q49: Entonces ahora, ¿hay un solo agente?

• Bueno, un ejecutor clave, que posee, en esencia, el núcleo end-to-end. Un guerrero samurái de este tipo. También tiene, bueno, llamémoslos... No exactamente asesores, pero, en resumen, puede lanzarse un revisor. Se lanza al terminar el trabajo, puede dar algún feedback al agente y el agente puede terminar algo una vez o ignorarlo. Puede no estar de acuerdo con ese feedback, y entonces quedará explícitamente registrado: fue ignorado. Y, en consecuencia, en gran medida intentamos no construir cadenas de roles

Q50: Otra pregunta. Un ingeniero realiza una tarea. Cuando pregunto sobre el día laboral del ingeniero, cuando llega al equipo y se ocupa de sincronización de equipo, entonces ¿en qué consiste esa sincronización de equipo?

• Bueno, para mí es importante entender, probablemente, convencionalmente, que no debo tener visión de túnel, porque recibí una tarea y fui a hacerla solo, pero eso lleva a que las personas se conviertan en esquizofrénicos, bueno, primero, probablemente no les interesa trabajar, se sienten simplemente como ejecutores, y porque alguien ahora hace todo su trabajo solo. Por eso aquí todos nuestros ingenieros están completamente inmersos en el contexto de producto, resuelven problemas del cliente. Piensan cómo implementarlo. Tenemos equipos así. Tenemos equipos así, equipos grandes, cada uno realiza su tarea. Ahora tenemos equipos así.