Cómo Usamos AI para Construir TanStack AI

Hola a todos. Mi nombre es Zalim Tuzlak. Y hoy voy a explicar cómo construimos TenStack AI usando IA. Así que antes de entrar en cómo lo hicimos, solo quería mostrarles qué es y explicar brevemente cómo funciona. Y TenStack AI es tu SDK de IA que te permite hablar con proveedores de LLM, y fácilmente integra funcionalidades de IA en nuestra aplicación. Así que si quieres añadir un chatbot, si quieres generar imágenes, generar algo como un video, transcripción, resumen, discurso, canciones, lo que sea, puedes usar TenStack AI para lograrlo.

Y es bastante fácil y sobre todo, de tipo seguro. Así que lo interesante de TenStack AI es nuestro hook principal, y también su contraparte del servidor llamado el chat hook. Así que el chat hook es realmente una verdadera potencia, y tiene muchas características que vienen integradas en él. Y el punto principal de este hook es conectarse a cualquier proveedor de LLM. Así que por ejemplo, si quieres conectarte a OpenAI, vas a usar OpenAI text, vas a ponerlo en el método chat, va a hablar con OpenAI. Si quieres usar el adaptador Entropic, solo tienes que cambiarlo. En lugar de OpenAI text, es Entropic text, y ya lo tienes funcionando.

Los mensajes se envían desde el cliente, se ingieren en el método chat, y todo sucede mágicamente para ti. Y tenemos un montón de características. Así que primero que nada, soportamos muchas opciones de modelo y todas estas son de tipo seguro basadas en el modelo que uses. Así que por ejemplo, si quieres usar GPT 5.5, GPT 5.5 tiene sus propias funcionalidades como razonamiento, llamada de herramientas, y cosas así. Y si un modelo no soporta algunas de las funcionalidades, puedes enviarlo en las opciones del modelo. Así que esa parte es completamente de tipo seguro.

Otra característica genial que tenemos es el middleware. Y el middleware es una de las cosas más geniales en el método de chat porque te permite engancharte en cualquier punto del ciclo de vida del chat. Así que te permite engancharte en estos fragmentos que se están transmitiendo, te permite engancharte en las estadísticas de usuario, te permite transformar fragmentos a medida que se transmiten, te permite cambiar y almacenar en caché las llamadas de herramientas, y cosas así. Puedes implementar registro, limitación de tasa, persistencia y muchas otras características usando middleware. Y por ejemplo, si hay algo que no está soportado por 10-Stack AI en este momento, puedes usar fácilmente middleware para implementarlo tú mismo.

La siguiente característica genial son los servidores MCP. Y de hecho, tomamos servidores MCP dentro del método de chat. Solo tienes que proporcionar tus servidores MCP conectados al método de chat. Puede conectarse automáticamente a esos servidores MCP. Puede desconectar los servidores una vez que hayas terminado.

Tiene muchas funcionalidades bajo el capó como la llamada perezosa de herramientas. Y cuando se trata de herramientas, una característica que es realmente genial es el modo de código de herramienta. Y lo que es el modo de código, si piensas en modelos LLM, es muy ineficiente para nosotros darle una lista enorme de herramientas y hacer que llame a una herramienta una por una. Así que, por ejemplo, tiene que obtener todos los productos, luego regresa al LLM. El LLM es como, está bien, tengo una lista de 30 productos. Quiero recomendar este único. Voy a llamar a esta otra herramienta. Va a enviar de vuelta lo que quiere hacer. Va a llamar a esa herramienta. Va a enviar los resultados de vuelta al LLM. Y luego es un ir y venir entre el LLM y tu servidor.

Bueno, el modo de código es un concepto realmente interesante donde en realidad no usas herramientas en un sentido tradicional, sino que en realidad permites que el LLM escriba sintaxis de typescript. Y lo que sucede es que escribe un script que va a llamar a todas tus herramientas disponibles. Así que, por ejemplo, si tienes funciones de obtener todos los productos, y obtener producto por ID, y recomendar producto dentro de tu aplicación, va a usar el modo de código. Va a escribir el script que llama a los productos, llama a uno específico, y luego lo envía a la recomendación. Y eso obtiene un resultado de vuelta. Y va a llamar a ese script y obtener los resultados de vuelta de manera eficiente. Y lo genial es que también es autorreparable.

