Cómo Usamos AI para Construir TanStack AI

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

Así que lo interesante de 10 stack AI es nuestro gancho principal y también su contraparte del servidor llamado el gancho de chat. Así que el gancho de chat es realmente una verdadera potencia, y tiene muchas características que vienen integradas en él. Y el punto principal de este gancho 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 de chat, va a hablar con OpenAI. Si quieres usar el adaptador entropic, puedes simplemente cambiarlo. En lugar de OpenAI text, es entropic text, y lo tienes funcionando. Los mensajes se envían desde el cliente ingeridos en el método de 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 modelos, y todos estos son seguros en tipos basados en el modelo que usas. 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 segura en tipos. 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.

Permite engancharse a estos fragmentos que se están transmitiendo. {{^}}Permite engancharse a las estadísticas de usuario. {{^}}Permite transformar fragmentos a medida que se transmiten. {{^}}Permite cambiar y almacenar en caché las llamadas a herramientas y cosas por el estilo. Puedes implementar registro, limitación de tasa, persistencia y muchas otras características usando middleware. Y, por ejemplo, si hay algo que no es compatible con 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 proporcionas 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 llamadas a herramientas perezosas.

Cuando se trata de herramientas, una característica que es realmente genial es el modo de código de herramientas. Y lo que es el modo de código, si piensas en modelos LLM, es muy ineficiente para nosotros darle una gran lista de herramientas y hacer que llame a una herramienta una por una. Así que, por ejemplo, tiene que buscar 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 de ida y vuelta 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 TypeScript.

Y lo que sucede es que escribe un script que va a llamar a todas tus herramientas disponibles. Entonces, por ejemplo, si tienes get all products, va a obtener producto por ID y recomendar funciones de 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 autocurativo. Entonces, 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 AI porque de alguna manera supera su naturaleza no determinista.

Y luego simplemente lo conectas a tu lado del cliente. Entonces, soportamos cinco frameworks, y los hooks en sí son bastante similares en todos los frameworks. Solo tienes el hook use chat, y simplemente te conectarías a él, a tu servidor, y eso es todo. Funciona. Pero hoy, mi masterclass no es realmente sobre lo genial que es 10-Stack AI, sino sobre 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 AI en React Conf. Por cierto, yo, al mismo tiempo, quería construir un producto de AI en 10-Stack.

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, se suponía que solo Jack y yo í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 principales proveedores como OpenAI, Entropic, Grok, Grok con la D-Q, 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, por lo 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.

Y 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 de baja calidad, 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 intentar como 20 modelos diferentes antes de él que realmente producía un código lo suficientemente bueno donde podía hacer que escribiera del 90% al 95% del código. Y luego solo necesitaba refinarlo para llevarlo a un punto donde cumpliera con mis estándares de calidad.

Y siempre me resultó gracioso porque odiaba usar IA para el desarrollo, y pensé 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 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, porque no éramos las primeras personas en hacer esto, ya teníamos ejemplos en la industria, como el AI SDK de Marcel, Mastra, LangRaf, LangChain. Había muchas empresas que ya estaban haciendo esto. Así que teníamos muchas referencias a las que recurrir y averiguar cómo se supone que deben 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.

Cómo hicimos eso, mapeamos manualmente cada característica de soporte 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. Y el segundo requisito es que fuera tree shakable por actividad. Y la razón por la que necesitábamos esto es porque somos un equipo muy pequeño. Y el problema que enfrentamos es que, si usamos un adaptador enorme que hace, como, chat, imagen, video, transcripción, si queríamos agregar, por ejemplo, solo soportábamos OpenAI y Tropic y Olama en ese entonces. Si queríamos agregar algo como Rock, tendríamos que implementar todas esas funcionalidades que son soportadas. De lo contrario, la clase no coincidiría. Así que lo que decidimos hacer es dividirlo por actividad. En primer lugar, 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, si quieres agregar imágenes, simplemente agregas imágenes sin soportar video y cosas así. Y nos facilitó mucho el mantenimiento a largo plazo. Y luego puedes cambiar de proveedor en tiempo de ejecución. Esa es otra cosa genial que puedes hacer. Todo es seguro por tipo.

Y luego la siguiente parte final fueron las herramientas isomórficas, donde simplemente puedes definir una definición de herramienta. Y luego, después de un tiempo, simplemente puedes 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 simplemente lo envías al proveedor y todo lo demás es manejado por la biblioteca en sí. 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 video, imagen, y cosas así, nos dimos cuenta de dónde estaban los errores. Y queríamos básicamente reducir todas las características y lanzar una pequeña alfa para que la gente pudiera jugar con ella y también pudiéramos 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 aquí está 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. También teníamos este concepto de fallbacks. Si un LLM responde y falla, puedes recurrir a otro. Y de alguna manera murió debido al tree shaking. Y si incluimos todo esto por defecto, estarías usando toda la biblioteca.

