La Generación Rápida de Código es Fácil. El Cambio Seguro a Nivel de Sistema No lo Es.

Hace dos años, la pregunta era ¿pueden los agentes escribir código? Hoy, la pregunta es ¿puede tu base de código sobrevivir a ellos? Esta charla trata sobre la segunda pregunta. Mi nombre es Bart. He pasado los últimos 15 años como ingeniero de software en una variedad de roles, y para ser completamente honesto, también soy el tipo que construyó Fellow, la herramienta que mencionaré un par de veces esta noche.

Para mí, la pregunta interesante ha cambiado. Conseguir que un agente produzca un div funcional está básicamente resuelto. La parte difícil es mantener una base de código grande coherente mientras los agentes vierten código en ella más rápido de lo que nosotros mismos lo hacíamos. ¿Recuerdas cuando discutíamos sobre tabs versus espacios? Eso parece que fue hace una eternidad. La velocidad con la que los LLMs generan código cambia mi trabajo. Quiero describir los resultados del usuario y dedicar mi tiempo al comportamiento del producto. Casos extremos y compensaciones.

Las conversaciones que aún necesitan un humano. Y lo que no quiero es cuidar al agente con las mismas instrucciones de calidad en cada solicitud. Evitar duplicaciones, limpiar exportaciones no utilizadas, mantener la complejidad baja, escribir pruebas que signifiquen algo. Esas reglas deberían ser parte del sistema, no parte de mi solicitud. Así que este es el flujo de trabajo del que trata esta charla. El desarrollador describe la intención, el agente cambia el código, la cadena de herramientas local detecta desviaciones de calidad, y el humano revisa salidas, evidencias y compensaciones. Vamos a recorrerlo.

Este es el tipo de solicitud que realmente quiero escribir. Se trata del usuario, se trata del comportamiento, da criterios de aceptación, y deja la puerta abierta para preguntas cuando el comportamiento del producto es ambiguo. Observa lo que falta. Nada sobre cómo estructurar la implementación. No extraer el hook, no tocar el archivo barrel, no cometer errores en mayúsculas. El agente debería inspeccionar la base de código y el flujo de pago, en este caso, averiguar cómo ya funciona el formato de dinero, hacer el cambio y ejecutar las verificaciones.

El sistema de calidad debería detectar problemas durante el ciclo del agente, automáticamente, cada vez. Ahí es donde entran las herramientas determinísticas, porque los agentes usualmente tomarán el camino más corto hacia un comportamiento funcional, y eso es útil, pero en un repositorio grande, también es como comienzan los problemas. El agente está tratando de satisfacer las solicitudes. Honestamente, eso es lo que hace cada nuevo empleado también.

Para nuestro futuro de ahorros, por ejemplo, la implementación funcional más rápida podría ser escribir un formato de dinero o directamente en el componente de checkout, o agregar una condición más a un componente que ya era una declaración if crítica, o importar desde cualquier archivo que tenga un nombre prometedor, incluso si ese archivo pertenece a un servidor local de node y contiene secretos del lado del servidor. Y aquí está la parte incómoda. La demo se ve genial. Los usuarios utilizan sus ahorros, el PR está en verde, todos aplauden, pero mientras tanto, la base de código empeoró un poco, y nadie lo notó porque cada cambio individual parece perfectamente aceptable.

Y este no es un problema nuevo. La investigación sobre la calidad del código ha estudiado olores, complejidad y mantenibilidad durante años, y sigue llegando a la misma conclusión. Estos problemas generan errores. Los agentes generan la misma categoría de problemas de mantenibilidad. Solo que los generan mucho más. Solo que los generan mucho, mucho más rápido. Así que el ciclo de retroalimentación tiene que ser más rápido también. Mantén este ejemplo de checkout en mente. Por cierto, vamos a ver este cambio exacto de nuevo más tarde, atrapado in fraganti por nuestras herramientas.