Así que, por ejemplo, si envías algo de vuelta al LLM, como que el script falló debido a la razón X, Y y Z, el LLM va a decir, está bien, me equivoqué al agregar un punto y coma o algo así. Va a corregir el script y enviarlo de nuevo. Y eso es realmente poderoso si estás usando modelos de IA porque de alguna manera supera su naturaleza no determinista. Y luego simplemente lo conectas a tu lado del cliente. Así que, soportamos cinco frameworks, y los hooks en sí son bastante similares en todos los frameworks. Solo tienes el hook de uso de chat, y simplemente te conectas a él, a tu servidor. Y eso es todo. Funciona.

Pero hoy mi charla no es realmente sobre lo genial que es TenStack AI, sino que se trata de llevarte detrás de escena y contarte cómo lo construimos. Y todo comenzó el año pasado cuando Tanner y Jack Harrington estaban hablando sobre construir una biblioteca para IA en ReactConf. Y casualmente, yo, al mismo tiempo, quería construir un producto de IA en TenStack, y le pregunté a Tanner, oye, ¿deberíamos siquiera construir esto? Y la razón por la que le pregunté eso es porque somos un equipo muy pequeño, y en ese momento solo Jack y yo se suponía que íbamos a construir esto con la ayuda de Tanner, pero él no estaba tan involucrado en el proyecto. Así que éramos como dos o tres personas.

Y luego tienes a todos los proveedores principales como OpenAI, Entropic, Grok, Grok con la DQ, no la K. Y hay muchos proveedores por ahí. Y luego tienes que soportar todos los frameworks, como Svelte, React, Solid. Hay muchas características que salen todos los días. Y la IA es una tecnología nueva y en constante evolución. Así que es muy difícil mantenerse al día, y no estábamos seguros de cómo íbamos a construir a la escala de todas estas tecnologías.

El año pasado, alrededor de noviembre, creo, lo llamo el momento Opus 4.5 porque en ese entonces en código abierto, cada vez que intentaba usar modelos para escribir código de código abierto, eran horribles en eso. Escribían código inferior, y era prácticamente inutilizable. Y podías salirte con la tuya con algunas aplicaciones más pequeñas y cosas así. Y esto fue incluso antes de que las habilidades se convirtieran en algo. Así que era realmente difícil escribir buen código con IA. Y luego salió Opus 4.5, y cambió todo. Ese fue el primer modelo que probé después de probar 20 modelos diferentes antes que realmente producía un código lo suficientemente bueno donde podía lograr que escribiera del 90 al 95% del código.

Y luego solo necesito refinarlo para llevarlo a un punto donde cumpla con mis estándares de calidad. Siempre me resultó gracioso porque odiaba usar IA para el desarrollo, y pensaba que nunca iba a ser algo. Y luego probé Opus, y me encantó. Y seguía diciéndole a mis amigos de código abierto, como el mantenedor de Nux que es un amigo cercano mío, y seguía diciéndole, tienes que probar a codificar con Opus 4.5. Y él decía, sí, no funciona en código abierto. Los modelos simplemente no son lo suficientemente buenos. Y yo le decía, solo pruébalo. Y lo hizo, y también le encantó.

Entonces, ¿cómo construimos esto realmente? Bueno, primero, lo que queríamos hacer era averiguar los requisitos. Afortunadamente, como no éramos las primeras personas en hacer esto, ya teníamos ejemplos en la industria, como el AI SDK de Marcel, Mastra, Langraph, Langchain, había muchas empresas que ya estaban haciendo esto. Así que teníamos muchas referencias a las que recurrir y averiguar cómo debían ser las APIs finales. Y nuestro objetivo principal, porque somos 10 stack, es la seguridad de tipos de extremo a extremo. Así que queríamos que las opciones del modelo fueran seguras por tipo por modelo. Y cómo lo hicimos, mapeamos manualmente cada característica compatible por modelo a los tipos. Así que pasé como siete días solo leyendo la documentación y mapeando las características una por una.

