De 8 años a 6 meses: Orquestando agentes de IA para la refactorización a gran escala

Vamos a jugar un juego. Vamos a jugar Jenga. Pero nuestro juego va a tener un conjunto de reglas un poco diferente. Vamos a construir una torre durante una década. Vamos a tener algunos de los bloques pegados entre sí y algunas de las torres van a estar atadas con cuerdas.

Esta es nuestra realidad diaria porque hemos estado construyendo nuestro monolito del lado del cliente durante una década ahora. Tiene más de 10,000 selectores, acciones, reductores, más de 40,000 archivos y, por supuesto, más de una década de trabajo. Queríamos desesperadamente descomponerlo. Y lo estimamos. Decidimos que nos llevaría más de ocho años de trabajo hacerlo. Eso no es realista para nosotros.

Pudimos aprovechar la IA para hacer todo por nosotros. Y estamos aquí para contarles la historia de cómo lo hicimos. Mi nombre es Amit. Soy un líder técnico en Monday. Y yo soy Alon. Y soy un líder de equipo en Monday. Y este es MorphX, nuestra herramienta de IA que está descomponiendo nuestro monolito del lado del cliente día y noche. Y para darles un poco de contexto sobre de dónde viene este proyecto, permítanme contarles unas palabras sobre Monday.

Entonces, Monday es una empresa de software global que ayuda a los clientes a escalar su impacto comercial y expandir lo que los equipos pueden entregar, y ahora con una plataforma de IA para que agentes y personas trabajen juntos. Y antes de hablar sobre el monolito de Monday, permítanme contarles un poco sobre qué tipo de aplicación web es Monday. No es una aplicación de páginas triviales. Entonces, imaginen una página y añadan algunos micro-frontends a ella y luego añadan un micro-frontend para la navegación y algo de contexto aquí y un estado pesado allá.

Además de todo eso, las sesiones tienden a durar mucho tiempo en Monday. Y las pestañas tienden a permanecer abiertas durante varios días, durante tres o más días con mucha interacción y muchas dependencias entre todos estos componentes y micro-frontends. Así que nuestro lado del cliente es una pieza de software sofisticada y compleja que se ejecuta en tu navegador y algunas de sus dependencias y servicios han sido construidos y mantenidos durante más de diez años con muchos desarrolladores de Monday y desarrolladores externos contribuyendo con código creando esta enorme pieza de software.

Este es un ejemplo real de un selector que tenemos. Puedes ver que depende de muchos otros selectores y cada uno de ellos puede depender de muchos otros selectores y cada uno de ellos depende de servicios y utilidades y muchos más archivos, resultando en el hecho de que este único selector puede depender de cientos de archivos.

Entonces, lo que salimos a hacer. Queríamos romper el núcleo, los mismos corazones y cerebros de nuestro monolito del lado del cliente y hacerlo manteniendo algunas reglas básicas. Queríamos cero incidentes de producción. Queríamos no crear cambios de comportamiento en nuestra aplicación. Queríamos convertir todo a TypeScript en el camino y mantener la fricción humana al mínimo en el proceso.

Entonces, ¿qué es ese Morphix que está rompiendo nuestro monolito? Para el desarrollador promedio en Monday, Morphix está creando pull requests aleatorios en momentos aleatorios y envía estos pull requests para que los revisen y fusionen. En este ejemplo, puedes ver un mensaje de Slack. Morphix envió a estos dos desarrolladores diciéndoles que había hecho mucho trabajo por ellos y ahora depende de ellos revisarlo y fusionarlo.

Ahora cómo elegir el archivo correcto para extraer. Al igual que en el juego de Jenga, necesitas saber qué ladrillo puedes extraer sin romper toda la torre. No queremos que nuestro producto se caiga. Pero si alguna vez jugaste Jenga, sabes que eventualmente la torre debe caer. Al extraer archivos, si simplemente eliges un archivo al azar y quieres sacarlo del monolito para extraerlo en otro lugar, sabes que no puedes simplemente sacarlo porque tiene dependencias y tiene otros bloqueadores que deben resolverse antes de que ese archivo específico deba ser manejado.

