Bloques de Construcción de una Plataforma de Ingeniería Agéntica: Lo que SRE Nos Enseñó Sobre Ejecutar Agentes

Primero, sobre mí. Mi nombre es Ilja. Vivo aquí desde hace 12 años en Ámsterdam. Pasé 20 años haciendo ingeniería intensa, replatforming, refactorización, en plataformas como plataformas heredadas, trabajando para empresas como Ikea, Nike y otras.

Así que lo que estoy haciendo ahora es que comencé hace un año, más de un año, una agencia llamada Endgame. Y lo que estamos tratando de hacer es básicamente lo mismo, pero estamos construyendo sistemas que construyen otros sistemas o hacen cualquier tipo de modernización heredada.

Y lo que también hacemos y tratamos de hacer, intentamos escalar estas prácticas, como las prácticas de ingeniería agéntica a organizaciones de 500 ingenieros a veces tendremos clientes de 3000 ingenieros. Este es el desafío. Cuando tienes un equipo de dos o tres personas, es un desafío. El otro desafío es cómo lo hacemos a la escala de 3000 personas. ¿Y qué hacemos con todo este gasto? ¿Cómo nos aseguramos de que tenemos retorno de inversión? ¿Cómo nos aseguramos de que la gente realmente lo está usando de manera segura? Y esto es en lo que hemos estado reflexionando durante el último año.

Y lo que aprendimos es que, básicamente, es una situación difícil en el mercado ahora mismo. Así que la gente no confía en los agentes. La gente piensa que todavía necesitas ir y verificar cada línea de código producida por el agente, incluso si haces una aplicación simple de Next.js. Pregunta para ustedes, ¿cuántos de ustedes usan Cloud Code diariamente o algún tipo de agente y no usan IDE en absoluto? No. De acuerdo. Creo que como cinco personas, incluyendo la primera fila aquí y yo mismo. Está bien. Porque lo que aprendimos es que el sistema agéntico sigue siendo un sistema, sigue siendo un sistema distribuido, y todavía necesita tener el mismo enfoque, el mismo tipo de patrones como si estuviéramos construyendo y escalando sistemas distribuidos.

Pero la dificultad es que falla silenciosamente. Puedes obtener 200, pero la tarea es descuidada. El código producido es de muy mala calidad y así sucesivamente. Así que el otro problema es que esta energía nuclear que puedes contener y puedes poner en cualquier tipo de canalizaciones, cualquier tipo de entorno empresarial, y necesitas asegurarte de que todavía tienes dinero para el salario del próximo mes y todavía tienes tus claves de entorno seguras. ¿Verdad? Y de esto iba a tratar la charla. Así que lo que vemos ahora, muchas cosas, lo que vemos sucediendo con la ingeniería agéntica y la construcción de sistemas agénticos, es básicamente muy derivado de los patrones de experiencia de desarrollo de SRE y lo que hemos estado haciendo durante los últimos 20 años con el movimiento en la nube y las transformaciones en la nube.

Entonces, si miramos, por ejemplo, DevOx, y este es el tema más interesante para mí, se desplaza hacia la experiencia agéntica. ¿Qué significa esto en realidad? Necesitas tener entornos provisionados en cuestión de segundos. Necesitas entender cómo probar tus sistemas. Necesitas ser capaz de soportar la carga de esos entornos contra los agentes y flotas de agentes. Y esto es algo de lo que puedo hablar durante horas y horas después. Intenté preparar esta charla para que fuera más de alto nivel, pero si quieres entrar en detalle, todavía estaré aquí, alrededor, solo pongámonos al día.

Entonces, ¿cómo miramos el problema en sí? Así que tienes una parte del problema, que es la ingeniería agéntica. Y esto es lo que estamos haciendo, supongo, la mayoría de nosotros todos los días. Esto es cómo nos aseguramos de que tenemos un arnés adecuado a nivel de base de código o múltiples bases de código. ¿Cómo nos aseguramos de que los agentes tengan una red de seguridad, puntos de verificación? ¿Cómo nos aseguramos de que podemos realizar algunas pequeñas cosas de un solo golpe, y va a funcionar y el código se producirá al nivel de los patrones que usamos en nuestro software, al nivel de los estándares de código. Y puedo continuar y continuar.

