How I Taught LLMs How to Svelte

Muy bien. Bienvenidos a todos a esta charla que se llama Cómo enseñé a los LLMs a usar Svelte. Antes de comenzar, se debe una pequeña presentación. Obviamente, dado el tema, traje a mi asistente conmigo, así que veamos. ¿Puedes ayudarme a presentarme? Absolutamente puedo ayudarte a presentarte. Eres Paolo Ricciuti. Eso es correcto. ¿De dónde vengo? Vienes de Campobasso, Italia. Eso es correcto. Es una ciudad muy pequeña, pero es correcto.

¿Dónde puede la gente encontrarme en línea? La gente puede encontrarte en bluesky.me. Eso también es correcto. Pero, ¿qué hay de GitHub? ¿Diet Abner? ¿Qué? Quiero decir, GitHub. Está bien. GitHub. Veamos qué dice. Tienes toda la razón. La gente también puede encontrarte en GitHub como Paolo Ricciuti. Eso es correcto.

¿Cómo me presentarías a estas personas? Definitivamente mencionaría tu participación en el proyecto Svelte. Eres un embajador y mantenedor de Svelte. Eso es correcto. ¿Dónde trabajo? Lideras el equipo de Svelte en Main Matter. Main Matter es una consultoría de ingeniería que se centra en Svelte, Rust y Ember. Te asocias con clientes para resolver sus desafíos más difíciles o adoptar Svelte dependiendo de dónde estén. Eso es absolutamente cierto. Hacemos lo que se llama aumento de equipo. Trabajo con Svelte, pero también enseño Svelte en mi trabajo diario, y esa es la mejor parte. Recuerda, como siempre, agradece a tus superiores, así que gracias. Y podemos pasar a la siguiente diapositiva.

Oh, está apestando. Déjame eliminar esta conversación. ¿Qué? Se rompió solo. Está bien. Lo arreglaré más tarde.

Hablemos. ¿Quién aquí por alguna razón ya está en la siguiente diapositiva, quién aquí conoce Svelte? Entonces levantando las manos. Bien. Mucha gente. El resto puede irse, por favor. No, estoy bromeando.

Puedes quedarte para que realmente aprendas algo. Entonces Svelte, es un framework de UI que utiliza un compilador para permitirte escribir componentes increíblemente concisos que hacen un trabajo mínimo en el navegador usando lenguajes que ya conoces, HTML, CSS y JavaScript. Es una carta de amor al desarrollo web. Y realmente lo pienso, porque este es un componente de Svelte. Y como puedes ver, es muy parecido a HTML. Tienes la etiqueta script donde puedes declarar variables. Tienes estas reglas de estado con signo de dólar, que es una sintaxis del lenguaje Svelte que te permite declarar variables reactivas. Puedes importar y hacer cosas dentro de la etiqueta script. Luego tienes la parte de plantilla, que es básicamente lo que se renderiza en el navegador.

Y como puedes ver, puedes usar llaves para renderizar una variable. Todo lo que declares en la etiqueta script también está disponible en la plantilla. También puedes cambiar variables sin usar set count, por ejemplo. Como count se declara como una variable reactiva, pero es solo una variable normal. Es un número. Puedes simplemente hacer count plus plus. También obtienes estilos gratis. Así que no tengo que usar una clase aquí, porque cada estilo está contenido en el componente que lo declara. Así que puedo simplemente usar button.