Pero si pudiéramos simplemente sacar los ladrillos de la parte superior de la torre, sería un juego mucho más fácil de jugar. Y eventualmente, para nuestro monolito, encontramos cómo hacerlo. Creamos el analizador Morphix, que es una herramienta determinista estática que utiliza un AST bajo el capó que recorre toda la base de código y construye un enorme árbol de dependencias. Y sus hojas son como la parte superior de la torre. Está libre para extracción. Y después de que el analizador se ejecuta, tomamos todos los datos, todos los datos de migración, las dependencias, la complejidad y todos los demás datos relevantes y simplemente los lanzamos a un tablero de Monday.

Y ahora, con el tablero, Morphix y nosotros tenemos una visibilidad clara sobre el progreso de la extracción, el estado y el orden, creando una increíble colaboración entre agentes humanos donde humanos y agentes están trabajando juntos en el mismo tablero hacia el mismo objetivo. Y con este tablero como un sumidero en su lugar, ahora permitimos que Morphix se ejecute en paralelo extrayendo múltiples archivos simultáneamente. Así que veamos cómo podemos extraer un solo archivo, un solo bloque del monolito. Simplemente vamos a Claude, por supuesto, y le decimos hola, Claude, por favor saca este archivo del monolito. Y como dijimos, también queremos convertirlo a TypeScript. Así es como se veía el prompt, como una línea única.

Y Morphix se ejecuta de manera autónoma sin intervención humana. Así que no pudimos hacerlo de esta manera porque necesitábamos hacerlo de una sola vez, ¿verdad? Necesitamos que funcione cada vez, miles y miles de veces. Y también queríamos más cosas. Por ejemplo, queríamos añadir una bandera de características al prompt. Y queríamos añadir más contexto sobre las guías y estándares y cómo escribimos código en Monday al prompt. Y añadimos más y más cosas. Y aún así no pudimos hacerlo de una sola vez de manera consistente.

Así que resulta que hacer el prompt más y más grande no es el camino a seguir. Al contrario, lo dividimos en microprompts. Cada uno de esos microprompts tiene su propia tarea dedicada y trabajo dedicado que hace realmente bien. Y de esta manera podemos hacerlo de una sola vez de manera más consistente. Lo construimos de esta manera en que cada paso necesita tener éxito porque el siguiente paso depende de que tenga éxito. De esa manera, si el primer paso, por ejemplo, no funcionó tan bien, entonces probablemente el resto fallará también.

Pero eso planteó la pregunta, ¿cómo sabemos cuándo un paso está hecho, verdad? ¿Cuándo realmente tuvo éxito un prompt? Porque es IA. La IA puede decirte, sí, funcionó. Pero a veces ese no es el caso, ¿verdad? Creamos este mecanismo. Aquí dejamos que la IA haga el trabajo. Ejecutamos un conjunto de validaciones. Y esas validaciones ocurren de manera determinista después de que la IA se ejecuta. No solo le digo a la IA en el prompt que ejecute lint cuando haya terminado.

No. Lo ejecutamos. Nos aseguramos de que se ejecute el 100% del tiempo. Y si algo falla, volveremos a intentar y a intentar una y otra vez con la retroalimentación adecuada sobre qué salió mal y volvamos a intentar la tarea. Por ejemplo, tenemos este script de tipo converter, ¿verdad? Y tenemos estas dos validaciones. Primero es el lint. Como dije, lo ejecutamos. Y no solo dejamos que la IA ejecute lint, ejecutamos el comando bash y nos aseguramos de dar la retroalimentación adecuada. Y también usamos la IA como juez.

