Escalando Agentes de AI para Bases de Código de Producción: Patrones para Precisión y Eficiencia

Hola a todos. Hoy quiero hablar sobre las tres mejores prácticas de codificación de IA de 2026, especialmente en lo que respecta a grandes bases de código de producción. Y es particularmente importante cuando hablamos de grandes bases de código de producción, porque ahí es donde la IA realmente puede estropear mucho. Y si la IA estropea las cosas en producción, entonces tu aplicación no está produciendo y eso puede ser un problema. Así que hablemos de algunos consejos, herramientas y estrategias que podemos usar hoy en 2026 para comenzar bien cuando se trata de trabajar con grandes bases de código de producción y usar asistencia de codificación de IA.

Mi nombre es Saurabh Dhalal. Soy un defensor de desarrolladores aquí en Amazon Web Services en el equipo de la plataforma Agentic AI. Y te guiaré a través de estas tres mejores prácticas. Aquí está la agenda del día. Primero vamos a echar un vistazo a un ejemplo de una base de código de producción de código abierto con más de medio millón de líneas de código. Así es. Medio millón de líneas de código. Así que es una gran base de código. Y luego vamos a hablar sobre la única herramienta que debes usar al refactorizar bases de código, especialmente cuando se trata de bases de código de producción, para que no desperdicies tu dinero, tus tokens o tus créditos de IA. Y también reduces errores. Vamos a hablar sobre la diferencia entre la comprensión semántica de tu código frente a la coincidencia de texto por fuerza bruta y lo que eso implica y por qué es relevante para ti.

Y por último, vamos a hablar sobre trucos de gestión de ventanas de contexto para que obtengas las mejores salidas de tu IA y también cómo puedes aprovechar eso hacia el desarrollo impulsado por especificaciones cuando estás construyendo una nueva característica en una base de código de producción. Así que comencemos. Así que la base de código de producción de la que vamos a hablar hoy. Código abierto, repositorio ShadCN aquí. Hay dos repositorios que en realidad voy a cubrir de la página de GitHub de ShadCN. El repositorio de UI, que es muy, muy grande. Más de medio millón de líneas de código. Y luego la base de código de Taxonomy, que también es bastante grande. Esta va a ser una aplicación de pila completa. Así que quiero mostrar algo con una aplicación de pila completa, pero también algo con una base de código realmente, realmente grande, ya sea de pila completa o no. Así que comencemos. Echa un vistazo a un caso de uso. Entonces, ¿cuál es la herramienta secreta? La herramienta que resultará en la diferencia entre escribir los mismos prompts para refactorizar una base de código, el resultado sería ya sea 38 segundos para que ese prompt se complete sin errores o más de 10 minutos con múltiples errores y luego probablemente horas de depuración después de que esos 10 minutos hayan terminado debido a los errores. La herramienta secreta, LSP, Language Server Protocol.

Eso es lo que significa LSP. Es la misma herramienta que está en tus IDEs que cuando pasas el cursor sobre, por ejemplo, cuando paso el cursor sobre algún código. Como justo aquí. Correcto. Si paso el cursor sobre algún código, es la misma herramienta que podrá entender de qué tipo son mis ciertas variables, qué tipo de entradas y salidas tienen mis funciones. Cosas así. Así que eso es el language server protocol. Y eso es LSP.

Y vamos a hablar sobre cómo esta herramienta LSP es súper crítica cuando se trata de refactorizar una gran base de código de producción. Así que echemos un vistazo a lo que realmente implica. Así que con LSP, es la diferencia entre la comprensión semántica y AST, que significa comprensión del árbol de sintaxis abstracta de tu base de código, donde tu agente realmente entiende los símbolos y las conexiones de todos los archivos de código y funciones e importaciones, exportaciones, interfaces, clases, objetos en tu código como código real en lugar de solo coincidencia de texto por fuerza bruta de tu código, que es la búsqueda grep. Así que no queremos hacer la búsqueda grep. Queremos hacer comprensión semántica y AST. Y eso es lo que el agente de codificación habilitado por LSP nos permite hacer.