Y estos estilos se aplicarán solo a este componente. Así que eso es muy bueno. Sin embargo, este es un componente de Svelte 5. Y notas que tengo que hacer algún tipo de especificación. Como si fuera un componente de Svelte 5. La razón es que en Svelte 5, tuvimos nuestros mayores cambios de sintaxis. Así es como se ve, con estos dollar sign props para recibir props, un dollar sign state para declarar variable, dollar sign derive para declarar derivaciones, dollar sign effect para hacer efectos dentro de algo que no está vinculado a la reactividad de Svelte, dollar sign expect para registrar tus variables con este onclick, que es solo un prop del botón. Y así es como se veía en Svelte 4. Así que era muy diferente. Aún similar. Como la mayoría de los cambios están en la etiqueta script. Pero es muy diferente. Tenemos este export let para exportar un prop. Count era solo una variable. Y era automáticamente reactiva. Y luego teníamos esta sintaxis extraña con este dollar sign colon, que en realidad es JavaScript válido para hacer tanto derivación, efectos, e incluso para registrar. Y luego teníamos este oncolon click, que eran directivas de eventos. Así que es muy diferente. Como, si vas hacia atrás y hacia adelante, es muy diferente. Y desafortunadamente, lanzamos esto básicamente cuando los agentes estaban comenzando a ser una cosa. Y sabes quién realmente no le gustan los grandes cambios de sintaxis? Obviamente. Lo adivinaste. Nuestros futuros señores. Y así, por un tiempo, esta fue la experiencia promedio de las personas que querían escribir Svelte 5. Así que esto no fue tan genial. Y si lo piensas, en realidad tiene sentido. Porque si tomamos este gráfico, esta es la cantidad de código Svelte 5 en el mundo. Ahora, Svelte 5 es completamente compatible hacia atrás. Así que esta es la cantidad de código Svelte 5 en el mundo que se parece a Svelte 4. Si a esto, le sumamos el código real de Svelte 4, y a esto, le sumamos el hecho de que Svelte 3 era literalmente lo mismo que Svelte 4, puedes ver cómo el desequilibrio en términos de conjunto de entrenamiento está justificando por qué estaba cometiendo errores tan tontos.

Por ejemplo, hizo esto. Intentó importar las runas cuando en realidad estos son solo un constructo del lenguaje. Es como la palabra clave import en JavaScript. También intentó hacer cosas como esta. Esta fue una de las grandes frustraciones, como el on-colon click. Es tan similar al on-click que constantemente lo confunden. También hicieron algo como esto, que es más sutil, porque derived en realidad recibe una expresión, no una función. Pero esto significa que probablemente puedas pasar por alto este error del LLM. También hicieron algo como esto, que básicamente mezcla la versión de runas, que es la nueva versión de hacer reactividad, con la antigua versión de hacer reactividad en un archivo JavaScript que estaba basada en store, donde este count habría sido un store y tenías que actualizarlo con .update. También hicieron algo como esto, que es súper raro, pero he visto LLMs declarando esto, que es básicamente este .$ al final por alguna razón. Y también hicieron algo como esto. Esto es en realidad código Svelte correcto. No está mal, solo es semánticamente incorrecto, porque double debería ser solo un derived. Reasignar el estado dentro de un effect es un mal código, aunque debo decir que he visto a muchos ingenieros haciendo eso, y quiero que sepan que los estoy juzgando.

Así que el problema con los LLMs es que una vez que su conjunto de entrenamiento está completo, básicamente están congelados en el tiempo, y no puedes agregarles más contexto. Bueno, en cierto modo puedes. Puedes agregar información a través del contexto, y no ese contexto. El contexto que agregas al LLM es solo tú dando indicaciones. Así es como pueden trabajar en tu base de código. El problema es que si cada vez que tienes que escribir algo en Svelte, tienes que empezar a declarar todo lo que Svelte puede hacer y cómo funciona. Como, quiero decir, escribí un script para agregar esto a Cloud, y ya estoy aburrido de ello. Y así, durante el Advent of Svelte 2023, creo que 2024, lanzamos LLMs.txt, que fue uno de los primeros intentos para permitir que los LLMs obtuvieran la información que necesitan del sitio web de documentación. Ahora, si vas a los documentos de Svelte, puedes añadir LLMs.txt a cada página de documentación, y obtienes algo como esto, que es básicamente la misma versión de la documentación, pero en archivos Markdown para que, como, no desperdicies tokens. Y esto fue un poco bueno, pero este estándar nunca realmente despegó. Y así estábamos siendo constantemente bombardeados con, quiero usar Svelte, pero no puedo porque la IA no puede escribir Svelte. Y quiero usarlo, pero entonces mi compañero de trabajo no podrá usar la IA para construir el componente de Svelte correctamente, y tengo que guiarlo constantemente, y tengo que, como, así que recibimos mucha información.

Y así, durante nuestra reunión mensual de mantenedores, dijimos, está bien, necesitamos hacer algo al respecto. Y de hecho comenzamos una verdadera fuerza de tarea específicamente para esto. No porque queramos ayudar a los LLMs, sino porque queremos ayudar a nuestros usuarios que quieren usar para poder hacerlo con Svelte. Y así lo que dijimos, dijimos, está bien, vamos a crear un canal de Discord.