Iniciamos otra nube con un prompt de revisor que revisa la tarea, sabe cuál es la tarea y se asegura de saber si tuvo éxito o no. Y es un contexto nuevo. De esa manera sabemos con certeza que el trabajo realmente está hecho. Ahora, también entendimos que no todo el trabajo necesariamente necesita IA. Por ejemplo, mover constantes, necesitamos crear una buena configuración para que la IA tenga éxito. Si le damos tantas distracciones como mover constantes, copiar archivos, solo consumirá contexto, será costoso, causará alucinaciones.

Así que nos aseguramos de usar operaciones deterministas siempre que pudimos para tareas muy simples, creando una configuración realmente buena para que la IA tenga éxito y además es gratis. Así que reduce costos y asegura que obtengamos los mejores resultados posibles. Así que envolvimos todo en un buen constructor. Y este constructor, como dije, es la forma en que definimos las migraciones. Tenemos pasos. Y cada uno de los pasos pasará al siguiente paso solo cuando todas las validaciones tengan éxito y el trabajo realmente esté hecho. Y de esta manera sabemos con certeza que las migraciones funcionaron y se ejecutaron.

Ahora, la pregunta obvia que nos hicimos es, ¿estamos complicando demasiado esto? Porque esto es mucho, ¿verdad? Como el constructor y las validaciones y todo. Así que la respuesta corta es no. Porque estamos migrando el núcleo de Monday. Es una gran empresa. Tenemos más de $1 mil millones de ingresos. Y el 100% de nuestros usuarios están usando este código. Si algo se rompe, el radio de impacto es absolutamente enorme. Así que para tener éxito cada vez, miles de veces, necesitábamos control de seguridad. Y nuestros mecanismos de seguridad son esos. Los que te voy a mostrar ahora mismo.

Primero, queríamos una liberación segura. Necesitamos envolver en un feature flag. Pero estamos moviendo un archivo fuera del monolito. Así que para envolver en un feature flag, necesitamos cambiar todas las importaciones. Lo cual es un poco torpe y extraño y podemos perder algunas ocurrencias. Así que usamos el siguiente mecanismo. Tomamos un archivo y lo convertimos en una carpeta con un archivo index.js. Ahora JavaScript sabe resolverlo automáticamente exactamente igual.

Y luego el feature flag está en un solo lugar. Puedes ver en el archivo index.js, hay un solo toggle para la nueva y todas las implementaciones. Y de esa manera podemos liberar nuestros cambios a producción de manera segura. Causó un buen efecto secundario. En lugar de cambiar toda la importación en todo el repositorio, que son cientos de cientos de archivos, tenemos un número muy conciso de archivos. Fácil de revisar. Fácil de tener confianza sobre tu liberación. Y de esa manera es manejable para nosotros los humanos. Pero necesitamos cambiar las importaciones en algún momento, ¿verdad? Así que lo movimos a la limpieza de PR. Las limpiezas de PR eran enormes. Cientos de archivos. Pero todos los cambios son de una sola línea.

Muy simple de revisar. Lo haces sin problemas. Lo haces bastante rápido y estamos seguros de ello. Así que, también queríamos cero cambios de comportamiento. Porque cuando mueves un código tan sensible, queríamos mantener todos los comportamientos existentes, todos los errores existentes. No crear nada nuevo. Porque cualquier nuevo error puede ser muy grave.

Lo que hicimos fue probarlo. Añadimos pruebas unitarias para cada archivo que extraemos. Y todas las pruebas unitarias no son para probar la lógica dentro del archivo. Es para probar la nueva implementación contra la antigua implementación. Para asegurarnos de que no haya cambios de comportamiento. Para hacer eso, creamos esta utilidad. Los resultados del código son los mismos. Comprobamos si los resultados son los mismos.

Si uno lanza un error, entonces el otro también lo hará. Si uno devuelve undefined, por ejemplo, entonces el otro también lo hará. Y abusamos de esas pruebas. Creamos muchas pruebas para asegurarnos de que el comportamiento no cambie. Además de eso, a veces la IA puede encontrar un error. O no hacer el trabajo correctamente. O no puede decidir sobre un desafío que necesita. Complica demasiado las cosas.