Por ejemplo, si necesitas, no sé, solo el método de chat, estás incluyendo la imagen, el video, el audio, y todas estas cosas que no necesitas en tu paquete. Y lo que hicimos después fue básicamente tener chats en vivo cada cierto tiempo. Y básicamente discutimos ideas. Así que, por ejemplo, este es un ejemplo del otro día donde estamos agregando 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 tiene muchas personas inteligentes, todos intervienen, dan sus opiniones. Y luego simplemente podemos 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, eso potencia muchas de las cosas geniales. Y finalmente, las habilidades de juego. 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.

Entonces, por ejemplo, si teníamos pruebas, lo que hicimos fue, está bien, no queremos que las pruebas usen casts as any. Porque eso simplemente mata la seguridad de tipos en la prueba y no tienes idea si es correcto o no. Y luego, por ejemplo, no sobre-abstractar pruebas, no omitir pruebas y cosas así. Y luego simplemente escribes esta biblioteca de habilidades que mejoran la base de código con el tiempo.

Y por ejemplo, lo que hicimos fue, escribimos una habilidad para docs. Y cada vez que agregamos una nueva característica, esta habilidad es una puerta de calidad que nos detiene de lanzar hasta que realmente escribamos muy buena documentación que cubra 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ñadores 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á al tanto 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 creando estos videos porque acorta la cantidad de tiempo que tienes que gastar en marketing, lo cual preferimos pasar más tiempo escribiendo código. Y finalmente, lo último que es algo genial aquí es que nuevos problemas requieren nuevas herramientas. Y, por ejemplo, nuestros docs, cuando usamos LLMs, a menudo alucinarían APIs, y fue muy frustrante.

Entonces, lo que hice fue crear una pequeña biblioteca que básicamente verifica tipos en tus fragmentos de código y markdown de documentación. Y básicamente verifica, por ejemplo, si tienes una importación o si tu documentación, cambias alguna API, pero olvidaste actualizar la documentación, esto lo detectará en CI y lo corregirá. Así que los equipos pequeños obtienen una gran ventaja al usar IA porque nos permite tener barandillas en la calidad del código, nos ayuda a definir lo que queremos lanzar y nos permite iterar de manera económica en los problemas.

Antes, si queríamos, por ejemplo, explorar nuestra 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, está bien, esta API no funciona. Tenemos que tirarla a la basura. Pero ya pasamos un mes en ello. Así que esta IA nos permite iterar rápidamente en 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 seguimos adelante.

Y finalmente, las herramientas generan 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 lo que el punto final de mi presentación es, es que deberías construir y soñar más grande que antes. Porque la IA nos permite iterar rápidamente en el código, obtener rápidamente POCs, y probar nuevas ideas. Y no tienes que quedarte atrapado en una sola API solo porque tomó como un mes escribir. Puedes iterar en ella todos los días, 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 eso es, no estoy seguro si sigues el Twitter de TensTech, pero anunciamos algo que va a suceder el 11 de junio, y eso es que TensTech AI va a entrar en la versión beta. Hemos finalizado y estabilizado las APIs, y está lista para el 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 TensTech 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 todavía. 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 la IA escriba el adaptador de Angular y luego esperando 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 TensTech que realmente pueda hacerlo.

Parece un buen trabajo para quien hizo esa pregunta, ¿verdad? Sí, exactamente. Sí. Debería marcarlo como un buen primer problema. Sí. Muy bien. Oh, Dios mío. Sigo descartando estos accidentalmente. Veamos. OK. ¿Ejecutaste la IA 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 ella. Así que básicamente la ejecuté en el modo normal y luego permití todo lo que necesitaba hacer. Más tarde, a medida que los modelos y las barandillas mejoraron, en realidad simplemente cambié para usar como para ejecutar con permisos automáticos. Y porque trabajo en una empresa llamada Copilot Kit y a nuestro CTO realmente le encanta escribir habilidades para las IAs para mejorar las barandillas. Tenemos todo un sistema de habilidades que simplemente hace que la salida sea muy, muy buena.

Y te lleva al 95 por ciento allí con las barandillas 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í. Así que 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 era 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 leer esos videos que acabo de mostrarte, donde Codex es mejor para pruebas de codificación en general. Personalmente, tengo curiosidad. ¿Es todo cuestión de sensaciones para ti? ¿Qué estás usando 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 las salidas y veo qué funciona mejor. Y también se reduce mucho al tiempo. Así que, por ejemplo, si toma como siete horas para que Opus llegue allí, y se hace en dos horas, eso es mucho más valioso para mí.

