Cómo enseñé a los LLMs a Svelte

Bienvenidos a todos a esta charla que se llama cómo enseñé a los LLMs a sveltear. Antes de comenzar, se debe una pequeña presentación, y 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 como paolo.ricciuti.me. Eso también es correcto. Pero, ¿qué hay de GitHub? Dietabner, ¿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? Y definitivamente mencionaría tu participación con el proyecto Svelte. Eres un embajador de Svelte y un mantenedor de Svelte.

Eso es correcto. ¿Dónde trabajo? Lideras el equipo de Svelte en Mainmatter. Mainmatter es una consultoría de ingeniería que se enfoca 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 se encuentren. Y eso es absolutamente cierto. Hacemos lo que se llama aumento de equipo. Así que puedo trabajar con Svelte pero también enseñar Svelte en mi trabajo diario, y esa es la mejor parte. Recuerda, como siempre, agradece a tus señores.

Oh, está apestando. Déjame eliminar esta conversación. ¿Qué? Se rompió solo. Está bien. Lo arreglaré más tarde. Hablemos. Pero primero, ¿quién aquí, por alguna razón, ya está en la siguiente diapositiva, quién aquí sabe sobre 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 interfaz de usuario 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 la 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++. 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. 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 es 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 props de signo de dólar para recibir props, el signo de dólar para declarar variables, signo de dólar derive para declarar derivaciones, signo de dólar effect para hacer efectos dentro de algo que no está ligado a la reactividad de Svelte, signo de dólar inspect 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. Así que 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 signo de dólar dos puntos, 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 fueras de un lado a otro, 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í que 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. Y ahora Svelte 5 es completamente compatible hacia atrás.

Así que esta es la cantidad de código Svelte 5 en la naturaleza 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 en realidad justifica por qué estaba cometiendo errores tan tontos. Por ejemplo, hizo esto. Intentó importar las runas cuando en realidad estas son solo un constructo del lenguaje. Es como la palabra clave import en JavaScript. También intentó hacer cosas como esta. Como esta fue una de las grandes frustraciones, como el on colon click. Es tan similar al on click que constantemente lo hacen mal. 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 puedes 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 versión antigua de hacer reactividad en un archivo JavaScript basado en store, donde este count habría sido un store y tenías que actualizarlo con dot update. También hicieron algo como esto, que es súper raro, pero he visto a LLMs declarar esto, que es básicamente este punto signo de dólar al final por alguna razón. Y también hicieron algo como esto. Esto es en realidad código Svelte correcto, como que no está mal, solo es semánticamente incorrecto porque double debería ser solo un derived. Reasignar estado dentro de un effect es mal código. Aunque tengo que decir, he visto a muchos ingenieros hacer 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á hecho, están básicamente congelados en el tiempo y no puedes agregarles más contexto. Bueno, en cierto modo puedes, como puedes agregar información a través del contexto y no ese contexto. El contexto que agregas al LLM es solo tú incitándolo. Así es como pueden trabajar en tu base de código. El problema es que si cada vez que tienes que escribir algo, Svelte, tienes que empezar declarando todo lo que Svelte puede hacer y cómo funciona. Quiero decir, escribí un script para agregar esto a Claude, 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 de permitir que los LLMs obtengan la información que necesitan del sitio web de documentación. Y 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 no desperdicies los 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 dirigirlo 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 LLM para poder hacerlo con Svelte.

Entonces, lo que dijimos fue, está bien, creemos un canal de Discord. Ponemos a todos los interesados allí, y realmente comenzamos a lanzar ideas a la pared hasta que algo se quede. Y algo realmente se quedó. 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 tenemos en LLM. Así que es el model. 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 punto es que hay algunos clientes MCP, como Cloud Code o OpenCode, Py 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 fuera, escuchando este JSON payload. Y luego puede hacer algo en el mundo real, por ejemplo, el servidor MCP linear 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 útil 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 que puedes hacer cosas bastante curiosas.