Ahora, la primera respuesta a la que podrías llegar es que deberías escribirlo en el archivo de reglas en el CloudMD o los agentes MD, y los archivos de reglas son realmente útiles. Cada repositorio debería tener un agent.md, un Cloud.md, o cualquier formato de memoria de proyecto que soporte tu agente. Ahí es donde vive la pila, los comandos, las convenciones, las armas de comida conocidas, la intención de la arquitectura, pero eso es contexto. Un archivo de reglas es como la charla de seguridad en un avión. Es información realmente importante entregada en cada vuelo y absolutamente ninguna garantía de que alguien la siga cuando las cosas se ponen emocionantes.

Así que los propios documentos de Cloud explican los modos de falla. El contenido de CloudMD se entrega como un mensaje de usuario. Cloud intenta seguirlo, y no hay garantía de cumplimiento estricto. Los mismos documentos también dicen que cualquier cosa que deba ejecutarse en un punto específico, como antes de cada commit, debería implementarse como un hook porque los hooks se ejecutan en eventos de ciclo de vida fijos, independientemente de lo que el modelo decida hacer. Esa es la distinción en la que se basa toda esta charla. Los archivos de reglas hacen que el agente esté mejor informado. Las verificaciones determinísticas hacen que el flujo de trabajo sea exigible.

Si una regla necesita ejecutarse cada vez, no pertenece a la prosa. Pertenece a una herramienta, un hook, o una puerta. Entonces, ¿qué verificaciones? Definí cuatro capas diferentes. Está TypeScript, que es para la corrección de tipos, pero incluso tiene opciones como no unused locals y no unused parameters. También es útil para la calidad del código, pero en un ámbito muy específico. Y Linting verifica la política local, las reglas del framework, por ejemplo, convenciones de nomenclatura, APIs restringidas, convenciones de proyecto, y las pruebas verifican el comportamiento que pensamos explícitamente. Pero Fellow se encuentra en una capa diferente. Consistencia basada en el código alrededor del cambio, archivos y exportaciones no utilizados, lógica duplicada, puntos críticos de complejidad, dependencias circulares, violaciones de límites, higiene de dependencias.

Así que TypeScript protege los tipos, Linting protege las reglas locales, y las pruebas protegen el comportamiento esperado. Y al final, Fellow intenta proteger la base de código de desviaciones estructurales mientras todo lo demás se analiza técnicamente. Permíteme clasificar correctamente a Fellow. Es un analizador determinista estático de la base de código y una puerta de calidad de código de cambio para TypeScript y JavaScript. Lo describo como una inteligencia determinista de la base de código. Está escrito en Rust nativo, por lo que es extremadamente rápido, sin configuración, y sin IA dentro del analizador. Es un analizador determinista estático de la base de código y sin IA dentro del analizador. Y esa última parte es mi favorita. Y es importante para esta charla. El agente de codificación que estoy usando y que todos están usando es probabilístico. Eso está bien. Ese es su encanto. Pero si mi puerta de calidad también está vibrando, entonces no tengo una verificación. Tengo dos opiniones. El agente propone, y algo aburrido y determinista debería verificar. Aburrido es una característica aquí. Quieres que tu puerta de calidad sea aburrida. La parte construida para este ciclo es el comando de auditoría. Una puerta de riesgo de PR para códigos generados por humanos y por IA. Combina archivos cambiados, hallazgos de código muerto con complejidad de archivos cambiados, y hallazgos de duplicación y emite un veredicto. Aprobar y advertir, salida cero, y fallar, salida uno. Y nota el alcance. Son solo archivos cambiados. Y eso no es un detalle de optimización. Eso es supervivencia. Si una herramienta es lenta, el agente la evitará. El desarrollador también la evitará. Y termina ejecutándose una vez por noche en CI, donde nadie la lee. O peor, en algún tablero de control. Una verificación solo cambia el comportamiento si es lo suficientemente rápida para vivir dentro del ciclo.