Así que echemos un vistazo a una demostración para renombrar este nombre de función comúnmente usado llamado CN a un nombre diferente. Así que una vez más, nuestra gran base de código de producción, voy a proceder a clonarla. Estoy en GitHub, chat CN UI. Este es el que quiero clonar. Así que procedamos a hacer git clone. Muy bien, así que he clonado una base de código de producción muy grande con más de quinientas mil líneas de código. Voy a entrar en esta base de código. Y luego PNPM. Vamos a instalar las dependencias usando PNPM install y una vez que eso haya terminado, echemos un vistazo a cómo el language server protocol hace una gran diferencia cuando se trata de refactorizar nuestra base de código. Muy bien, así que ahora que los paquetes han sido instalados, voy a limpiar mi terminal y estoy en Kiro I.D.E. Así que esta es una aplicación llamada Kiro. Puedes encontrarla en. Kiro dot dev. Es una plataforma de desarrollo de AI agentic. Así que bifurcación de V.S. code y tiene agentes aquí y en el terminal, estaré demostrando el concepto de language server protocol siendo usado por agentes para refactorizar una base de código.

Así que voy a estar en mi directorio de proyecto de trabajo y escribiré en Kiro CLI para entrar en una sesión con mi agente. Muy bien. Ahora estoy en una sesión de chat con mi agente y puedo pedirle. Renombrar la función de utilidad C a CNN usando LSP e inteligencia de código. Pero antes de hacer eso, necesito realmente inicializar la inteligencia de código con los protocolos del servidor de lenguaje LSP. Si hago slash code in it, cuando escribo este comando, inicializará este espacio de trabajo con el servidor de lenguaje TypeScript. Detectó automáticamente que este es un proyecto TypeScript. Y ahora si escribo slash code. Status, debería mostrar que ha sido inicializado. Tomó alrededor de 174 milisegundos inicializar el protocolo del servidor de lenguaje. Y esta es la misma herramienta que potencia nuestros IDEs para que. Nuestros IDEs entiendan mejor nuestro código. Por ejemplo, si paso el cursor sobre un archivo determinado como. Vamos a apps, components, cards, activity, go. Si paso el cursor sobre un símbolo determinado, mira toda esta información que el IDE ya conoce. Eso es gracias al protocolo del servidor de lenguaje.

Ahora, un agente si un agente también es capaz de tener esta característica y funcionalidad, entonces es mucho mejor para actualizar nuestra base de código o entender nuestra base de código debido a la comprensión semántica de nuestra base de código. Así que echemos un vistazo a. Lo que se necesitaría para renombrar la función de utilidad C a CNN usando LSP e inteligencia de código. Así que está usando esta herramienta incorporada en hero llamada code, que es una herramienta de inteligencia de código que hace comprensión semántica de nuestro código. Y voy a decirle que sí, confío en que haga esta operación. Ahora, hay múltiples si necesitas renombrar todos ellos, no lo haré. Sí. Así que voy a decir renombrar todos ellos. Así que veamos cuánto tiempo toma eso. Pero nota cómo es capaz de usar. Esta herramienta de inteligencia de código para identificar rápidamente los archivos que están involucrados con estas funciones y hay ciertos archivos que tienen. Cientos de ocurrencias. Ciertos archivos tienen una ocurrencia, ¿verdad? Así que puedes ver que varía según los archivos, pero ya ha terminado. Así que 22 segundos para renombrar todo eso.

Muy bien, genial. Así que echemos un vistazo a un ejemplo para comparar qué sucede si no usamos LSP. Así que tengo la misma base de código. Como te gusta, pero la nombré UI old way, que es la misma base de código, pero no habilitaré el protocolo del servidor de lenguaje en esta. Así que crearé una nueva sesión de terminal aquí y CD en UI old way. Y entraré en la sesión del agente escribiendo hero CLI.