Ahora no voy a usar esto porque sería el clicker más caro de todos. El punto es que en ese momento queríamos usar MCP, pero yo todavía era bastante escéptico porque ¿qué haces con un MCP para un framework? Puedes inyectar documentación. Y así fue la línea inicial de pensamiento. Así que Scott Spence, que por cierto, si estás interesado en IA, deberías absolutamente seguirlo porque siempre está en la vanguardia de la IA. Comenzó a experimentar con esta documentación MCP Svelte para alimentar la documentación 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ó el relevo y comenzó a desarrollar algo con lo que realmente más personas comenzaron a trabajar, que es el Svelte LLM MCP. Y básicamente se trataba de alimentar la documentación 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 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 agéntico 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 agéntico. Así que escribes el código como al LLM, el LLM escribe el código antes de realmente volver al LLM, pasa por el Svelte MCP. Y el Svelte MCP, lo que hace 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. 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? Como 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. Como 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 call on click, por ejemplo. Aquí on call on click, verás que el LLM está diciendo, oye, usar on click para escuchar el evento de clic 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 vamos a duplicar $state, cero, como estábamos haciendo antes. Y hago $effect double es igual a count time two. No sé si cometí algún error. Sí, hay un un... Aquí, lo vi. Bien. Así que puedes ver que ahora, incluso si este es un código Svelte normal, como que 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 un problema. Podrías usar un derived para eso. Así que esto realmente 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 buen código incluso con modelos locales, por ejemplo. Si hice eso, como puedes ver, después de 30 minutos, tuve que apagarlo porque simplemente no estaba corrigiendo las cosas que necesitaban ser corregidas. Lo mismo, por ejemplo, con esto. Esperemos que cargue. No cargará. Ese es un problema. Bien. No sé por qué. Hay un pequeño... Bien. Este es GPTUSS20Billion, que en realidad fue capaz de escribir buen código Svelte una vez.

¿Qué? Buen código una vez. Pero como puedes ver, estaba empezando a volverse loco y decir, bien, estoy atascado. Estoy atascado.

Pero cuando funciona, y una vez más el video cargará lentamente. Cuando llegues a eso, llegaremos a eso. Cuando funciona, es realmente bastante 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 un Minesweeper. De hecho, comenzó a usar el MCP leyendo la documentación, obteniendo las secciones, 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 Svelte 4. No funcionaba con Svelte 5. Pero comenzó a usar el auto fixer, y una y otra vez verás en un segundo, corrigió cada problema que el auto fixer reportó, y al final, realmente obtuvo un sorprendentemente buen código Svelte 5.

Así que, obviamente no enviamos solo, de nuevo, el video 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 dirigir el modelo para usar el MCP sin tener que escribir todo a mano. Y si tu agente no lo soporta, puedes simplemente copiarlo de la documentación de Svelte. También enviamos con esta agradable herramienta. Como, si estás usando, 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 a Playground, que realmente te permite abrir el enlace a 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 algo 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 el 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, OK, 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 get documentation 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? Esa es una pregunta para las 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 central de Svelte, 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, esto 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 el agente también pueda aprender. Obviamente, una vez más, las habilidades están disponibles en la documentación si deseas descargarlas.

Hablemos sobre la gestión de contexto. Así que la gestión de contexto, sabemos que es un problema con la IA, como que 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 el subagente. Así que el subagente permite a un agente crear una versión de sí mismo con su propia ventana de contexto. Y literalmente puedes ejecutar en este subagente cerrado, puedes ejecutar cada operación atómica. Y así, en realidad enviamos un subagente oficial que le dice al agente, oye, cada vez que tengas que escribir un componente Svelte, no lo hagas en el bucle principal. Simplemente invoca al subagente, haz cada llamada MCP o llamada CLI allí, escribe el componente y reporta cualquier problema al padre.

De esta manera, la documentación nunca se filtrará en el agente oficial. Obviamente, esto será bastante aburrido de configurar, ¿verdad? Bueno, afortunadamente, en realidad enviamos como las herramientas de IA de Svelte se envían como un plugin de Cloud Code. Así que puedes simplemente instalar el marketplace e instalar este plugin de Svelte y obtendrás todo. También enviamos como un plugin de open code. 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 issue y lo vamos a arreglar.

Lo primero de lo que hablar es el benchmark. Stanislav también creó el primer borrador del benchmark de Svelte, que básicamente era una forma de probar LLMs en qué tan buenos eran escribiendo Svelte. Pero esto no soportaba habilidades ni nada más. Así que en realidad creamos un banco de pruebas de AI SDK con el AI SDK para ejecutar el mismo benchmark con el MCP o las habilidades. Y también creamos Svelte evals. En realidad ejecutamos una prueba mucho más amplia con un arnés real en 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 abrir eso. Y como siempre, gracias por ver.