Y necesitábamos que la IA escalara a un humano siempre que necesitara ayuda. Así que, creamos este mecanismo. La IA puede añadir un humano para hacer un comentario y este comentario está bloqueado en el PR. Ahora, el proceso no se detiene. Porque si la IA no pudo decidir, puede escalar a un humano y luego un humano lo resolverá. Pero el archivo no se quedará atascado porque cada archivo liberará más y más archivos. Desatascará más archivos del monolito.

De esa manera, la IA puede escalar a un humano. Un humano lo resuelve después de que se fusiona. Luego, el PR también puede fusionarse y el archivo puede extraerse del monolito. Increíble, ¿verdad?

Ahora, ampliemos un poco y veamos todo el flujo. Entonces, como dijimos, Morphx toma el archivo del árbol de dependencias y crea la solicitud de extracción para extraerlo. Luego lo envía al desarrollador para revisarlo y fusionarlo.

Y luego, una vez fusionado, Morphx retoma el control y libera la bandera automáticamente. Y una vez hecho esto, crea un PR de limpieza, eliminando el archivo antiguo automáticamente y lo envía de nuevo al desarrollador para revisarlo y fusionarlo. Y una vez que se completa el ciclo, Morphx puede reconstruir el árbol de dependencias y seleccionar el siguiente archivo.

Entonces, hemos hecho todo ese trabajo para poder extraer de manera segura un solo archivo de nuestro monolito. Y con eso, sentimos que lo tenemos todo resuelto. Tenemos la capacidad de extraer archivos. Conocemos el alcance del trabajo. Nos sentamos a calcular todo. Enumeramos todos los archivos a extraer y todos los equipos relevantes. Y distribuimos el trabajo a lo largo de los próximos seis meses.

Y lo que se nos ocurrió fue 155 archivos a la semana con dos PRs por archivo, uno para la migración y otro para la limpieza, resultando en 310 PRs a la semana. Y terminamos. Y luego realmente sentimos que habíamos alcanzado lo que nos propusimos hacer. El plan comenzó a funcionar. Fuimos invitados a compartir nuestra historia con toda la empresa. Tuvimos reuniones con VP y champán y limusinas y todo fue genial y todo estaba funcionando sin problemas. Sí. Solo necesitábamos que los desarrolladores humanos revisaran 310 PRs a la semana y terminamos.

Sí. Correcto. Solo necesitábamos que los desarrolladores humanos revisaran 310 PRs a la semana. ¿Crees que podría funcionar? Yo no. Bueno, no, no funcionó. Muy pronto la gente comenzó a retrasar el trabajo. Comenzaron a cuestionar si ese esfuerzo realmente valía su tiempo. De hecho, recibimos demandas más ambiciosas de nuestro liderazgo. Y las nuevas características en Monday parecían más atractivas para los desarrolladores en lugar de revisar la solicitud de extracción que Morphix había generado para ellos.

Entonces, en ese momento, decidimos que necesitábamos liberar completamente a Morphix para permitirle que automáticamente fusione cualquier PR que considere lo suficientemente bueno para fusionar. Si pasa su revisión y requisitos, puede fusionar automáticamente el PR sin esperar a nadie. Y los resultados fueron visibles. Lo que puedes ver es el cambio antes del flujo de auto-fusión y después del flujo de auto-fusión.

Pero el éxito no vino solo de la tecnología. ¿Verdad? Fue todo por sí mismo. Era realmente bueno creando los PRs, revisándolos y fusionándolos. Pero también necesitábamos humanos porque el futuro de los agentes incluye a los humanos. Primero, necesitábamos escuchar. Escuchamos a nuestros desarrolladores, recibimos comentarios y creamos un ciclo de retroalimentación muy corto, obteniendo comentarios, corrigiéndolos, obteniendo comentarios y corrigiéndolos.