Y en esta. Base de código, no la inicializaré con el protocolo del servidor de lenguaje, lo que significa que no haré slash code. No presionaré enter en este comando. OK, así que no tendrá habilitado el protocolo del servidor de lenguaje y le haré la misma pregunta.

Renombrar la función C y utility a CNN usando I will tell it sin usar LSP o inteligencia de código en toda la base de código.

Ahora, echemos un vistazo a la herramienta que se está utilizando aquí. Está usando la herramienta grab y va a buscar manualmente. Cada archivo y.

Va a ser un patrón de fuerza bruta de búsqueda y reemplazo cuando no se utiliza el protocolo del servidor de lenguaje. Así que le diré que sí. Confío en que haga los cambios. Y sí, parece que ya está viendo que podría ser un problema debido al gran número de archivos. Sabes, todo este uso está tratando de forzar su camino hacia la solución. Le diré que confío en que haga eso escribiendo T, permitir esta acción y un rato.

Mira esta ventana de contexto, por cierto, ya al 16% en comparación con antes. Mira eso. Ya habíamos terminado en el ejemplo anterior con el 7% de la ventana de contexto utilizada. Ya había renombrado todo. Aquí todavía está trabajando en ello. 16% casi el doble, 100% de uso extra de la ventana de contexto que está impactando tu dinero. Así que, ding, ding, ding. Eso probablemente debería captar tu atención. Está duplicando básicamente tu gasto de dinero sin LSP.

Y mira, todavía está haciendo cosas. Y esto va a tomar mucho tiempo, de hecho. Y para los propósitos de esta demostración, solo confía en mí cuando digo que esto tomará mucho, mucho tiempo. Más de 10 minutos más errores. Así que, ese es mi ejemplo para resaltar la diferencia entre agentes de codificación habilitados con LSP versus agentes de codificación no habilitados con LSP. Y dato curioso, esto también resultará en un montón de errores debido a la metodología de fuerza bruta que está usando al utilizar grep y el script de shell para simplemente buscar y reemplazar por fuerza bruta.

Así que, eso también te va a causar encontrarte con aún más problemas donde tendrás que corregir errores y gastar aún más tokens y créditos solo en arreglar algunos problemas. Mira, parece que ya se encontró con algunos problemas por sí solo. La definición de la función no fue renombrada. Está tratando de averiguar, déjame verificar qué pasó para solucionarlo. Y ahora está dando vueltas. Segundo intento de intentar hacer algo. Creo que ustedes entienden el punto. LSP es el camino a seguir en 2026 cuando trabajas con bases de código de producción a gran escala. Muy bien, parte dos. Hablemos sobre la gestión del contexto.

Para este, voy a usar el repositorio de taxonomy de ShadCNUI. La razón por la que voy a usar este es porque es una aplicación de full stack. Y quiero mostrarte una forma de trabajar con agentes de codificación AI en 2026, que implica una gestión efectiva de la ventana de contexto.

Así que, saluda a los subagentes. Entonces, ¿qué es un subagente? Voy a volver al IDE de Kiro aquí mismo para mostrarte aquí en la caja de chat que también puedes hablar con el agente a través de esta ventana de chat de la UI en lugar de solo el terminal. Y aquí, voy a demostrar el caso de uso de un subagente.

Así que, puedes pensar en un subagente como simplemente otro agente que puede ejecutarse en paralelo con otros agentes para realizar ciertas tareas. Así que, imagina que tuvieras que mirar la parte de front end de tu código y luego el código de back end y luego el código de la base de datos para hacer una revisión de seguridad de tu base de código. Bueno, podrías estar haciéndolo uno por uno, uno a la vez.