Y esta es una parte, esto es más a nivel de equipo individual. Si lo escalamos a la organización de 3000 personas, tenemos problemas totalmente diferentes. Y los problemas se han resuelto en el pasado, como dije, con la transformación en la nube. Y lo que llamamos ahora mismo, este tipo de configuración como SRE, o cualquier tipo de equipo responsable de asegurarse de que las mejores prácticas, el mejor patrón, la forma segura de hacer las cosas se escale en toda la organización, lo llamamos habilitación agéntica. Y esta es la diferencia en términos de cómo hacerlo localmente con tres personas, y cómo escalarlo a toda una organización. Así que cómo estructuré la charla en sí es en tres áreas, básicamente pasaré por una lista de preguntas que típicamente nos hacen nuestros clientes. Y esas preguntas a veces son técnicas, esas preguntas son operativas en su mayoría y muchas preguntas son organizacionales. Nuevamente, esta no es una lista completa, intenté condensarla y destilarla en las más importantes. Vamos.

Entonces, en términos de patrones técnicos, cubriré solo un par, porque definitivamente conoces la mayoría de ellos. Así que el primero es, la parte más difícil de convencer a cualquier desarrollador de hacer, es aislar sus agentes. Tienes muchas maneras de hacerlo. Pero el problema si no lo haces, puedes tener fugas de seguridad, puedes tener la mayoría de las cosas que están saliendo de tu agente siendo en realidad no seguras también. Puede acceder a redes a las que no quieres acceder. Y este es uno de los mayores problemas que vemos en las organizaciones más grandes que simplemente regalan suscripciones de equipo defectuosas. La gente comienza a usarlo a nivel de sus computadoras o sus entornos locales. Y en realidad lo que tenemos, y va a ser una bola de nieve en el futuro, hemos escuchado ahora mismo en algunas charlas de nuevos ataques ShyHulud a través de CloudQuot recientemente, va a suceder más y más. Y asegúrate de que aseguras y haces que tus agentes tengan el menor privilegio de acceso a lo que están haciendo.

A continuación, lo que comenzamos a explorar incluso hace un año es que sabía que la codificación a nivel individual en un repositorio se resolvería. Pero lo que no se va a resolver y va a ser difícil de hacer es la gestión de contexto en la escala de un sistema. Y el sistema típicamente, lo que llamo un sistema, va a ser múltiples repositorios, a veces repositorio separado para el front end, cinco servicios diferentes, algunas configuraciones diferentes, Terraform tareas de extremo a extremo, y así sucesivamente. Y aquí es donde piensas, está bien, ¿cómo lo hacemos? ¿Cómo lo hacemos en la escala de múltiples repositorios? Y comenzamos a experimentar con algo que llamamos hubs de contexto. Así que es un repositorio separado que tiene todas las decisiones, forma estructurada de registrar qué ADRs a través del sistema son. Y luego intentamos avanzar hacia construir sobre eso, construyendo diferentes gráficos de contexto. Y hay múltiples cosas en el mercado que puedes probar de inmediato, desde ByteProver para hacer contexto a nivel de equipo hasta en realidad nivel de base de código, entendiendo como graphified. Y luego, por supuesto, comenzamos a desarrollar nuestras propias herramientas. Y creo que aquí es donde todo va, es que comenzarás a desarrollar tus propias herramientas personalizadas para entender y construir mejores sistemas y reportar registros como ADRs, reportar alcance y cualquier tipo de decisiones de producto.