Ahora, podrías preguntar, ¿por qué el lenguaje simplemente no hace esto? Y algunos ecosistemas lo hacen. Go directamente se niega a compilar si tienes una variable o importación no utilizada. Rust tiene lints de código muerto incorporados. Y Zig incluso convierte un local no utilizado en un error de compilación. Pero TypeScript y JavaScript son gloriosamente flexibles. Lo cual es una gran parte de por qué siempre han sido tan productivos. Y también significa que mucha estructura vive fuera del compilador. Puntos de entrada del framework, archivos barril, cambio de re-exportación, alias de tabla, límites de monorepo.

TypeScript no te dirá que una exportación pública murió silenciosamente en un refactor generado. El ecosistema ya tiene herramientas especializadas. KNIP para código no utilizado, dependency cruiser para reglas de dependencia, JSCPD para duplicación. Pero el ángulo de Fellowes es combinar estas verificaciones de consistencia basadas en código en una herramienta rápida y hacer que la salida esté lista para el agente. Así que este es el ciclo que realmente ejecuto. El desarrollador comienza con la intención del producto. El agente cambia el código. Y el entorno local verifica los resultados. Mientras el agente todavía tiene la tarea en su cabeza.

Verificación de tipos, lint, pruebas relevantes, análisis de código cambiado y los resultados van directamente de vuelta al agente. CI todavía importa. Es la capa de confirmación compartida para el equipo. Pero el ciclo de reparación debería ocurrir antes. Mientras la corrección no cueste nada. Hay pocas cosas peores que un lanzamiento bloqueado por un CI fallido. Y los hooks son el mecanismo aquí. Comandos de shell que se ejecutan en un ciclo de vida fijo en puntos de ciclo de vida fijos. Así que ciertas cosas siempre suceden en lugar de depender de que el LLM sienta ganas de hacerlas. Fellowes envía esto como una configuración de un solo comando. Lo que obtienes es una puerta de uso previo de herramientas en la herramienta bash del agente. Piénsalo como un portero parado en la puerta de git commit.

El agente se acerca, el portero ejecuta auditorías de Fellow, veredicto completo, el commit está bloqueado. Y el portero le entrega al agente una lista completa en JSON de razones por las que no va a entrar esta noche. Directamente de vuelta a la conversación. Y aquí está la parte hermosa, el agente no discute. No se enfurruña. Simplemente arregla su atuendo y regresa dos minutos después mientras el contexto aún está fresco.

Y el mismo instalador también puede escribir un simple hook de pre-commit de git para humanos. Mismo bar, ambas especies. Así que recuerda el atajo de checkout de antes en la presentación? Aquí está, atrapado. El agente escribió su propio formateador de dinero en el archivo de descuento y dejó una exportación no utilizada atrás. La función funciona, pero la auditoría falla. En la parte superior, un veredicto. Este dice fallo, así que el portero de la diapositiva anterior bloquea los commits.

Y luego está la atribución, el resumen de toda la historia. El modo de puerta es solo nuevo, uno introdujo la detección de código muerto, uno introdujo el grupo de duplicación, cero fueron heredados. La herramienta separa lo que este cambio causó de lo que ya estaba por ahí. Luego los hallazgos se agrupan por tipo, símbolo y la línea. Y cada hallazgo lleva un array de acciones. La exportación no utilizada está marcada como autofijable y la duplicación sugiere extraer una función compartida. E incluso hay un comando de supresión listo para usar para cuando un hallazgo resulta ser intencional.

Y luego los siguientes pasos, mi parte favorita para los flujos de trabajo de agentes, comandos de evidencia ejecutables de solo lectura para cuando los necesiten. Aquí sugiere rastrear la exportación antes de eliminarla. Y nota lo que la herramienta no hace. Nunca edita tu código. Desliza la evidencia sobre la mesa y deja que el agente se encargue de la solución. ¿Y por qué solo nuevo? Bueno, toda base de código real tiene una historia. Parte de ella es de 2019, escrita por un colega que se fue hace tiempo con un comando de no tocar encima.