Pusimos a todos los interesados allí, y realmente comenzamos a lanzar ideas a la pared hasta que algo se pegó. Y algo realmente se pegó. Así que si echas un vistazo, hay más menciones sobre algo llamado MCP. ¿Qué es un MCP? Bueno, MCP significa Model Context Protocol. Y model es literalmente la misma M que estamos en LLM. Así que es el modelo. Es el modelo LLM. Context es de lo que acabamos de hablar. Y protocol es una palabra mucho más antigua, y es solo una forma para que dos partes se comuniquen entre sí con un lenguaje compartido.

En este caso, en el caso de MCP, es JSON RPC 2.0. El problema, básicamente el punto es que hay algunos clientes MCP, como Cloud Code o OpenCode, Pi, o Goose, pero hay literalmente cientos de ellos. Y no son el LLM real. Son una especie de envoltorios alrededor del LLM. Y también pueden conectarse a servidores MCP. Y el servidor MCP es solo un programa que está ya sea a través de HTTP o a través de estándar en y estándar out, escuchando este payload JSON. Y luego puede hacer algo en el mundo real. Por ejemplo, el servidor MCP lineal podría cerrar un issue por ti, o pueden enviar de vuelta información al cliente MCP, que luego alimenta esa información al LLM.

Así que pueden enviar de vuelta la información al cliente MCP. Por ejemplo, la herramienta MCP de Chrome es muy usable porque abrirá una instancia de Chrome y realmente puede obtener de vuelta el árbol de accesibilidad, por ejemplo, para la página. Ahora, MCP es realmente bastante curioso, y puedes hacer cosas bastante curiosas con él. Por ejemplo, este conjunto de diapositivas es en realidad un servidor MCP, y está conectado a mi instancia de OpenCode. Así que puedo decir, ¿puedes ir a la siguiente diapositiva? Y si todo funciona, yay, funcionó. Y aquí debería haber habido confeti. Por alguna razón, no están. El punto es, puedes hacer cosas bastante curiosas.

Ahora, no voy a usar esto porque sería el clicker más caro de la historia. El punto es que, en ese momento, queríamos usar MCP. Pero todavía era bastante escéptico porque, ¿qué haces con un MCP para un framework? Puedes inyectar docs. Y así fue la línea inicial de pensamiento. Así que Scott Spence, que, por cierto, si estás interesado en AI, deberías absolutamente seguir porque siempre está en la vanguardia de AI. Comenzó a experimentar con estos MCP Svelte docs para alimentar los docs de Svelte al LLM a través del MCP. Según su propia admisión, no llegó tan lejos como quería. Así que Stanislav Koromov tomó, de hecho, el manto y comenzó a desarrollar algo con lo que realmente más personas comenzaron a trabajar, que es el Svelte LLMs MCP, y básicamente era alimentar los docs de Svelte al mismo LLM.txt que puedes leer a través del protocolo MCP. Y esto realmente estaba funcionando. Y de hecho comenzamos desde esto para construir el servidor oficial de Svelte MCP.

Pero si volvemos a esta diapositiva aquí, puedes ver que además de que podemos usar el MCP, también hay otra idea rondando. Y esta idea es el hecho de que podríamos ejecutar un script de algún tipo, de alguna manera determinista para determinar si el código es correcto. Así que este es el flujo de trabajo agente normal, ¿verdad? Tú, el usuario, escribes a un LLM. El LLM escribe el código, luego verifica el código, luego escribe el código, luego verifica el código. Cuando está satisfecho con él, volverá a ti. Ahora, lo que hicimos fue básicamente agregar otra parte de este flujo de trabajo agente. Así que escribes el código al LLM, el LLM escribe el código, antes de realmente volver al código al LLM, pasa por el Svelte MCP. Y lo que hace el Svelte MCP es que ejecuta un análisis estático en el código para descubrir si el LLM generó algún error común, como el hecho de que está usando .update, el hecho de que está usando .$ para leer una variable. Tenemos una lista, básicamente, de errores comunes. Y cada vez que encontramos un nuevo error común, simplemente lo corregimos con análisis estático. Y lo bueno de esto es que no solo puedes devolver cosas que nunca devolverías a un usuario, porque nunca le dirías a un usuario, oye, tal vez estás haciendo $, como .$, ¿estás seguro de que eso es realmente una propiedad en ese objeto y no otra cosa? Nunca le dirías esto a un usuario.