Dato curioso, lo que realmente hacemos, no tenemos el estado ideal para nosotros. Incluso si vamos a clientes y trabajamos en algunos entornos complejos, no nos gusta usar GRS, linears o cualquier tipo de estas cosas, porque no creemos que sea realmente adecuado para agentes. Lo que usualmente hacemos, tenemos archivos JSON L, por ejemplo, en el repositorio de hub de contexto separado, y lo sincronizamos de ida y vuelta solo para reportar a los gerentes de producto y cosas así. Otro patrón que hemos visto en la naturaleza es si tienes transferencias de una actividad a otra actividad, por ejemplo, tienes un PRD o EPIC o cualquier tipo de especificación, necesitas establecer un formato muy estandarizado. Y más allá de eso, necesitas verificar y validar que el formato sea realmente percibido y completado y funcione bien entre esas etapas. Lo que significa que necesitas comenzar a consolidar y entender cómo estandarizamos todos los artefactos de transferencia en toda la empresa.

A continuación, la parte más interesante es cuando la gente me pregunta, ¿qué es, cómo hacemos con los agentes autónomos? ¿Dónde los desplegamos? Esto parece una gran inversión de capital que necesitamos hacer. Pero mi respuesta usualmente es si tienes GitHub actions, este es el mejor punto de partida para que entres en agentes autónomos. Y esto es cierto porque tienes algo que puedes integrar en tu pipeline de inmediato. Tienes eventos que están saliendo de tu pipeline de CI. También lo que tienes es un entorno sandbox de inmediato. Así que esta es la manera más fácil de hacerlo. Y lo que comenzamos a hacer bastante es pasar de maneras simples, por supuesto, todos están haciendo revisiones de código aquí, haciendo revisiones de PR, probablemente han estado haciendo un poco de acciones de comillas y ajustando eso. Pero lo que estamos haciendo al siguiente nivel es, un buen ejemplo de un pipeline muy avanzado puede ser un pipeline de caza de errores donde entiendes las áreas más complejas de tu base de código. Entras con cualquier cambio para ejecutar una comprensión, comprensión semántica de lo que puede romperse desde el punto de vista del negocio, también desde el punto de vista técnico e intentas auto-corregirlo. Así que creo que si puedes hacerlo en tu pipeline de CI, eso va a ser, creo, una de las grandes victorias para todo el equipo, lo cual requerirá mucho contexto, mucha gestión de contexto supresión y trabajar en esto.

Si subimos a continuación, creo que el primer punto interesante es como, por supuesto, GitHub actions puede cubrir mucho. Puedes integrar agentes en tu CI. Va a ser lento. Y luego vamos a patrones más avanzados como, está bien, podemos envolverlo, envolver el por ejemplo, plot SDK o deep agents SDK en una aplicación de Python, por ejemplo, ¿verdad? Publicarlo en Docker en algún lugar, proporcionar algunas mecánicas de pull o push en los web hooks. Y luego va a ser siempre un tipo de agente de respuesta rápida. Una manera muy simple de cómo comenzar a reconstruir tu flujo abierto es pensar de esa manera. Eso es todo sobre el patrón técnico. Muy fácil. Puedes integrar tus agentes en tu pipeline de CI. Necesitas comenzar a hacer esto. Necesitas comenzar a pensar sobre el contexto y el contexto no es estático. El problema con el contexto es también que es otra capa de actividades que tu equipo debería estar haciendo. Supresión, contexto obsoleto, revisión del contexto, entendiendo qué debería ponerse, cómo ponerlo, cómo acceder a él adecuadamente, cómo hacerlo accesible, rápido, confiable para el agente.

Vamos a lo operacional. Así que la primera pregunta que usualmente nos hacen es como, está bien, si vamos a Claude y Claude es la infraestructura masiva, nosotros en el mercado ahora mismo, es un gran bloqueo de proveedor. Y aparte de esto, hay múltiples otras cosas que se preguntan sobre Claude y cómo nos protegemos yendo a un solo proveedor? Por supuesto, todo el arnés, el pod de Claude, el paquete instalable que instalas en tu entorno y en realidad interactuando con el terminal o a través de SDK es el más poderoso en términos de funcionalidad y características. Y nadie quiere perder estas características. Por ejemplo, los flujos de trabajo fueron anunciados recientemente. Es bastante difícil imaginar mi vida sin flujos de trabajo ahora mismo. Así que no quiero perder esta funcionalidad.