Porque entonces puedo comenzar a probarlo e iterar sobre él como cinco horas antes. Así que realmente puedo probarlo. Y, por ejemplo, para trabajos creativos, es mucho más fácil porque ves visualmente el resultado y dices, oh Dios mío, esto se ve horrible, y dices que este modelo es claramente mejor en trabajos creativos. Así es como descubro las cosas de Opus, porque los videos que genero con GPT son horribles.

Muy bien, el siguiente aquí. Estoy usando el AI SDK de Vercel. ¿Por qué debería cambiar a TanStack AI? Sí, ofrecemos bastantes características que faltan en Vercel. Una de ellas es lazy tools, que es un concepto realmente genial donde básicamente puedes marcar una herramienta como lazy y no enviarla a un LLM. Y básicamente, te permite ahorrar un montón de tokens. Y otra razón es que tenemos code mode, que expliqué anteriormente cómo funciona. No solo ahorra tokens, sino que creo que según el benchmark, completa un 90% más rápido que el bucle de llamada de herramienta regular.

Así que esa es otra gran razón. Bien. Bien. Déjame marcar este también. Bien. Oh, y acabo de ver la pregunta, así que el AI Gateway no es... Entonces AI SDK es la alternativa de código abierto a TanStack AI, pero el 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. Bien.

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. ¿Existen arneses para asegurar la calidad de tus documentos? No puedo hablar por todas las bibliotecas porque no mantengo todas. Mantengo DevTools y la IA. Por lo que puedo decir en IA y DevTools, hay muchas medidas de seguridad para asegurarnos de que escribimos la documentación que necesitamos. Tengo una habilidad llamada doc writing, y la llamo 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 con TanStack AI. No puedo decir por las otras bibliotecas.

Muy bien. Hagamos esta. ¿Cuál encuentras que es el nuevo cuello de botella para tu desarrollo con todas las nuevas ganancias del desarrollo de IA? Sí, esta es bastante fácil de responder. El nuevo cuello de botella soy yo. 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 solo hago clic en recomendado y recomendado. 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 toma como cuatro o cinco días verificarlo manualmente, asegurarse de que sea de buena calidad, que la API sea 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. Es como entrar en una nueva era 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 nueve a cinco. Y luego, cuando terminaba, iba a la tienda de comestibles, pensaba en un problema, cómo puedo resolverlo. La mayoría de las cosas que creé vinieron de mis duchas. Y ahora, después de nueve a cinco, estoy demasiado agotado para pensar. Mi cerebro está frito y simplemente no puedo pensar. Y no tengo idea de lo que voy a hacer 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 potenciadas 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 se intenta meter IA en productos que realmente no necesitan IA. Y luego los desarrolladores tienen que meterlo en sus proyectos. Pero ahora que lo pienso más, otro error es que la gente piensa que para agregar IA a tus proyectos, necesitas todo un nuevo enfoque y cosas así. Donde, por ejemplo, estaba teniendo una masterclass ayer sobre TensorStack 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.

Bien. ¿Qué tal esto? Esto está incluso un poco relacionado.

¿Qué partes de TensorStack AI fueron las más difíciles de construir con asistencia de IA? Creo que el middleware fue la más difícil porque el middleware es como aterradoramente 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 me tomó, usualmente me toma unos días para como 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 usual. Lo bueno es que no puedo dejar la compañía de la manera usual. Así que todos simplemente pierden la experiencia. Así que esa es la parte buena. Pero sí, creo que, he querido, el equipo de React router, solía ser un gran tipo 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 estás documentando. Exactamente. Alimenta eso de vuelta. Sí, en mi experiencia personal, lo encontré bastante efectivo. 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, tú cometiste un error, lo documenta automáticamente en el repositorio para que no lo cometa 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 TenSecMaintainers porque sigo escribiendo habilidades para todo. Y básicamente el flujo habitual es, digamos que quiero escribir una habilidad de TypeScript que va a resolver cosas como casts y cosas así. Básicamente vierto toda mi experiencia y conocimiento de TypeScript en un prompt y luego le digo que escriba una habilidad. Y luego empiezo a probarla ejecutándola en algún código malo de TypeScript y luego veo el resultado. Y luego digo, está bien, 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. Y ese es el flujo habitual que hago, pero realmente no tenemos un proceso interno de mejora de habilidades porque no somos una empresa. Así que si alguien piensa que esto mejorará la habilidad, simplemente lo fusionamos.

Sí. Aquí hay una interesante. ¿Qué hace a 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... Así que como no vendemos productos, no vamos a ser dogmáticos en cosas como persistencia, dónde alojas cosas y cosas así. La idea es que somos completamente sin cabeza. 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, LangChain y cosas así. Genial. Bueno, muchas gracias, Olem. Esto ha sido increíble. Y pensé que tu charla fue increíble. Gracias. Y gracias a todos por venir.