Una vez que termine de mirar el front end, luego miraré el back end, luego miraré la base de datos, y estoy recopilando contexto durante todo el proceso. Y para cuando haya terminado de mirar solo el front end, ya habrá utilizado gran parte de la ventana de contexto antes de llegar al back end. Y ahora el modelo de lenguaje grande, su ventana de contexto, como ya se está llenando, su eficiencia comienza a disminuir. Su productividad comienza a disminuir para cuando llega al back end.

Y para cuando llega a la base de datos, será realmente ineficaz. Pero, ¿y si te dijera que en realidad podrías dividir este trabajo en tres subagentes diferentes, donde cada agente estará especializado para un front end o el back end o la base de datos, y cada uno tendrá su propia ventana de contexto especializada para que no interfiera con la ventana de contexto del front end, no va a interferir con la ventana de contexto del back end o la ventana de contexto de la base de datos, para que todos puedan trabajar efectivamente en su parte de la aplicación. Eso es lo que harán los subagentes.

Así que aquí en la sesión de chat, le voy a decir que mire el repositorio de taxonomy, mire la base de código y use subagentes para hacer una seguridad para el front end, back end, y asimile todos los hallazgos en un documento para mí. Así que lo que va a hacer es que Kiro es mi agente que va a usar, ya sabes, en este caso, cloud Opus 4.5. Y en realidad está invocando múltiples agentes. Así que en lugar de usar la ventana de contexto completamente para el front end, back end y base de datos, y acumular más contexto a medida que llega a la capa de base de datos, en realidad está invocando tres subagentes diferentes.

Así que hay uno aquí, aquí está el segundo para el back end. Y luego aquí está el tercero para la base de datos. Y lo genial es que cada una de estas instancias de los subagentes, como puedes ver, donde están las cajas de colapso, todas tienen su ventana de contexto individual, que no está impactando esta ventana de contexto justo aquí. Por lo tanto, como este es el agente de revisión de seguridad del front end, trabajando en el aspecto del front end de la base de código, esa ventana de contexto no va a impactar la ventana de contexto del agente del back end que está haciendo la revisión de seguridad para mi parte del back end de la base de código, como rutas de API y autenticación del back end.

Y de manera similar, el agente de la base de datos no está usando una ventana de contexto de los otros dos agentes, tiene su propia ventana de contexto solo para la revisión de seguridad relacionada con la base de datos. Y otra gran cosa es que están funcionando en paralelo. Así que no tengo que esperar a que el front end termine, y luego hacer el back end, y luego hacer la base de datos. Eso es tres veces la cantidad de tiempo que estarías usando versus estos tres que están funcionando en paralelo, y parece que el back end ya ha terminado. El agente de la base de datos ya ha terminado, y luego el agente del front end acaba de terminar ahora.

Así que todos terminaron en momentos ligeramente diferentes, pero no tuve que esperar a que uno terminara antes de que el siguiente tuviera que ejecutarse. Están funcionando en paralelo, por lo que están funcionando de manera asíncrona. Y como desarrolladores, nos encanta la palabra async. Así que ahí lo tenemos. Y ahora, basado en todos los hallazgos de estos tres subagentes, está creando un documento de revisión de seguridad para mí. Y esta es una gran manera de gestionar mi ventana de contexto cuando estoy haciendo una revisión de seguridad sobre una gran base de código de producción. Y digamos que quiero hacer actualizaciones basadas en la revisión de seguridad. Bueno, tengo este documento que resalta toda la información y hallazgos que hemos descubierto. Así que echemos un vistazo a lo que hemos descubierto hasta ahora. Haré una vista previa abierta. Y echemos un vistazo a los hallazgos. Así que sí, hay algunos hallazgos de seguridad que necesitan ser abordados en esta base de código de producción. Es una base de código de código abierto. Así que voy a contribuir a esta base de código de código abierto ayudando a mejorar su seguridad. Así que no hay limitación de tasa implementada en el back end. Faltan políticas de seguridad de contenido. Bien, genial. Así que con todos estos hallazgos, un gran enfoque para realmente crear una nueva característica e implementar esta nueva característica usando AI Coding Assistant es tomar estos hallazgos y generar lo que se llama un spec a partir de ellos. Así que esa será la siguiente parte. Así que hablamos sobre la gestión de la ventana de contexto. Saludamos a los subagentes y ellos nos saludaron de vuelta.