Pero lo que hago es como si no tuviera dinero para esto. No puedo permitírmelo en la escala de 3000 personas. Entonces, ¿qué hago? La forma sencilla que aconsejamos es mirar modelos compatibles y API compatibles. Y también hay una manera de implementar algo llamado LLM gateway, que proporciona la capacidad de traducir cualquier tipo de, por ejemplo, modelos alojados en bedrock, modelos de peso abierto más baratos como kidney, por ejemplo, y hacerlos "quote quote" compatibles para que puedas cambiar fácilmente. Puedes rastrear fácilmente lo que hace toda la organización. Pero aparte de esto, LLM gateway proporciona muchas características de seguridad. Permite esto para MCPs, cualquier tipo de configuraciones, mecanismo de inyección de prompts y cosas así.

Lo siguiente es cómo nos aseguramos de gastar algo de dinero en algo que sea valioso. Y también hay DX y muchas otras grandes plataformas. Probablemente pagas cientos de miles de euros cada año. Creemos que va a ser muy fácil simplemente conectarse básicamente a LLM hotel y crear una sincronización con tu Prometheus y poner Grafana en la parte superior. Y luego, lo que puedes obtener de ello, puedes obtener bastante. No solo puedes obtener todo el gasto, sino también el precio por commit. ¿Qué modelo se utilizó? Si conectas cada tipo de PR a cualquier historia o registro, ¿cuál es el valor? Puedes pensar más. Entonces, ¿cuánto gastaron realmente en entregar algún valor? Y luego, si avanzas y avanzas, puedes conectarlo a cualquier tipo de herramientas de gestión de productos o herramientas analíticas para obtener información del cliente. Y puedes entender bastante en términos de dónde se está gastando esto. Forma sencilla. No pienses demasiado, no sobre-ingenierices. Ya lo tienes. Simplemente crea la sincronización de Hotel desde tu Cloud Code o cualquier otra herramienta a tu entorno.

Otra pregunta, ¿cómo mantenemos los costos bajo control? Y hay múltiples maneras. No quiero hablar mucho a nivel individual. Pero creo que quiero comenzar con un poco de, probar algunas herramientas que están haciendo racionamiento de la salida de herramientas. Lo que hace, usualmente tienes un lote de herramientas ejecutándose desde el Cloud Code o cualquier tipo de agente. Y lo que puedes hacer con ello, puedes decir, está bien, no necesito toda la salida. Y esas herramientas como RTK o Headroom te permiten realmente racionar. Asegúrate de que tu agente obtenga solo lo que necesita. Pero aparte de esto, por supuesto, límites de costos y cualquier tipo de autonomía progresiva, solo para asegurarte de que no permitas que tus agentes hagan más de lo que necesitan hacer. Si subimos en términos de los patrones, lo que también vemos que ayuda si tienes cualquier tipo de planos de tus servicios disponibles de tu equipo de DevOps, por ejemplo, cómo aprovisionar un servicio de API rápido o cómo aprovisionamos un microservicio conectado a Kafka de inmediato y comenzar a construir rápidamente. Necesitas asegurarte de que ya haya un arnés incorporado en él. Significa habilidades para hacer las cosas importantes, hooks, cualquier tipo de flujos de trabajo que se necesiten, cualquier tipo de puntos de verificación adicionales que deberían estar en su lugar.

Entonces, cualquier tipo de paquete distribuido dentro de la organización, fuera de la organización, asumo que ahora mismo debería tener algún arnés integrado. Los mercados internos, nuevamente, la forma más rápida de iniciarlo es simplemente Git repl. Nada más. Proporciona un mecanismo de gobernanza y mucho más para hacerlo realmente escalable para toda la organización y contribuible para toda la organización. Y muchas empresas realmente piensan que el contexto y la información dentro de la empresa se comparten y todos saben todo, lo cual no es cierto en muchos casos. Y usan Confluence y cualquier tipo de esas herramientas. Creemos que Confluence y las herramientas centradas en humanos no son buenas para los agentes. Lo que usualmente hacemos es crear algo llamado distribución de contexto y usamos imágenes estándar o artifactories para hacerlo. Así que puedes empaquetar una pieza de contexto de un equipo, enviarla allí, versionarla y otro equipo puede realmente extraerla u otro agente puede extraerla.