Pero lo más importante, dado que estamos hablando con un LLM, podemos devolver información en lenguaje natural. No tenemos que corregir el código para el LLM. Podemos simplemente devolver algunas sugerencias y luego dejar que el LLM lo resuelva. Así que juguemos un pequeño juego, y digamos que somos el LLM. Este es un editor que está realmente conectado al servidor MCP real. Así que si hago cosas como esta, y tengo que mirar eso, así que digamos que hago, no sé, on column click, por ejemplo, aquí, on column click, verás que el LLM está diciendo, oye, usar on click para escuchar el evento click está obsoleto. Si hago cosas como esta, por ejemplo, .$, incluso si esto es técnicamente código Svelte correcto, estoy diciendo que estás tratando de leer la variable de estado count usando $. Las variables de estado deberían simplemente accederse en tiempo de ejecución como variables normales. Y lo bueno de esto es que también podemos guiar al modelo para escribir código Svelte adecuado.

Así que hagamos, let double es igual $state cero, como estábamos haciendo antes. Y hago $effect double es igual a count time dos. No sé si cometí algún error. Sí, hay otro, aquí, lo vi. Bien, puedes ver que ahora, incluso si este es un código Svelte normal, como, no tiene un error, está diciendo que la variable con estado double se asigna dentro de un efecto. Por favor, asegúrate de que eso no esté creando problemas. Podrías usar un derivado para eso. Así que esto funcionó sorprendentemente bien. Así que si el video carga, sí, correctamente.

Ahora esto no es obviamente, como, funciona sorprendentemente bien, pero no es como una bala, una bala de plata. Por ejemplo, aquí estaba usando un $quen3 porque siempre ejecuto el MCP en un modelo muy tonto porque quiero poder escribir código bueno y adecuado incluso con modelos locales, por ejemplo. Si hice eso, como puedes ver, después de 30 minutos tuve que apagarlo porque simplemente no estaba arreglando las cosas que necesitaban ser arregladas. Lo mismo, por ejemplo, con esto. Espero que cargue. No cargará. Eso es un problema. Bien. No sé por qué hay un pequeño...

Bien. Este es GPT-OSS 20 billion que en realidad fue capaz de escribir código Svelte bueno y adecuado una vez. ¿Qué? Código bueno y adecuado una vez. Pero como puedes ver, estaba empezando a volverse loco y decir, bien, estoy atascado. Bien, estoy atascado. No sé qué hacer. Porque no era lo suficientemente inteligente para hacer lo que el MCP le estaba diciendo que hiciera. Pero cuando funciona, y una vez más el video cargará lentamente, cuando lleguemos a eso, llegaremos a eso. Cuando funciona, es realmente interesante. En el video que está a punto de cargar, Mistral, que también es un modelo bastante tonto, básicamente uno de mis prompts favoritos es construir Buscaminas. Y en realidad comenzó a usar el MCP leyendo la documentación, obteniendo las secciones, por... No sé.

Por alguna razón, comenzó a hacer una imagen del diseño. Pero luego básicamente generó un código que era muy malo. Esto era básicamente código de Svelte 4. No funcionaba con Svelte 5. Pero comenzó a usar el autofixer. Y una y otra vez, verás en un segundo, solucionó cada problema que el autofixer reportó. Y al final, en realidad obtuvo un código Svelte 5 sorprendentemente bueno.

Así que obviamente no enviamos solo... Nuevamente, el video se está cargando lentamente. Lo siento. Pero no enviamos solo el MCP. También enviamos con recursos, que son básicamente archivos que puedes agregar. Y esos son solo los mismos archivos que obtendrás como LLMs.txt. Y puedes simplemente agregarlos directamente en tu gráfico, lo cual es mucho, mucho mejor. Y también enviamos con prompts, que es una forma de guiar al modelo para usar el MCP sin tener que escribir todo a mano. Y si tu agente no lo soporta, puedes simplemente copiarlo de los documentos de Svelte docs.