El segundo requisito es que fuera tree-shakeable por actividad. Y la razón por la que necesitábamos esto es porque éramos un equipo muy pequeño. Y el problema que enfrentamos es que si usas un adaptador enorme que hace chat, imagen, video, transcripción, si querías agregar, por ejemplo, solo soportábamos OpenAI y Tropic y Olama en ese entonces. Si querías agregar algo como ROK, tendríamos que implementar todas esas funcionalidades que son compatibles. De lo contrario, la clase no coincidiría. Así que lo que decidimos hacer es dividirlo por actividad. Primero que todo, lo que obtienes con esto es tree-shaking. Y en segundo lugar, lo que obtienes es que es realmente fácil escribir una actividad. Por ejemplo, queremos agregar imágenes. Solo agregamos imágenes sin soportar video y cosas así. Y nos facilitó mucho el mantenimiento a largo plazo. Y luego puedes cambiar de proveedores en tiempo de ejecución. Esa es otra cosa genial que puedes hacer. Todo es seguro por tipo. Y la siguiente parte final fueron las herramientas isomórficas donde puedes definir una definición de herramienta y luego después de un tiempo puedes simplemente usar esto.

Es muy similar a las funciones del servidor desde el inicio donde puedes definir una implementación del servidor y la implementación del cliente de una herramienta y luego enviarla al proveedor y todo lo demás es manejado por la propia biblioteca. Así que construimos una gran alfa y tenía muchas características. Y por ejemplo, si piensas en una buena arquitectura, generalmente proviene de muchos errores y muchos aprendizajes a lo largo de los años con experiencia y cosas así. Y debido a que el código se volvió un poco más barato de escribir, decidimos construir una gran alfa, equivocarnos, acertar y luego averiguar cuáles eran las cosas correctas. Y eso es lo que hicimos.

Porque la alfa que construimos era demasiado grande. Construimos todas las funcionalidades como imagen de video y cosas así. Nos dimos cuenta de dónde estaban los errores y básicamente queríamos reducir todas las características y lanzar una pequeña alfa para que la gente pueda jugar con ella. Y también podemos obtener las APIs correctas desde el principio. Y eso es lo que hicimos. Así que básicamente construimos una gran alfa y luego la restringimos a un pequeño método de chat y lo lanzamos como la alfa.

Y aprendimos muchas lecciones al hacer eso que aplicamos más adelante a medida que avanzamos a través de las fases alfa. Y este aquí es el primer prototipo detrás de escena de 10-Stack AI. Y el video aquí a la izquierda es lo que teníamos al principio. Así que teníamos esta clase de AI que básicamente te permitía llamar a cualquier cosa. Así que era AI.chat, AI.image y cosas así. Y era un concepto realmente genial y todo era seguro por tipo. Y también teníamos este concepto de fallbacks donde si un LLM responde y muere, puedes recurrir a otro. Y como que murió debido al tree shaking. Y si incluimos todo esto por defecto, estarías usando toda la biblioteca.

Y, por ejemplo, si necesitas, no sé, solo el método de chat, estás incorporando la imagen, el video, el audio y todas estas cosas que no necesitas en tu paquete. Y lo que hicimos a continuación fue básicamente tener chats en vivo de vez en cuando. Y básicamente hablamos sobre ideas. Así que, por ejemplo, este es un ejemplo del otro día donde estábamos añadiendo soporte de multimodalidad a la generación de imágenes. Así que puedes enviar imágenes de referencia y hacer que funcione. Y básicamente solo debatimos sobre la API. Y como el grupo de 10-Stack tiene muchas personas inteligentes, todos participan. Dan sus opiniones. Y luego podemos simplemente refinar la API. Y, por ejemplo, esta es la idea para la API final, que pasó por como tres o cuatro revisiones, lo que nos ayuda a construir una gran API porque si tienes un gran equipo detrás de ella, eso potencia muchas de las cosas geniales.