También eliminamos la codificación de nuestros desarrolladores, pero mantuvimos la propiedad. Eso significa que los desarrolladores son dueños del código que Morphix libera a producción, lo cual es crucial. E hicimos que Morphix se adaptara a nuestra organización. Hicimos que Morphix no fusionara los fines de semana. Conocemos los días laborales de los desarrolladores. No queremos interrupciones. Queremos que sea lo más fluido y sin problemas posible. Y creamos canales de comunicación directa. Morphix envía mensajes de Slack. Yo fusiono esto. Yo libero esto. Esta limpieza ya está hecha. Y de esa manera, el desarrollador realmente sabe lo que Morphix hizo por ellos. Y construimos confianza. Creamos un nuevo ciclo de vida de desarrollo de software dentro de nuestra empresa. Esta es la primera vez que se hizo en la empresa. Y construimos confianza en el I+D para asegurarnos de que Morphix realmente haga el trabajo y los desarrolladores ahora confían en él.

Para resumir, queremos compartir algunos de nuestros aprendizajes clave de este proyecto. Primero, dividir en micro prompts. De esa manera, las tareas dedicadas y muy específicas simplemente funcionan mejor. Además, tus resultados serán los mismos que tu flujo de trabajo. Un flujo de trabajo determinista siempre te dará buenos resultados, deterministas y consistentes. Crea una buena configuración antes de dejar que la AI haga la tarea. Como hacemos con constantes y copiamos archivos antes de que la AI realice la tarea, nos ayudó mucho. Redujo costos y crea resultados mucho mejores.

Y cada proyecto autónomo de AI necesita un mecanismo de humano en el bucle. Porque si la AI llega a un punto muerto o un dilema que no puede resolver, no puedes poner el freno en tu proyecto. Necesitas avanzar y necesitas que los humanos lo desatasquen a veces. Y usando nuestro propio tablero de Monday. Esto fue realmente un cambio de juego. En lugar de usar una base de datos o cualquier cosa, de esta manera, imagina a todo el I+D de Monday trabajando en el mismo tablero con Morphix, transfiriendo propiedad, manteniendo buena comunicación a lo largo de toda la empresa y todo el I+D, y esto fue enorme para nosotros. Fue realmente una colaboración entre Morphix y todo el I+D.

Y por supuesto, ir completamente agéntico y dejar que Morphix realmente haga el trabajo dependió mucho de los humanos, de la cultura, hacer que Morphix se adapte a nuestra organización y nuestras necesidades fue un cambio de juego aquí y fue mucho trabajo y mucho feedback. Y estamos realmente contentos de haberlo logrado. Así que también escribimos una publicación en el blog, a la cual pasaré en un minuto porque veo que algunos de ustedes están tomando fotos de los aprendizajes, si también quieren escanear el código QR. Y eso es todo. Muchas gracias por escuchar.

¿Cómo lograron que las revisiones de PR no se convirtieran en un cuello de botella y usaron algunos guardianes de calidad automatizados? Lo siento. ¿Se han referido a la... ¿Cómo lograron...

revisiones de PR. Sí, bueno, las revisiones de PR inicialmente fueron el cuello de botella. Los desarrolladores lo entendieron.

Hemos hecho mucho trabajo para hacer el proceso más fácil y fluido. Tuvimos muchas automatizaciones, recordando a las personas que simplemente lo revisen o incluso enfocándolos en lo que necesita ser revisado. También tuvimos reuniones donde mostramos a equipos enteros o divisiones enteras lo que necesita ser revisado.

No necesitan revisar la implementación antigua. Solo necesitan revisar algunos lugares. Y hemos trabajado en eso durante mucho tiempo. Pero eventualmente, fue el cuello de botella y fue entonces cuando decidimos que necesitamos descifrar la manera de permitir que se fusionen automáticamente los PRs, para eliminar exactamente ese cuello de botella del proceso.