También enviamos con esta herramienta agradable. Como, si estás prototipando en Cloud. ai, por ejemplo, no podrán ejecutar el código Svelte que generan. Y así enviamos con un enlace de playground, que en realidad te permite abrir el enlace de playground con el código generado. Y puedes jugar con él. Y si tu agente soporta MCPUI, estará directamente en el LLM. Así que eso es todo. Hemos terminado. Bueno, no tan rápido, desafortunadamente. Porque si hay algo que los desarrolladores realmente, realmente odian es quedarse en lo mismo por más de dos semanas, especialmente en IA. Así que comenzamos con MCP, pero luego algunos desarrolladores dicen, bueno, ¿qué pasa si puedo usar un CLI y tal vez algunas habilidades? Y tal vez incluso echar un vistazo a la gestión de contexto. Y así lo hicimos. Y una vez más... Bien.

Está cargando. Así que ahora el Svelte MCP es en realidad también un CLI que puedes usar directamente en el terminal. Y puedes simplemente ejecutar los mismos comandos, como listar sección para obtener la lista de la sección. Puedes ejecutar obtener documentación para obtener la documentación directamente en tu terminal. También puedes ejecutar el Svelte autofixer en un archivo. Así que puedes simplemente hacer esto para obtener documentación, por ejemplo. Y también puedes hacer Svelte autofixer pasando un archivo para que lo corrija automáticamente. Y obtendrás el mismo resultado que arriba.

Sin embargo, ¿cómo sabrá el agente sobre esto? Bueno... Es una pregunta para habilidades. Así que enviamos dos habilidades. El escritor de código Svelte, que básicamente solo enseña a tu agente cómo usar el Svelte MCP a través del CLI. Y otra interesante es la mejor práctica de Svelte core, que es una habilidad más pura que solo enseña a tu LLM cómo escribir muy buen Svelte directamente de Rich Harris, quien fue el creador. Y otro punto interesante es que esto no es algo que solo interese a los agentes ¿verdad? Y así Svelte afirma ser un framework centrado en el humano. Y así, en realidad, esta es solo una página de documentación. Así que cuando estás aprendiendo Svelte, puedes aprender la mejor práctica. Y luego convertimos eso en una habilidad para que los agentes también puedan aprender. Obviamente, una vez más, las habilidades están disponibles en la documentación si deseas descargarlas.

Y hablemos sobre la gestión de contexto. Así que la gestión de contexto, sabemos que es un problema con la IA, como necesitas tener el contexto lo más bajo posible. Y una forma de hacerlo, en mi opinión, y algo que mucha gente realmente pasa por alto, es sub-agentes. Así que los sub-agentes permiten a un agente crear una versión de sí mismo con su propia ventana de contexto. Y literalmente puedes ejecutar en este sub-agente cerrado, puedes ejecutar cada operación atómica. Y así, en realidad enviamos un sub-agente oficial que le dice al agente, oye, cada vez que tengas que escribir un componente Svelte, no lo hagas en el bucle principal, solo invoca al sub-agente, haz cada llamada MCP o llamada CLI allí, escribe el componente e informa cualquier problema de vuelta al padre. De esta manera, la documentación nunca se filtrará al agente oficial. Obviamente, esto sería bastante aburrido de configurar, ¿verdad? Bueno, afortunadamente, en realidad enviamos, como las herramientas de Svelte AI, se envían como un plugin de código en la nube. Así que puedes simplemente instalar el marketplace e instalar el plugin de Svelte y obtendrás todo. También enviamos como un plugin de código abierto, enviamos como un plugin de cursor, enviamos como un plugin de GitHub. Quiero decir, lo adivinaste, como, si tienes algo que tiene plugin y no lo soportamos abre un problema y lo vamos a arreglar. Última cosa de la que hablar, benchmark.

Entonces, AI Slav también creó el primer borrador del benchmark de Svelte, que básicamente era una forma de probar LLMs sobre qué tan buenos eran escribiendo Svelte. Pero esto no soportaba habilidades ni nada más. Así que realmente creamos un AI SDK bench con el AI SDK para ejecutar el mismo benchmark con el MCP o las habilidades. Y también creamos Svelte Evals, en realidad realizamos una prueba mucho más amplia con un arnés real de páginas de SvelteKit.