Avanzando bastante rápido. Patrones organizacionales. Y aquí es donde comienza la diversión. Así que si miras todo lo que discutí, se convierte en un trabajo masivo real y probablemente una función separada dentro de la organización. ¿Por qué? Porque no es muy uniforme. Tenemos diferentes prioridades. Todos tienen diferentes experiencias y necesitas asegurarte de que las mejores prácticas se distribuyan a lo largo de la organización. Pero también necesitas tener una plataforma muy confiable para ejecutar tus agentes. Y para nosotros, cómo vemos toda la plataforma en sí, no importa si haces ingeniería agéntica o haces cualquier tipo de automatización de procesos de negocio con agentes, puede ser ejecutado en la misma plataforma.

Y en la pantalla, ves un montón de capas que necesitas introducir para que suceda, incluyendo orquestación, incluyendo gobernanza, incluyendo capas de seguridad, incluyendo las micro VMs para sandboxing y así sucesivamente. En términos de equipos, y esta es una gran pregunta de la que puedo hablar durante años. Y comienza con el número mágico tres. ¿Por qué tres? Porque hay algo llamado coordinación, comunicación, en el diseño organizacional. Y tres personas es donde hay un número dorado donde tus caminos de comunicación no están creciendo exponencialmente. Después de esto, lo están. Significa que si agregas otra persona al equipo, otra persona al equipo, otra persona al equipo, pasas más y más tiempo en colaboración, comunicación. Y ahora mismo con agentes, lo que nos permite hacer es realmente volver a estos pequeños equipos, abre muchas preguntas. ¿Qué hacemos con otras personas? ¿Cómo reubicamos la capacidad? No quiero hablar de esto. Lo que significa que aún necesitas habilitar todos esos puertos y equipos para tener las mejores prácticas y cómo pensamos que debería hacerse es exactamente esta habilitación agéntica. Y este es un equipo separado que hace el trabajo de asegurarse de que la experiencia agéntica esté en un nivel alto, la experiencia de desarrollo también.

Y cómo escalarlo prácticamente, porque también debería haber dinámicas y movimientos sobre cómo hacerlo. Entonces, ¿cómo lo estructuramos realmente? Intentamos encontrar los bolsillos de adopción dentro de la empresa. Intentamos encontrar a esas personas, equipos Pathfinder que ya están haciendo bastante de lo que he mencionado e intentar institucionalizar y asegurarnos de que este conocimiento y estos patrones y esas prácticas estén cualificados. Y aquí es exactamente donde el equipo de habilitación juega bien y se distribuye a través de la red de campeones de otros equipos a otros, toda la organización. Así que en resumen, solo para concluir de lo que estaba hablando, es bastante lo que podemos derivar de prácticas y disciplinas que ya hemos tenido en el pasado. Y esto es Esri, experiencia de desarrollo, ingeniería en la nube, y cómo pasamos de no saber nada sobre la nube y sistemas distribuidos en la nube a donde estamos ahora mismo. Pero algunas cosas son muy nuevas y puedes obtener mucho de este pasado, pero necesitas aprender bastante. Y lo que quiero mostrarte y lo que quiero producir un poco de interés es que esto sigue siendo un sistema distribuido. Puedes incrustar tu agente y sacar una salida estructurada de ellos y conectarte a cualquier tipo de procesos de negocio y flujos de trabajo de negocio, incluyendo tu SDLC. Es totalmente lo mismo. Pero necesitas abrazar esta entropía y necesitas entender cómo avanzar con este poder nuclear que realmente puede ser para bien y para mal. Gracias.