Genial. Gracias. Y tenía una pregunta que es, ¿podrías compartir un poco sobre qué hay dentro de MorphX? Sí, en realidad estamos envolviendo Cloud Code SDK. Comenzamos antes de que incluso tuviéramos Cloud Code, pero Cloud Code realmente nos dio buenos resultados porque es muy independiente, ¿verdad? Puede leer archivos. Puede entender problemas. Y la mayor parte de la magia que sucede en MorphX, en realidad la extendemos aquí como el constructor, flujos de trabajo deterministas, creando las validaciones y volviendo a empezar. Queríamos imitar la forma en que trabajamos en nuestro día a día porque trabajamos, obtienes el código de la IA, lo revisas, das retroalimentación, y haces lo mismo una y otra vez nuevamente. Creo que los principios fundamentales y las cosas principales estaban aquí, pero está usando Cloud Code y estamos usando AST para todas las operaciones deterministas. AST es como una biblioteca de modelos de código para aquellos que no lo conocen. Sí. Genial, gracias.

Parece que fue un proceso bastante completo de averiguarlo y muchas iteraciones, estoy seguro. Una pregunta es, ¿cómo convenciste a tu liderazgo de que dividir tu monorepo valía la pena? ¿Tenías algún dato que presentaste para iniciar este proceso? Sí, bueno, eso es como, es una pregunta interesante. Así que romper nuestro enorme monolito, además del monolito que tenemos, tenemos como muchos otros repositorios para micro frontends y otros monorepos y más. Pero el antiguo monolito principal era como un objetivo que teníamos antes de que incluso me uniera a la empresa. Era como una iniciativa dorada para que la empresa lo manejara porque está retrasando el trabajo. Reduce la velocidad de desarrollo. Y era algo que estaba destinado a ser manejado hace mucho tiempo. Y cada vez que alguien intentaba abordarlo, llegaban a otras cosas que lo impedían de suceder. Y puedo decir que la raíz de eso fue el hecho de que, como dije, la aplicación es compleja y muchos componentes diferentes allí reaccionan entre sí. Y nos llevó a estar en una situación en la que para que un equipo extrajera su código del monolito, tenían que esperar a que otro equipo extrajera su código para que todos sus datos y componentes y todo estuvieran fuera del monolito y pudieran usarlo. Así que esa fue como la razón principal. Y fue como algo que se midió hace mucho tiempo, incluso nuevamente antes de que incluso me uniera a la empresa. Y fue como divertido para nosotros que no tuviéramos ese desafío de probarlo. Pero fue mucho trabajo hecho por otras personas antes de que nos uniéramos. Genial saberlo.

Parece que, sí, es un esfuerzo de todo el equipo, ¿verdad? Otra pregunta bastante jugosa. ¿La fusión automática que implementaste sin revisión humana resultó en errores significativos o incidentes? En realidad, antes de la fusión automática tuvimos un incidente, lo cual fue curioso porque en la escalada humana un humano decidió corregir un error y luego ocurrió el incidente. Pero después de la fusión automática añadimos directrices de revisión muy estrictas. Revisamos de dos maneras. Un MorphX revisa con IA como juez, como hicimos para las validaciones. Revisamos todo el PR. Además de eso, revisamos con operaciones deterministas como ASTs. Comprobamos, por ejemplo, que todos los símbolos en el archivo antiguo son los mismos que los símbolos en el nuevo archivo. Y muchas de esas comprobaciones. Así que fue mucho trabajo. También hicimos pruebas en seco. Nos enviamos mensajes a nosotros mismos. Este PR se va a fusionar. Luego lo revisamos por nuestra cuenta, obteniendo confianza sabiendo, está bien, no ocurrirán incidentes, no ocurrirán incidentes. Y eventualmente cuando liberamos MorphX, realmente no ocurrieron incidentes porque hicimos las pruebas en seco y verificamos todo que realmente funciona con, más y más directrices de revisión. Y de esa manera pudimos realmente reducir el riesgo al mínimo. Bien, impresionante. Eso suena realmente genial. Y es curioso que mencionaras que fue un humano en el proceso el que causó un incidente con ese.