Si la puerta bloqueara todo eso desde el primer día, nunca se enviaría nada. Así que, todo eso se siente solo en hallazgos introducidos por los conjuntos de cambios actuales. Los hallazgos heredados aún aparecen como contextos anotados como introducidos falsos. Y si te sientes valiente, la puerta en todos los modos falla en todo en los archivos de cambio. Eso es lo que hace que el bucle sea práctico. Bloquear primero el nuevo desvío, mejorar la calidad con el tiempo. Mantener al agente en movimiento sin permitirle añadir más degradación.

Entonces, ¿por qué pasar por todo esto? Por lo que sucede en el momento de la revisión. Si el agente genera más código y reviso cada línea con igual intensidad, no he ganado nada. Solo he movido el cuello de botella malo de escribir el código a revisarlo. Y curiosamente, para mí personalmente, revisar es mucho más difícil que escribir. El objetivo no es mirar menos código por pereza. El objetivo es obtener mayor confianza a través de mejor evidencia. Todavía soy dueño del cambio. Todavía reviso las partes arriesgadas. Pero la revisión comienza desde una señal más fuerte.

¿La característica resuelve el problema del usuario? ¿Cubrimos los casos extremos que importan? ¿El agente tomó silenciosamente una decisión de producto que debería haber regresado a mí? ¿Y tocó un límite sensible? Salió de TypeScript y las pruebas pasan. Y esta es la dirección más amplia de todo el campo. La ingeniería con agentes se convierte en dirigir sistemas que producen código. Las cosas que mantienen su valor son la propiedad, el gusto, el contexto local del repositorio, estrictas barreras de protección y bucles de retroalimentación rápida.

La tipificación nunca fue el punto. Mirar menos código solo funciona cuando la evidencia mejora. Para eso es la capa determinista. Así que, terminemos esto. La generación rápida de código está aquí. Codificación de fibra, ingeniería de bucles, cualquier sabor, y cuando lo pruebas, no volverás a escribir bucles a mano. El siguiente problema, el problema realmente interesante, es mantener las bases de código coherentes mientras la velocidad de generación sigue aumentando. Como ingeniero, quiero solicitar al nivel de la intención del usuario. Y las compensaciones arquitectónicas. Quiero pensar en los problemas difíciles. Quiero agentes manejando los detalles de implementación. Y quiero sistemas deterministas haciendo cumplir las reglas de calidad que nunca deberían depender de la disciplina de los prompts.

TypeScripts sigue verificando tipos, Linting sigue verificando reglas locales, las pruebas siguen verificando el comportamiento esperado, y para mí ahora, Velo verifica la consistencia en toda la base de código. Los hooks retroalimentan los fallos al agente mientras la solución sigue siendo barata, y CI confirma el estado final para el equipo. Y el humano revisa el resultado, la evidencia y las compensaciones que se están haciendo. El agente escribe, el bucle local verifica. El humano decide, y con un poco de suerte, git blame seguirá apuntando a un humano en el futuro previsible.

Gracias. Muchas gracias, Bart, por tu sesión. Fue realmente interesante aprender sobre tu producto, sobre tu enfoque, cómo hacer que nuestro trabajo con agentes de IA sea un poco más predecible, diría yo. Por supuesto, es como una súper simplificación, pero aún así, creo que cualquier oportunidad de tener alguna parte determinista de los flujos de trabajo actuales fuertemente infundidos con agentes de IA siempre es buena. Al menos esto es… En mis sesiones sobre, por ejemplo, optimización de tokens y optimización de costos de tokens, siempre recomiendo inyectar tantas como sea posible estas barandillas deterministas. Todos los verificadores de tipos, linters, uniters, todo. Eso previene desviaciones en su etapa más temprana. Así que no vamos en la dirección totalmente equivocada y el precio de un error es el más bajo.