Ahora eso es todo, necesito correr, se me acabó el tiempo. Así que si estás interesado, puedes visitar la documentación de Svelte, si estás interesado en cómo MainMatter puede ayudarte, puedes visitar MainMatter.com. Además, recientemente lanzamos una serie en YouTube sobre ingeniería agéntica con Svelte. Así que si estás interesado en eso, también puedes abrirlo. Y como siempre, gracias por ver.

Sí, funcionó. El primero que destaqué aquí fue, ¿puedes lograr lo mismo con las herramientas existentes como ESLint o cualquier tipo de herramienta existente? Así que primero que nada, como sí y no. En el sentido de que realmente ejecutamos ESLint como parte del pipeline de auto-corrección. Así que sí, esos son parte. Técnicamente puedes escribir los mismos plugins de auto-corrección como un plugin de ESLint y luego ejecutarlo en tu CLI local. Lo que noté es que primero, los agentes son mucho más propensos a invocar una herramienta MCP múltiples veces y simplemente ejecutan linting al final.

Así que eso podría funcionar absolutamente si quieres tomarte el tiempo para simplemente escribir todos los problemas. Y supongo que la ventaja que tienes sobre una regla de ESLint que creces en la ciudad, como en tu base de código, es el hecho de que en realidad, como el repo es en realidad un colector de errores normales. Como cuando la gente nota muchos errores, vienen al repo de Svelte AI y dicen, oye, como que la IA se ha encontrado con estos múltiples veces. Así que podemos recopilar los errores comunes dentro del repo de auto-corrección.

Bien, genial. Así que eso significa que muchas de estas cosas pueden ser hechas por las herramientas existentes de ESLint. Si quieres configurar todo, puedes absolutamente. Si quieres configurarlo. Sí. Otra cosa que estaba un poco relacionada que vi aquí es que ¿qué pasaría si pudieras enviar las habilidades del agente? Así que estas, como hablabas de habilidades del agente. ¿Qué pasaría si pudieras enviarlas en node modules? Así que cuando haces NPM install o algo así, simplemente lo obtienes en tus node modules.

Creo que es una idea interesante. Y en realidad he visto agentes entrar en node modules en el código literal para averiguar qué está mal, especialmente porque Svelte está escrito en Javascript y la verificación de tipos se hace con JS doc. Así que en realidad obtienes el código real que está ejecutándose. Así que he visto agentes entrar en node modules y leer el código real para corregir un problema. Así que definitivamente es una idea interesante. La desventaja es que si no estás usando habilidades y no estás usando agentes tal vez, entonces aún obtendrás ese pequeño paquete de habilidades en tu sitio instalado. Lo cual quiero decir, está bien porque como que la carpeta de node models de todos ya es de 30 gigabytes.

Pero supongo que esa es solo la única desventaja. Sí. Así que lo que estoy escuchando es que se trata mucho de acercarse a los usuarios y usar las mismas herramientas que ellos están usando, dándoles todas las posibilidades en cualquier ecosistema en el que se encuentren. Una cosa que también me resulta interesante es la cuestión de la adopción. Así que también lo destaqué en la parte superior. Así que Svelte es algo que tal vez no está en el mismo tipo de popularidad que algo como React o algo así. Entonces, ¿cómo compite Svelte o cómo ves la adopción con LLMs y este tipo de micro aplicaciones y cosas así? Así que creo que en términos de adopción personalmente, creo que está creciendo. Tal vez es solo porque estoy en una burbuja. Así que no lo sé, pero creo que está creciendo. Y en términos de cómo se diferenciará de la vista de los componentes web, si no has estado siguiendo lo último y lo mejor de Svelte, en realidad, como recientemente estamos haciendo mucho trabajo en Svelte asíncrono, por ejemplo. Así que ahora mismo puedes literalmente esperar algo dentro de la plantilla y funcionará y funcionará. Así que eso es lo que esperas. Y también específicamente para Svelte, todavía es experimental, pero estamos haciendo funciones remotas, que es, en mi opinión, la mejor manera, como la mejor abstracción alrededor de la carga de datos, porque es literalmente solo una función que declaras en un archivo diferente porque no queremos que el código del servidor se mezcle con el código del cliente. Como es un archivo separado, pero luego puedes importarlo en el cliente y simplemente llamarlo como una función. Y también, lo más importante para los formularios, creo que la abstracción de formularios es la mejor porque también obtienes, por ejemplo, autocompletado sobre cuáles son los nombres de los campos, lo cual es algo que siempre es muy difícil de hacer cuando haces formularios y tienes que mantener los dos lados, el cliente y el servidor en sincronía.