Tenemos una primera pregunta para ti. Parte de nuestro problema con la IA agentic es la dificultad para encontrar mejores prácticas. Todos estamos luchando con esto porque está cambiando tan rápido. ¿Cuál es tu enfoque para construir un marco fundamental, indicaciones, habilidades, reglas, etc., frente a la ingeniería compuesta y ese tipo de cosas? Buena pregunta. Mi opinión sobre esto sería que hay algunas cosas que ya puedes... Así que hay múltiples direcciones para responder a esta pregunta. Una sería que ya tienes cosas que están más o menos establecidas, como las habilidades estarán aquí y estandarizadas. Todavía no es mucho. Entonces, lo que haces con la ingeniería de contexto, para ser honesto, en la forma más simple, solo marca archivos y registros. Pero si subes y subes en términos de cómo lo estructuramos, es básicamente lo mismo que hacer un modelo de datos específico para cómo haces las cosas como un proceso.

Por ejemplo, necesitas registrar decisiones arquitectónicas. Cada una de ellas debería tener un ID. Está conectado a un sistema específico y así sucesivamente. Así que básicamente la capa de ejecución subyacente puede cambiar cómo lo haces, pero este conocimiento no se perderá. Entonces, cómo empezar con esto es como empezar a pensar en lo que hago, cómo lo hago, qué necesito reportar y qué tipo de conocimiento tácito debería comenzar a ser más explícito dentro de mi equipo o organización y luego solo pensar en cómo lo hacemos, qué es. Pero cómo lo hacemos, qué es, es básicamente algunas cosas que ya están estandarizadas.

Eso lleva muy bien a la siguiente pregunta, que es cómo mantienes esos trabajos de contexto con cambios arquitectónicos, registros de decisiones, etc., automáticamente a medida que avanzas en esto? Todos piensan que va a ser solo conectar y usar y mantener automáticamente y luego la gente no debería corregir. Desafortunadamente, no es la realidad. Como dije, va a ser más un nivel adicional de actividad que el equipo y los individuos deberían hacer, pero hay un par de maneras de hacerlo. Así que la forma más simple, de nuevo, creo que estoy volviendo a la ingeniería fundamental aquí, es como puedes conectar libros de puertas para asegurarte de que algunas cosas después de tu cambio estén actualizadas y luego crear una revisión con y juntar con el PR, por ejemplo.

Además, por supuesto, puedes hacer automatizaciones semanales para hacerlo. Pero lo que me gusta es que algunas cosas que son de agentes a agentes se pueden hacer automáticamente y hay mucho de esto. Pero algunas cosas, que nuevamente, como mencioné, hay decisiones de producto, decisiones arquitectónicas, una funcionalidad específica e intención de lo que queremos hacer deben ser revisadas por seres humanos.

Muy bien. La siguiente pregunta que tenemos. ¿Tienes algún consejo para equipos u organizaciones que crean código de alto riesgo, por ejemplo, software como dispositivo médico, y emplean agentes de IA o se aplican las mismas reglas? Maravillosa pregunta. Tenemos dos grandes clientes de atención médica. Recientemente estábamos haciendo excavaciones en la aplicación de 45 años de antigüedad con C++ y Delphi. Técnicamente, las mismas reglas de trabajo en la base de código se aplicarán igual, totalmente igual.

Hay mucha mecánica regulatoria con la que necesitas cumplir. Por ejemplo, no puedes hacer fusiones completamente automatizadas. No puedes hacer muchas cosas que imaginarías hacer automáticamente, incluyendo el mantenimiento de la documentación, porque aún debe ser aprobada por humanos. Pero en general, se remonta a la red de seguridad y pruebas. ¿Cómo lo pruebas? Pero te sorprenderá que si los dispositivos médicos, todos piensan que está cubierto con 100% de cobertura de pruebas y cosas. No, no es el caso.