Y finalmente, las habilidades de came. Así que, por ejemplo, después de un tiempo, te das cuenta de que la salida de los LLMs es buena, pero no es lo suficientemente buena. Así que lo que básicamente hicimos fue escribir un montón de habilidades para ayudarnos a obtener la consistencia y la calidad que buscamos. Así que, por ejemplo, si teníamos pruebas, lo que hicimos fue, está bien, no queremos que las pruebas usen casts como any porque eso simplemente mata la seguridad de tipos en la prueba y no tienes idea de si es correcto o no. Y luego, por ejemplo, no sobreabstraer las pruebas, no omitir pruebas y cosas así. Y luego simplemente escribes esta biblioteca de habilidades que mejora la base de código con el tiempo. Y, por ejemplo, lo que hicimos fue escribir una habilidad para los documentos y cada vez que añadimos una nueva característica, esta habilidad es una puerta de calidad que nos impide lanzarla hasta que realmente escribamos muy buenos documentos que cubran las nuevas características.

De esa manera nos mantenemos al día y no olvidamos hacer algunas de las características. Y otro problema con el que nos encontramos al lanzar características y asegurarnos de que todo funcione es que no teníamos presupuesto para marketing. Somos una comunidad de código abierto y dependemos de nuestros patrocinadores y no tenemos un equipo de diseño dedicado que pueda crear videos geniales para nosotros para promover nuestras nuevas características. Así que lo que hice fue usar una biblioteca llamada HyperFrames. Así que es una alternativa a Remotion. Y creé una habilidad que genera estos videos para nosotros. Así que nos ayuda a promover nuestras nuevas características que estamos construyendo y no hacer que sea solo una nota al pie en X o lo que sea. Así que nadie está como consciente de todas las características geniales que estás lanzando. Y esto en sí mismo nos ayuda a lanzar estas características en lugar de pasar tiempo en como crear estos videos porque acorta la cantidad de tiempo que tienes que pasar en marketing, lo cual preferimos pasar más tiempo escribiendo código. Y finalmente, lo último que es algo genial aquí es que los nuevos problemas requieren nuevas herramientas. Y, por ejemplo, nuestros documentos, cuando usábamos LLMs, a menudo alucinaban APIs y era muy frustrante. Así que lo que hice fue crear una pequeña biblioteca que básicamente verifica tipos en tu documentación, fragmentos de código y markdown.

Y básicamente verifica si, por ejemplo, si tienes una importación o si tu documentación, cambias alguna API, pero olvidaste actualizar la documentación, esto lo va a detectar en CI y lo va a corregir. Así que los equipos pequeños obtienen una gran ventaja al usar AI porque nos permite tener guías sobre la calidad del código. Nos ayuda a definir lo que queremos lanzar, y nos permite iterar económicamente sobre problemas. Antes, si queríamos, por ejemplo, explorar una nueva API, probablemente nos tomaría como un mes implementar primero el POC. Y luego todos tienen que probarlo y luego dar retroalimentación. Y luego nos damos cuenta, OK, esta API no funciona, tenemos que tirarla a la basura. Pero ya gastamos un mes en ello. Así que esta AI nos permite iterar rápidamente sobre una idea. Obtenemos un POC en el día. Lo probamos. Nos gusta. No nos gusta. Lo tiramos a la basura si simplemente no funciona. Y simplemente seguimos adelante.

Y finalmente, las herramientas engendran nuevas herramientas. Así que cada vez que nos encontramos con un problema o un inconveniente, simplemente creamos una herramienta para ello que nos ayuda a lanzar esto con más confianza. Y el punto final de mi presentación es que deberías construir y soñar más grande que antes, porque AI nos permite iterar rápidamente sobre el código, obtener rápidamente POCs y probar nuevas ideas. Y no tienes que quedarte atascado en una sola API solo porque tomó como un mes escribirla. Puedes simplemente escribirla en un día, ver si te gusta y luego tirarla a la basura porque se ha vuelto más fácil que nunca probar cosas nuevas y descubrir nuevas APIs.