Entonces, ¿cuál fue la historia detrás de este producto? ¿Por qué decidiste crear algo así? ¿Fue una necesidad práctica o solo una idea? ¿Cómo iniciaste esto? Esa es una buena pregunta. Al principio, realmente estaba trabajando con los linters. Así que, noté… Creo que la primera vez que realmente vi el gran beneficio de esto fue cuando Cursor, en aquel entonces, agregó algo que cada vez que editabas un cursor o el LLM editaba código, inmediatamente ejecutaba el linter.

Y fue una diferencia tan grande en calidad para mí porque ahora el código generado realmente se ajusta a cómo quería que se viera, cómo funciona. Y así, eso realmente me enseñó los valores de esos análisis estáticos. Y a medida que pasaba el tiempo, pensé, bueno, quiero ver hasta dónde puedo llevar esto. ¿Cómo puedo incorporar más herramientas? Así que descubrí KNIP, que hace un muy buen trabajo al detectar las partes de código muerto. Y también noté que estaba duplicando código por todas partes. Así que agregué JS CPD, que hace la parte de duplicación. Y todo eso realmente mostró cómo todas estas herramientas estaban ayudando al agente a escribir mejor código. Pero noté que cuando estaba todo en esas diferentes herramientas y en ese momento, esas herramientas eran un poco más lentas. Así que pensé, bueno, tal vez pueda construir algo que haga lo mismo que estas herramientas hacen, pero de una manera más rápida para que pueda ponerlo dentro del bucle y pueda obtener retroalimentación más rápida. Así es como comencé. Y ahora solo estoy pensando en, bien, ¿cómo puedo hacer que esta herramienta haga aún más cosas que los linters no pueden realmente hacer porque están mirando archivos individuales? Así que, sí. Eso es realmente bueno. Quiero decir, la comunidad de desarrolladores necesita más historias como esa, ¿verdad? Algún problema del mundo real, un poco de curiosidad y un gran potencial para construir herramientas en estos días, ¿verdad? Revisé tu repositorio. Veo que usas activamente inteligencia artificial para construir esto, ¿verdad? Hay muchas habilidades, agentes personalizados, todo, ¿verdad? Sí.

Esta es una base de código Rust y Rust tiene más de estas cosas que Fallow realmente hace. Así que, sí. Esa es también una buena motivación para avanzar en algún lenguaje de programación hacia las capacidades de la comunidad de Rust. Desarrollar otro lenguaje de programación desde una dimensión particular, por supuesto.

Y, sí. Tenemos muchas preguntas, veo. ¿Qué hacer con los hallazgos de falsos positivos?

Para trabajar con falsos positivos, básicamente hay dos maneras. Una es que puedes suprimir hallazgos. Así que, si realmente lo estás usando en algún lugar, es como ESLint. Está ESLint Disable. Está Fallow Disable. O puede ser que una cierta categoría de hallazgos sea algo que quieras desactivar juntos. Así que, también hay una opción para hacer eso. Es posible que sea un error real en Fallow. Así que, si ese es el caso, simplemente lanza un problema en GitHub. Y, sí. En algunos casos, debido a la forma en que Fallow funciona, intenta detectar el framework que estás usando. Y algunos de los falsos positivos se deben a cosas de configuración interna del framework. Así que, la mayoría de los frameworks más grandes, como React, Angular, Vue, todos esos están cubiertos. Pero si usas algo un poco menos, algo un poco menos utilizado, puede ser debido a cosas que los frameworks hacen que muestran falsos positivos. Sí, y, sí, amigos. Este es un proyecto de código abierto. Siéntete libre de enviar un pull request. Tal vez sea incluso una mejor opción hoy.

Así que, la siguiente pregunta es, primero, personalmente, no soy un gran fan de la comparación uno a uno de los productos. Pero, de todos modos, ¿cómo se compara esto con Sonar, si usas este? Sí, sí. He trabajado en empresas que usan Sonar, y creo que Sonar es una gran herramienta que hace muchas cosas similares. Sonar es mucho más grande, más amplio, cubre todos los idiomas. Pero creo que la principal diferencia es que Sonar está más orientado a ser un panel. Así que es algo que miras después de haber creado tus pull requests. Informa hallazgos en tu PR, y puedes mirar el panel. Pero para TypeScript, JavaScript específicamente, mi experiencia fue que las herramientas para ejecutarlo localmente no son tan buenas. Eso fue hace un tiempo que lo usé por última vez. Así que podría haber mejorado. Pero la única forma real de ver todos esos hallazgos es después mirar el panel. Y quería crear algo y usar algo que inmediatamente responda a este tipo de preguntas y pueda inmediatamente canalizar sus resultados de vuelta al agente para que pueda arreglarse a sí mismo.