Sí, funcionó. El primero que destaqué aquí fue, ¿puedes lograr lo mismo con la herramienta existente como ESLint o cualquier tipo de herramienta existente? Así que primero que nada, sí y no. En el sentido de que en realidad ejecutamos ESLint como parte de la tubería de corrección automática. Así que sí, esos son parte. Técnicamente puedes escribir el mismo corrector automático como plugins 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 el linting al final. Así que eso podría funcionar absolutamente si quieres tomarte el tiempo para simplemente escribir todos los problemas. 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 el repositorio es un colector de errores normales. Como cuando la gente nota muchos errores, vienen al repositorio de Svelte AI y dicen, oye, la IA se ha encontrado con estos múltiples veces. Así que podemos recopilar los errores comunes dentro del repositorio de correctores automáticos.

Bien, genial. Así que eso significa que muchas de estas cosas se pueden hacer con la herramienta existente 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 de agente? Así que como estabas hablando de habilidades de agente. ¿Qué pasaría si pudieras enviarlas en módulos de Node? Así que cuando haces npm install o algo así, simplemente lo obtienes en tus módulos de Node. Creo que es una idea interesante. Y en realidad he visto agentes entrar en módulos de Node en el código literal para averiguar qué está mal, especialmente porque Svelte está escrito en JavaScript y la verificación de tipo se realiza con JS doc. Así que en realidad obtienes el código real que se está ejecutando. Así que he visto agentes entrar en módulos de Node 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 todavía obtendrás ese pequeño paquete de habilidades en tu sitio de instalación. Lo cual, quiero decir, está bien porque como todos saben, la carpeta de módulos ya tiene 30 gigabytes. Así que supongo que esa es solo una desventaja.

Sí, así que lo que estoy escuchando es que se trata mucho de llegar a los usuarios y usar las mismas herramientas que están usando, dándoles todas las posibilidades en cualquier ecosistema en el que estén. Una cosa que también me interesa 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 apps 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 has estado siguiendo lo último y lo mejor de Svelte, es realmente como si recientemente estamos haciendo mucho trabajo en Async Svelte, por ejemplo. Así que ahora mismo literalmente puedes esperar algo dentro de la plantilla y funcionará y funcionará. ¿Cómo lo esperas? Y también específicamente para Svelte, simplemente nos gusta, 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 literalmente es 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 como tienes que mantener los dos lados, el cliente y el servidor en sincronía.

Genial. Genial. Así que estoy escuchando que hay muchas cosas como tipo baterías 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 es realmente convincente. Así que creo que para ser franco, al final del día, como cada marco, tienes una manera de hacer lo que tienes que hacer. 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 ir. Podríamos hacerte pasar por un montón de obstáculos para hacerlo funcionar. O podríamos hacer el trabajo duro y hacer que simplemente escribas esperar algo y funcione y funcione mágicamente porque somos un compilador y podemos hacer mucho trabajo detrás de escena. 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 parece el JavaScript normal. Así que no hay nada raro. No hay nada sorprendente al respecto. Sí.

OK, eso tiene sentido. Otro aquí es este el auto corrector. Entonces, si no está entendiendo los props del componente Svelte, ¿es esto algo que puede ser consciente de o.

Estoy bastante seguro. ¿Quién hizo esta pregunta? Levante la mano si esto es sobre una advertencia que recibe cuando pasa el 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. Como, es una advertencia que estamos muertos y estamos pensando en una forma de evitar eso cosa. Como, el problema es, es cierto en Astro. Es estático. También puede ser estático en Svelte. Podemos pensar en una forma. Por favor, abra un issue en el repo 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 auto-corrección. Así que, una vez más, creo que una de las cosas buenas del auto-corrector de Svelte es que no está corrigiendo el código por ti. Solo le está diciendo al LLM que lo corrija y cómo corregirlo. 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 el LLM 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 es. Genial.

Entonces, ¿usaste algún rag en esto? Como cuando estabas tratando de enseñarle sobre Svelte kit routing o algo para proporcionar la documentación más reciente o ¿cómo lo hiciste? Así que esto fue en realidad como ideas que se lanzaron a la pared en ese entonces. El problema con afinar un modelo para eso. El problema es que si sale un nuevo modelo, tenemos que volver a afinar ese nuevo modelo. 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 documentación más reciente directamente de los documentos. Y es por eso que, de nuevo, el rag se hace 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.