Y una cosa más antes de terminar mi discurso, y es que no estoy seguro si sigues el Twitter de Ten Stack, pero anunciamos algo que va a suceder el 11 de junio, y es que Ten Stack AI va a entrar en la versión beta. Hemos finalizado y estabilizado la API y está lista para uso público. Y gracias por la presentación. Y si estás interesado, puedes seguirme en Twitter. Y también estoy haciendo una masterclass sobre Ten Stack AI. Ese es el QR a la derecha. Y muchas gracias. Vimos React, Svelte, Vue. ¿Dónde estaba Angular en todo esto? Sí, así que no hay razón para no soportar Angular. Simplemente no lo hemos hecho aún. Personalmente, no soy un tipo de Angular, así que probablemente tenga que encontrar un mantenedor que lo haga por nosotros porque no me siento cómodo simplemente dejando que AI escriba el adaptador de Angular y luego esperar que funcione.

Así que va a ser una contribución de la comunidad, si alguien está interesado en eso, o vamos a encontrar a alguien en nuestro grupo de mantenedores de Ten Stack que realmente pueda hacerlo. Parece un buen trabajo para quien hizo esa pregunta, ¿verdad? Sí, exactamente. Debería marcarlo como un buen primer problema. Sí. Muy bien. Oh, Dios mío, sigo descartando estos accidentalmente. Veamos.

OK. ¿Ejecutaste AI en modo automático o tuviste que aprobar cada acción que ejecutó? Sí, esa es una pregunta muy interesante. Antes, no confiaba mucho en ello. Así que básicamente lo ejecuté en el modo normal y luego permití todo lo que necesitaba hacer. Más tarde, a medida que los modelos y las medidas de seguridad mejoraron, en realidad lo cambié para usarlo con permisos automáticos. Y porque trabajo en una empresa llamada CopilotKit, y a nuestro CTO realmente le encanta escribir habilidades para AIs para mejorar las medidas de seguridad. Tenemos todo un sistema de habilidades que simplemente hace que el resultado sea muy, muy bueno. Y te lleva al 95% con las medidas de seguridad de no borrar todo tu disco duro. Muy bien.

Aquí está el que descarté accidentalmente. ¿Usaste Opus 4.5 todo el tiempo o cambiaste o usaste otros arneses? Sí, he estado cambiando mucho entre Entropic y Codex, OpenAI. Básicamente comencé con Opus 4.5 cuando salió. Luego pasé a 4.6, 4.7. Luego volví a GPT 5, creo que fue 2 y luego Codex y el GPT 5.5. Así que sigo cambiando de un lado a otro. Desde mi experiencia personal, Entropic es mejor para trabajos creativos, como crear esos videos que acabo de mostrarte. Donde Codex es mejor para pruebas de codificación en general. Personalmente, tengo curiosidad. ¿Es todo por sensaciones para ti o qué usas personalmente para evaluar? Porque sé que yo siempre estoy cambiando y probando cosas nuevas, pero a menudo son solo sensaciones. ¿Tienes un marco para entender qué es lo que más te gusta? Para mí, es principalmente como si ejecutara el agente generalmente en las mismas cosas, y luego comparo los resultados y veo qué funciona mejor. Y también depende mucho del tiempo. Así que, por ejemplo, si Opus tarda siete horas en llegar y lo hace en dos horas, eso es mucho más valioso para mí porque puedo comenzar a probarlo e iterar en él cinco horas antes.

Así que realmente puedo probarlo. Y, por ejemplo, para el trabajo creativo, es mucho más fácil porque ves visualmente el resultado y dices, Oh Dios mío, esto se ve horrible. Y dices, este modelo es claramente mejor en el trabajo creativo. Y así es como descubro las cosas de Opus, porque los videos que generé con GPT son horribles. Muy bien. El siguiente aquí.

Estoy usando el AI SDK de Vercell. ¿Por qué debería cambiar a TanStack AI? Sí, ofrecemos bastantes características que faltan en Vercell. Una de ellas es LazyTools, que es un concepto realmente genial donde básicamente puedes marcar una herramienta como perezosa y no enviarla a un LLM. Y básicamente, te permite ahorrar un montón de tokens. Y otra razón es que tenemos el modo de código, que expliqué anteriormente cómo funciona. No solo ahorra tokens, sino que creo que, según Benchmark, completa un 90% más rápido que el bucle de llamada de herramientas regular. Así que esa es otra razón realmente buena. OK, déjame marcar este también. OK. Oh, y acabo de ver la pregunta.