No es el caso. Lo he visto todo. No, no es el caso. Así que mi opinión sobre esto es que hay múltiples maneras de hacerlo, pero también múltiples maneras de contener el cambio y cómo entender cómo podemos tocar todo esto con el ojo, porque la velocidad del cambio sería rápida. Solo pondré una dirección interesante, intenta entender qué son las pruebas de caracterización. Básicamente son pruebas de regresión sin entender el resultado. Y lo que usualmente hacemos cuando estamos entrando en un brownfield, es juntar una red de seguridad de pruebas de caracterización, al menos alrededor de algunos de los módulos más críticos para el negocio o críticos para la misión. Entonces entiendes, OK, esto es una caja negra, así es como funcionaba antes. Curiosamente, encontrarás muchos errores en primer lugar. Pero luego también entenderás que este es el estado en el que debería estar antes de que toquemos a los agentes. Sí, es un buen recordatorio. Los humanos también cometen errores. También somos entidades no determinísticas. Exactamente.

Afortunadamente. Muy bien. El siguiente tema, hablando de la revisión de código. Así que usualmente tenemos un par de desarrolladores para front end y back end en un equipo para revisar el trabajo efectivamente. ¿Cómo funcionaría eso en un equipo de tres personas? Pregunta difícil de responder. Primero, comenzamos con un poco de historia y aprendiendo de mí mismo y haciendo esto por algún tiempo ya. Comenzamos con, como, ya no nos importan los lenguajes de programación. Y solo necesitamos experiencia e ingenio fundamental en ingeniería, como diseño de sistemas y entender cómo funcionan las cosas. Y todavía lo mantenemos como base, pero aún pensamos que se requerirá y necesitará alguna especialización. Y funciona bien, especialmente si tocas algo de front end, si tocas algunas bases de datos, si tocas algo de legado. Así que todavía hay mucha diferenciación en términos de esta especialización. Y se mantendrá. Eso significa que todavía necesitas esos en el equipo. Pero eso significa que necesitamos establecer un estándar más alto para asegurarnos de que esas personas sean efectivas está establecido.

Correcto. Pero no tengo una respuesta, como, completa para esta pregunta. Pero creo que el punto sigue siendo que todavía necesitas especialización. Todavía necesitarás especialización. Pero en gran medida con la IA puedes aprender rápido. Y si tienes este conocimiento fundamental, puedes aprender bastante. Por ejemplo, comencé a hacer bastante Rust, que es difícil de aprender. Lo aprendí de manera agentic en lugar de solo hacer .NET también. Así que no he hecho nada de .NET en el pasado. Ahora mismo estoy bastante seguro de que podemos pasar la entrevista para desarrollador senior, .NET developer.

Sí. Una última pregunta que abordaremos, y creo que se relaciona con esto. Si tienes esas especialidades, puedes incorporarlas en habilidades u otras cosas. Así que tu desarrollador de front end puede hacer una habilidad de revisión de front end que busque esas cosas particulares y similares que se puedan reutilizar. Y esto nos lleva a esta última pregunta para la que tenemos tiempo, que es, ¿tienes una perspectiva sobre ejecutar la revisión de PR localmente a través de una habilidad frente a un agente CI, agente dedicado, cosas así? Y eso es complementario para ser honesto. Es complementario porque necesitas asegurarte de que, en primer lugar, todavía está tu responsabilidad. ¿Verdad? No importa quién, alguien debería ser responsable del código y responsable de que todo el sistema sea confiable, correcto en la producción.

Así que todavía necesitas conocer la base. El cambio es como, cómo lo haces y cómo te aseguras de que esta base completa sea confiable con los estándares y no esté causando ningún daño. Y esa es toda la diferencia. ¿Verdad? Hay múltiples maneras de hacer esto de manera agentic, por supuesto. Pero hasta cierto punto, puedes usar los agentes para ser tu navegador y hacer el trabajo pesado por ti. Pero solo asegúrate de que esté en el nivel adecuado. Muy bien. Eso es todo el tiempo que tenemos. Vamos a hacer uno más. Gracias, Ilya.