Sí, creo que eso es un consejo práctico para las personas que usan Sonar. Solo dale una oportunidad a follow. Tal vez combines estos productos, tal vez tomes una decisión técnica diferente. Creo que es una idea absolutamente buena experimentar con diferentes productos. Una pregunta un poco técnica de Brad. ¿Qué proceso te gusta usar para desarrollar planes e intenciones antes de enviar la implementación a un agente? Sí, esa es una buena pregunta. No creo que esto esté realmente relacionado con Fellow en sí porque trato de mantener, como mostré, la intención sobre la característica real que quieres y no tan específicamente sobre cómo debería implementarse. Pero en cuanto a mi proceso, trato de poner mucho esfuerzo en escribir los planes. Así que hay, creo que se llama Pocock, Matt Pocock, quien tiene un repositorio por ahí con muchas habilidades diferentes relacionadas con el trabajo con IA. Y creo que mi configuración se parece un poco a lo que él tiene, que es mucho esfuerzo en obtener los planes correctamente. Trato de eliminar todas las conjeturas del agente para que tenga un plan realmente específico sobre la característica que realmente quieres. Así que esto es tanto para construir Fellow como para construir el otro trabajo que hago. Así que una vez que el agente comienza, el plan está realmente bien definido y tanto como quiero que esté. Sí, creo que lo que compartiste es una recomendación general muy moderna y actualizada dividida en múltiples pasos, investigar, planificar y luego implementar. A veces puedes omitir la investigación, pero planificar e implementar, sí, deberían estar algo separados. Sí, una pequeña cosa es que también tengo algo que llamo el panel de revisión, que son un par de agentes diferentes que tienen una persona, que modelo alrededor de los usuarios de la herramienta. Así que puedo activarlo una vez que tengo mi plan listo. Y a menudo me dan retroalimentación sobre cómo reaccionarían las personas reales a ciertos cambios. Así que me ayuda a hacer algo solo con un grupo de personas que en realidad no están allí, pero en espíritu. Exactamente, exactamente. Y de nuevo, siempre tengo curiosidad sobre cómo diferentes desarrolladores usan herramientas de IA de manera diferente en el caso de repositorios de código abierto. Así que sí, todos, amigos, pueden ir y ver qué tipo de habilidades, qué tipo de agentes personalizados está usando Bart en este proyecto en particular. Siempre perspicaz, diría. Definitivamente, encontraré algo para mí. La pregunta sobre la portabilidad, así que esto es específicamente una cosa de PipeScript, cosa de JavaScript, ¿verdad? ¿Podemos aplicar algunas técnicas, tal vez de alto nivel, bajo nivel a otros lenguajes de programación y arquitecturas? Sí, hay dos lados en esto, creo, o al menos dos lados. Un lado es algo que Fellow llama salud, que razona sobre qué códigos son bien mantenibles. Y esos principios son de personas que son mucho más inteligentes que yo, que tienen doctorados, etcétera. Y esos, creo, puedes aplicarlos a cualquier lenguaje. Pero también hay, recientemente, hubo alguien que creó una solicitud de característica de problema sobre una cierta métrica que pensó que era una buena idea para agregar a Fellow, que realmente investigué e intenté hacer que encajara. Pero fue, creo que fue Elcom 4, para las personas que saben sobre eso.