Así que el AI gateway no es... Así que AI SDK es la alternativa de código abierto a TanStack AI. Pero AI gateway es solo un proveedor para modelos, así que no es diferente en ese término. El AI gateway es algo así como una alternativa de open router, donde AI SDK en sí mismo es la alternativa a TanStack AI. Genial. Gracias. OK, el siguiente aquí.

He notado que TanStack ha estado enviando habilidades para prácticamente todos sus paquetes. He notado que tus archivos de habilidades a veces contienen más información que tu documentación regular. ¿Hay algún arnés para asegurar la calidad de tus documentos? No puedo hablar por todas las bibliotecas porque no mantengo todas. Mantengo dev tools y AI. Por lo que puedo ver en AI y dev tools, hay muchas medidas de seguridad para asegurarnos de que escribimos la documentación que necesitamos. Tengo una habilidad llamada doc writing y mejoro como una llamada cada vez que termino con una característica y básicamente escribe documentos para cada persona usuaria. Así que para principiantes, para usuarios avanzados, para alguien en el medio.

Y así es como nos aseguramos de que la calidad de los documentos esté a la par en TanStack AI. Así que eso es lo que hacemos en TanStack AI. No puedo hablar por las otras bibliotecas. Muy bien. Hagamos este.

¿Cuál encuentras que es el nuevo cuello de botella para tu desarrollo con todas las nuevas ganancias del desarrollo de IA? Sí, este es bastante fácil de responder. El nuevo cuello de botella soy yo. Porque, por ejemplo, a veces puedo abrir como ocho terminales y luego me hace muchas preguntas desde todos los lados. Y luego tengo que pensar en cada respuesta porque no me gusta simplemente hacer clic en la recomendación recomendada.

Tengo que pensar en cada respuesta. Y luego tengo que probarlo manualmente cuando está hecho y asegurarme de que funcione y luego revisar todo el código. Y creo que esa es la parte más lenta, porque a veces creo como tres, cuatro características que se supone que deben ir a TanStack AI. Y luego lo creo en como cuatro o cinco horas. Y luego me lleva como cuatro o cinco días verificarlo manualmente, asegurarme de que sea de buena calidad, que la API esté correcta y cosas así. Y para refinarlo aún más con IA. Así que el mayor cuello de botella soy yo mismo.

Sí, ¿cómo te sientes con tus niveles de estrés con todo esto? Sé que para mí, puede sentirse la fatiga de decisiones. Puede sentirse un poco más estresante todo el tiempo. Sí, he estado hablando con mi CTO sobre esto, y es como entrar en una era completamente nueva de estrés. Y creo que aún no somos conscientes de ello, como lo que va a traer en los efectos secundarios a largo plazo. Pero también pienso mucho en eso porque, por ejemplo, antes cuando solía escribir código manualmente, escribía de 9 a 5. Y luego, después de terminar, me gustaría ir a la tienda de comestibles, pensar en un problema.

¿Cómo puedo solucionarlo? Como la mayoría de las cosas que creé vinieron de mis duchas. Y ahora, después de trabajar de 9 a 5, estoy demasiado exhausto para pensar. Mi cerebro está frito y simplemente no puedo pensar y no tengo idea de qué va a pasar a largo plazo. He estado escuchando eso cada vez más.

Sí. ¿Cuál fue el mayor error arquitectónico que ves repetidamente que los desarrolladores cometen al construir aplicaciones React impulsadas por IA? Esa es una pregunta interesante. Creo que, bueno, no es realmente un error arquitectónico, sino más bien un error de UX. Pero no son los propios desarrolladores los que lo cometen, sino más bien un problema de gestión donde la IA intenta ser forzada en productos que realmente no necesitan IA. Y luego los desarrolladores tienen que forzarlo en sus proyectos.