Genial, genial. Así que estoy escuchando que hay muchas cosas incluidas, cosas que están incluidas allí. Lo siguiente que moví a la parte superior aquí es, entonces, si fueras a vender a una audiencia de React ¿qué sería algo que está en el ecosistema de Svelte? Quiero decir, hablaste de formularios ahora y hablaste de estas funciones, que no están realmente en React o algo que sea realmente atractivo? Así que creo que para ser franco, al final del día, cada marco, tienes una manera de hacer lo que tienes que hacer, ¿verdad? Así que se trata solo de la DX. Así que creo que lo que diferencia a Svelte del resto es que realmente nos importa profundamente tu DX. Realmente nos importa que tengas la API más natural para algo. Por ejemplo, funciones remotas, quieres esperar algo, podríamos hacerte pasar por un montón de obstáculos para que funcione. O podríamos hacer el trabajo duro y hacer que simplemente escribas, espera algo, y funcione. Y funciona mágicamente porque como somos un compilador y podemos hacer mucho trabajo detrás de las escenas. Y eso es definitivamente algo. También es uno de los marcos más rápidos de todos modos. Y en general, es muy cercano a lo que el JavaScript normal parece. Así que no hay nada raro en ello, no hay nada sorprendente en ello. Sí. Bien. Eso tiene sentido.

Otro aquí es este, el autofijador. Entonces, si no está entendiendo las props del componente Svelte, ¿es esto algo de lo que se puede hacer consciente? Estoy bastante seguro. No lo sé. ¿Quién hizo esta pregunta? Levante la mano si esto es sobre una advertencia que recibe cuando pasa una prop a un estado. No sé si todavía está aquí. Era así. Sí. Así que eso es algo real que no es solo sobre Astro. Es una advertencia que estamos muertos y estamos pensando en una forma de evitar eso. El problema es que es cierto en Astro. Es estático. También puede ser estático en Svelte. Podemos pensar en una forma. Por favor, abra un problema en el repositorio y tal vez podamos pensar en algo para señalar eso. Genial. Sí. Así que supongo que aún no has ido en esta dirección, pero es una idea interesante como el linter MCP agnóstico al lenguaje que tiene algo como capacidades de autofijación. Así que una vez más, creo que una de las cosas buenas del autofijador de Svelte es que no está arreglando el código por ti. Solo le está diciendo a DLLM cómo arreglarlo. Creo que esa es una distinción realmente importante porque hay un límite en lo que el análisis estático puede hacer. Y también hacerlo agnóstico sería muy interesante. Pero cada proyecto tiene reglas diferentes. Cada proyecto tiene diferentes maneras en las que DLLM se equivoca básicamente. Así que, como en Svelte, tenemos una colección y creo que esa colección de errores similares es lo que hace que el MCP sea poderoso como lo es. Genial. Entonces, ¿usaste algún RAG en esto? Como cuando estabas tratando de enseñarle sobre el enrutamiento de SvelteKit o algo para proporcionar la última documentación o cómo lo hiciste? Así que esto fue en realidad como, estas eran ideas que se lanzaron a la pared en ese entonces. El problema con afinar un modelo para eso, el problema es que luego si sale un nuevo modelo, tenemos que volver a afinar ese nuevo modelo. Y también si tienes una suscripción cerrada, no puedes usar nuestro modelo. Así que la razón por la que elegimos MCP es porque queríamos que te conectaras a cualquier sistema que tengas. También pensamos en RAG para eso. Y quiero decir, no es realmente RAG, como si solo estuviéramos obteniendo la última documentación directamente de los documentos. Y es por eso que, de nuevo, el RAG se realiza a través del MCP en tu LLM básicamente. Genial. Sí, creo que eso es todo el tiempo que tenemos. Pero sí, un aplauso para Paolo.