Así que otra pregunta es, ¿MorphX hizo alguna refactorización compleja o la idea era, lo siento ha desaparecido, simplemente delimitar y dividir el código y la migración a TypeScript? Así que cuando tomamos ese desafío, dijimos que no estamos aquí para arreglar la base de código y estamos aquí para romper el monolito. Y si tomamos cada misión secundaria posible, nunca progresaremos y nunca lo terminaremos. Así que tomamos esa decisión de no mejorar el código y no hacer refactorización aparte de las cosas que mencionamos. Y MorphX, por ejemplo, también añade un comentario cuando encuentra un error, pero no lo maneja. Está diciendo, veo algo problemático aquí. No lo estoy tocando ahora mismo, pero tenlo en cuenta más adelante. Encontramos algunas cosas como en las dependencias específicas de nuestro monolito que deben ser manejadas y MorphX no puede extraerlo por sí solo. Y nos alertó y vimos en el tablero que la cantidad de elementos disponibles para MorphX está reduciéndose. Tuvimos la visibilidad para eso y MorphX nos estaba alertando que tiene archivos bloqueados, que no puede extraer. Encontramos a las personas relevantes, ya sea nosotros u otros equipos, desenredaron ese archivo específico y luego MorphX fue libre para continuar. Impresionante.

Gracias. Un poco más sobre ese proceso, las cosas que MorphX tuvo que hacer. Alguien ha preguntado, si estás extrayendo archivo por archivo, ¿no estás preservando las conexiones entre las piezas de Jenga y no resolviendo el problema real, que es simplificar la complejidad? Estamos preservando las líneas porque lo extraemos a paquetes separados. Tenemos dependencias de paquetes y tenemos toda una infraestructura de gestión de estado en Monday. Tenemos esta cosa llamada Vulkan. Manejamos todo el estado y todo dentro de él. Podemos mantener las dependencias entre los diferentes bloques y productos mientras lo extraemos a diferentes bases de código para asegurarnos de que mantenemos todo lo más limpio posible y tan lógicamente separado como podamos. Impresionante. Tenemos tiempo para una pregunta más. ¿Cómo se ven los costos de uso de IA? Ejecutar muchos prompts durante mucho tiempo debe ser costoso. Sí. De hecho, creo que desde el primer día, añadimos visibilidad para el costo. Como dijo Amit, lo comenzamos antes de que CloudCode estuviera allí. El desarrollador principal del proyecto, creó algo como CloudCode por sí mismo antes de que comenzáramos. Estaba enviando solicitudes de API a Gemini y obteniendo respuestas. Solo recopilamos los costos. Ahora, lo que estamos haciendo es que en cada migración, estamos recopilando el costo de la misma. Puedo compartir que creo que para la mayoría de ellas, son varios dólares, como tres, cuatro dólares por migración. Añadimos límites a eso, que si está intentando e iterando el proceso de validación más de unas pocas veces o si el costo alcanza una cierta cantidad, se detiene. Nuevamente, nos alerta. Nos dice que algo está mal porque no debería ser tan costoso. Como dije, es como cuatro o cinco dólares por archivo para ser extraído y comparado con el tiempo y esfuerzo que le tomaría a un desarrollador, entonces estamos tomando ese precio. Los límites fueron cruciales y también los code mods. Porque usamos muchas operaciones deterministas, reducimos el costo dramáticamente. Fue un cambio de juego cuando introdujimos esto. Realmente vemos que los precios bajan. Esto también fue impresionante para nosotros. Asombroso. Muchas gracias. Gracias. Gracias.