Pero ahora que lo pienso más, otro error es que la gente piensa que para agregar IA a sus proyectos, necesitas un enfoque completamente nuevo y cosas así. Donde, por ejemplo, ayer estaba teniendo una masterclass sobre Test Tech AI, y lo que hicimos fue principalmente reutilizar el código existente dentro de las herramientas de IA, porque la IA puede simplemente integrarse en tu aplicación como una característica adicional. En lugar de tener que escribir todo desde cero, solo para IA. ¿Qué tal esto? Esto está incluso un poco relacionado. ¿Qué partes de TanzDec AI fueron las más difíciles de construir con la asistencia de IA? Creo que el middleware fue lo más difícil porque el middleware es increíblemente poderoso porque puede engancharse en cualquier cosa dentro del bucle del agente, lo cual es realmente genial.

Así que la API en sí misma necesitaba ser perfecta. Y generalmente me toma unos días resolverlo. Pero para el middleware en sí, me tomó como tres o cuatro semanas para hacerlo perfecto.

Aquí hay algo que me interesa personalmente. ¿Qué usas para documentar decisiones importantes en tu equipo, como el tree shaking a nivel de actividad? Realmente no documentamos eso. Viven en mi cabeza, como la experiencia habitual. Lo bueno es que no puedo dejar la empresa de la manera habitual. Así que todos simplemente pierden la experiencia. Así que esa es la parte buena. Pero sí, creo que sí. He querido hacerlo. El equipo de React Router, solía ser un gran fan de React Router, un tipo de Remix. Y una cosa que me encantó que hicieron fue que escribieron decisiones, por ejemplo, por qué eligieron A en lugar de B. Y creo que quiero empezar a hacer eso porque es como un gran contexto para los LLMs también para tomar decisiones. Pero simplemente no lo he hecho todavía. Sí, creo que algunas personas usan un sistema ADR para eso también, ¿verdad? Donde documentas, retroalimentas eso.

Sí, en mi experiencia personal, lo encontré bastante efectivo. Sí. Pero tal vez solo estás, ya sabes, obsolescencia allí. Sí, tengo una habilidad para mejorar flujos de trabajo donde es como cuando le digo, oye, cometiste un error, lo auto-documenta en el repositorio para que no lo haga en el futuro. Y eso ha sido realmente genial. Y eso es básicamente lo que son los ARs. Así que creo que esa es la manera correcta a largo plazo de hacer este tipo de cosas. Sí. Y junto con las habilidades, ¿qué tipo de proceso tiene tu equipo para crear habilidades en proyectos? ¿Hay pasos de aprobación, sesiones de refinamiento, retroalimentación rápida? ¿Qué tipos de cosas estás usando? Sí. Así que principalmente para, es gracioso porque me he convertido en el tipo de habilidades en el Canal de Mantenedores de 10-Sec porque sigo escribiendo habilidades para todo. Y básicamente el flujo habitual es, digamos que quiero escribir la habilidad de TypeScript que va a resolver cosas como casts y cosas así. Básicamente vuelco toda mi experiencia y conocimiento de TypeScript en un prompt y luego le digo que escriba una habilidad. Y luego empiezo a probarlo ejecutándolo en algún código malo de TypeScript y veo el resultado y luego digo, OK, estas partes son buenas, pero olvidé refinar estas partes. Y luego sigo iterando en ello hasta que es lo suficientemente bueno para usar y lograr lo que busco de un solo golpe.

Y ese es el flujo habitual que sigo. Pero realmente no tenemos un proceso interno de mejora de habilidades porque no somos una empresa. Así que simplemente, si alguien piensa que esto mejorará la habilidad, simplemente lo fusionamos.

Sí. Aquí hay uno interesante. ¿Qué hace que Tanstack AI, oh no, lo siento. ¿Cuál es el objetivo final de Tanstack AI y cuál es su mejor punto de venta? Sí, así que el objetivo final de Tanstack AI es básicamente ser algo similar a Mastra. Pero en lugar de ofrecer, como no vendemos productos, no vamos a ser dogmáticos en cosas como la persistencia, dónde alojas cosas y cosas así. La idea es que somos completamente headless. Tú, por ejemplo, traes tu propia base de datos, traes tu propio proveedor de alojamiento y cosas así.

Pero cuando se trata de características, estamos a la par con algo como un marco de agentes similar a Mastra, Lankchain y cosas así. Genial. Bueno, muchas gracias, Olam. Esto ha sido increíble. Y pensé que tu charla fue increíble. Gracias.