Y nos ayudaron a obtener mucha información sobre lo que necesita mejorarse en términos del punto de vista de seguridad para nuestra aplicación. Y ahora podemos asegurarnos de que nuestros agentes se alineen con nuestros requisitos desde el principio antes de que comience a actualizar esta aplicación. Esto se llama desarrollo impulsado por especificaciones, donde vamos a generar el diseño y los requisitos y desglosarlos en tareas basadas en lo que queremos actualizar sobre esta aplicación. Y todo se escribirá en Markdown para que podamos entender completamente qué cambios se llevarán a cabo antes de permitir que el agente realmente trabaje en la base de código. Esto permite muchos beneficios que cubriremos ahora.

Así que abriré una nueva sesión en el chat y le pediré que vaya al modo de especificación donde realmente creará un documento de diseño completo para actualizar la aplicación basado en la revisión de seguridad. Así que voy a copiar la ruta aquí. Y voy a generar una especificación para actualizar esta aplicación para que incorpore la revisión de seguridad. Así que lo que Kiro va a hacer es que va a mirar todos estos cambios propuestos y actualizaciones para la aplicación. Y va a generar un documento altamente detallado llamado documento de requisitos PRD que delineará al agente. Los pasos exactos que necesita tomar para pasar de nuestra base de código actual a la base de código actualizada que incorpora estos hallazgos de seguridad. Y mejores prácticas.

Muy bien, así que echemos un vistazo al primer documento que se creó. Este es el documento de requisitos de nuestra especificación para nuestra nueva versión de la aplicación de taxonomía. Aquí, Kiro realmente proporcionará palabras muy concretas como glosario para que sepa qué términos significan qué, y pueda referirse a estos términos para entender sus significados desde el principio. Esto es genial para que un equipo también lo revise para que también podamos aclarar cualquier malentendido aquí desde el principio antes de que realmente tengamos al agente comenzando a trabajar en tareas para actualizar el código. Una vez que esto sea revisado por su equipo, como ciertos requisitos que se van a implementar como limitación de tasa y criterios de aceptación o formas en que el agente probará para asegurarse de que se cumpla este requisito.

Así que el limitador de tasa deberá limitar las solicitudes API autenticadas a 100 solicitudes por 60 segundos por usuario. Así que probablemente generará algunas pruebas que realmente cuantificarán esto o llevarán esta declaración cuantificada a una prueba real que pueda medir y validar. Así que note que el lenguaje aquí es muy cuantificable y muy específico para que el LLM no tenga que adivinar con ninguna incertidumbre y falta de claridad.

Así que digamos que revisamos esto con el equipo y hemos actualizado este documento en consecuencia. Luego puede pasar a la fase de diseño y tomará este documento y luego generará un documento de diseño donde mostrará cómo implementará estos requisitos. Tal vez tenga algunos ejemplos de fragmentos de código. Así que echaremos un vistazo a eso. Muy bien, parece que ha creado el documento de diseño, que es la siguiente parte de nuestro enfoque de desarrollo impulsado por especificaciones, donde nuestros requisitos se presentan en ejemplos reales de cómo vamos a implementar esos requisitos.

Así que se vuelve aún más específico en cuanto a incluso fragmentos de código que va a intentar usar. Así que como desarrollador y como equipo, podemos mirar estas implementaciones y enfoques. Y verificar si este es el tipo de mejor práctica que queremos usar para la implementación de los requisitos. Y una vez más, nos alinearemos en este documento antes de pasar a la siguiente fase para que el agente esté completamente alineado con nuestros requisitos y nuestra forma de implementar esos requisitos en el documento de diseño.