Pero simplemente no encajaba realmente en PipeScript porque estaba castigando clases que tenían ciertos métodos. Pero en la forma en que usamos PipeScript para la web, tenemos Angular y NestJS, por ejemplo, que añaden muchos métodos a una clase que no son, fueron creados por el framework. Así que, sí, realmente no funcionó, pero las cosas que están ahí, creo, son portables a otros lenguajes. Y creo lo mismo para las cosas de arquitectura, que Fellow intenta mantener. Los valores predeterminados que están aquí son específicos de cómo los proyectos de PipeScript para la web están configurados actualmente. Pero todos los modelos como MVC, etc.

, puedes modelarlos con ciertas configuraciones de Fellow. Y como en el otro lado, portarlo a otros lenguajes como herramienta en sí, eso fue un poco más difícil porque gran parte del trabajo que hace Fellow se basa en construir un gráfico de tu base de código. Y para poder hacer eso, necesita saber mucho sobre los puntos de entrada. Entonces, ¿dónde comienza tu aplicación? Y esos puntos de entrada se basan mucho en cosas del framework. Así que para React, NestJS, Angular, todos tienen archivos específicos, ubicaciones. Así que Fellow sabe, esta es la aplicación de NestJS. Tenemos páginas. Esos son puntos de entrada, y podemos seguir el gráfico a lo largo de ese camino. Y sí, otros lenguajes hacen esas cosas de manera diferente. Y construir el gráfico en sí se basa en los paquetes Oxium Rust, crates, debo decir. Y esos solo funcionan para PipeScript. Así que los principios generales son portables a otros lenguajes.

Pero la herramienta en sí, por el momento, no. Sí, justo. Creo que es una gran oportunidad para las personas que nos ven ahora, tal vez si quieres tener algo así para tu lenguaje de programación favorito, simplemente adopta estas ideas de alto nivel, una especie de meta-Fellow, ¿verdad? Pero aterrízalo, ponlo en práctica en tu propio lenguaje de programación de tu elección.

Y la última pregunta del evento de hoy, específicamente quiero tener esta de Alejandro, nuestro participante más activo de hoy en la sesión de preguntas y respuestas. Gran trabajo, Alejandro. Y se trata de esta elección siempre presente, continuar la sesión existente o comenzar una nueva. Entonces, ¿cuál es tu opinión sobre, es mejor agregar la entrada de la corrección en el mismo contexto, o es mejor iniciar una nueva sesión para evitar el fraude de contexto, tal vez también para no inflar costos, etc.? Entonces, ¿cuál es tu opinión al respecto? Sí, creo que esta es una pregunta realmente difícil, Alejandro. Y realmente no sé cuál es la mejor respuesta para esto.

En el pasado, y creo, no sé cómo comenzó, pero todos estaban como, si tienes un 50% restante en tu ventana de contexto, puedes hacer otra pregunta. Si tienes menos, necesitas comenzar una nueva sesión. Pero en el momento en que Opus y Tropic fueron a una ventana de un millón de tokens, dejé de prestar atención a eso. Así que ahora siempre termino la sesión en la ventana de contexto actual con la idea de que el agente tomó una cierta decisión basada en una suposición. Y si el agente todavía sabe por qué hizo algo, lo cual podría haber sido algo que le pediste que hiciera, también puede saber mejor cuándo detenerse y preguntarte si esto es realmente lo que quieres, en lugar de cuando estás en una sesión nueva, todo ese contexto, por supuesto, se pierde, lo cual es por un lado, la razón por la que tomaste la decisión de comenzar una nueva sesión, para obtenerlo en un estado mental fresco. Así que sí, creo que es mejor en su mayoría mantenerlo en el contexto actual, a menos que haya... En general, la respuesta es, depende.

No quería decir que depende. Podría ser el tercer problema más complejo en la ingeniería de software, como nombrar, validación de caché, y comenzar o no comenzar una nueva sesión. Muchas gracias, Bart. Todos, encuentren a Bart en LinkedIn, encuéntrenme en LinkedIn, mantengámonos conectados. Muchas gracias. Fue un gran placer ver tu sesión y tener una conversación contigo. Gracias. Gracias.