Si estás metido en esto de crear apps con inteligencia artificial, tarde o temprano te pasa lo mismo: te acostumbras a pagar, a depender de ciertos modelos premium y a sentir que “si no pago, no avanzo”. Pues bien, en este artículo vamos a romper esa lógica con un modelo que, según lo probado, está disponible de forma gratuita: QWEN 3.6 Plus.
El enfoque es simple: usar QWEN 3.6 Plus para construir una app web completa, apoyándonos en un agente dentro de un entorno de desarrollo. Veremos cómo instalar y usar Kilo Code en VS Code, y también una alternativa clave: Open Router, que puede mejorar la experiencia por velocidad o por cómo está alojado el modelo.
La idea no es solo “probar y ya”. La idea es que te vayas con una ruta clara para construir, generar pantallas y hasta correr lo que te genera el modelo, sin enredos y sin quedarte a medias.
Tabla de contenido
- 📌 ¿Por qué QWEN 3.6 Plus importa tanto?
- 🧰 Herramientas que vas a usar
- ⚙️ Instala Kilo Code en VS Code (para usar QWEN como agente)
- 🔁 Configura el modelo: QWEN 3.6 Plus en modo gratuito
- 🧩 El prompt base: de una idea a una app para personal trainers
- 🧠 Qué ocurre cuando el agente empieza a ejecutar (y por qué importa la demanda)
- ✅ Auto-approve rules: cómo dejar que el agente avance sin trabarse
- 🧱 El contexto y su límite: cuando empieza la alucinación
- 🎨 Resultado: una interfaz que se ve “redonda”
- 🔁 Alternativa para probar: Open Router como vía de acceso
- 🧪 Ejemplo con Open Router: pedir solo el diseño de login
- 📱 Responsivo de verdad: prueba en tamaños tipo móvil y tablet
- 🏁 Conclusión práctica: QWEN 3.6 Plus como reemplazo de modelos de pago
- 🧠 Checklist para que tus pruebas salgan bien (en vez de perder horas)
- 🔎 ¿Cuándo conviene usar Open Router?
- 📚 Siguiente paso: organiza tu aprendizaje con IA para apps web
- 🎥 Video para referencia
📌 ¿Por qué QWEN 3.6 Plus importa tanto?
QWEN 3.6 Plus se posiciona como un modelo con muy buen rendimiento y, lo más importante: está disponible gratuitamente en el flujo mostrado. Además, se comenta que frente a una versión anterior (QWEN 3.5) hay mejoras “significativas”.
Ahora, ¿qué significa “buen rendimiento” en la práctica?
- Menos trabajo manual para armar estructuras de proyecto.
- Mejor calidad al generar interfaces.
- Capacidad para entender objetivos (por ejemplo: “haz la página de login” sin que se vaya a otro lado).
Lo que me gusta de este punto es que no se queda en marketing. La prueba se enfoca en crear una app web con componentes reales y comportamiento esperado, en vez de solo generar texto bonito.
🧰 Herramientas que vas a usar
Para que esto sea práctico, se usan herramientas muy concretas. En el flujo que se muestra aparecen:
- QWEN 3.6 Plus
- Kilo Code como agente
- VS Code (y se menciona que está disponible para Mac y Linux)
- Google Antigravity como entorno alternativo (no obligatorio)
- Open Router como vía adicional para acceder al mismo modelo
En la descripción también aparecen recursos y links para construir apps con IA, como comunidad, hosting y playlists. Aquí van (tal cual están referenciados):
- Skool (comunidad): https://www.skool.com/vibe-coding-crea-apps-con-ia-5930
- Hosting (Hostinger): https://hostinger.com/rodrigo
- Playlist (maratones con IA): https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
- Video original: https://www.youtube.com/watch?v=Ila1NoK5h48
Con esto claro, pasemos a lo importante: la configuración y la metodología para construir la app.
⚙️ Instala Kilo Code en VS Code (para usar QWEN como agente)
Si ya trabajas con VS Code, este paso es bastante directo. La recomendación práctica es: instala VS Code (es gratuito) y luego agrega la extensión de Kilo Code.
En el flujo se hace así:
- Abres VS Code.
- Vas a Extensiones y buscas Kilo Code.
- Lo instalas.
- Te aparecen pantallas de bienvenida, pero puedes quitarlas y empezar a trabajar.
También se menciona que la herramienta puede funcionar con distintos entornos derivados de VS Code. La idea es que el agente viva en el editor que ya usas para programar.
Un detalle importante: si ya tenías sesión iniciada en otro entorno, la “máquina” puede quedar autenticada. En el caso mostrado, eso permitió usar la parte gratuita (en el contexto de QWEN gratuito).
🔁 Configura el modelo: QWEN 3.6 Plus en modo gratuito
Una vez que tienes Kilo Code listo, el siguiente paso es seleccionar el modelo.
Lo clave aquí es que se selecciona QWEN 3.6 Plus en versión gratuita. El objetivo es mantener el costo en cero y ver si realmente da la talla para construir una app completa.
Luego, se elige el modo Thinking. ¿Por qué importa esto?
- Porque no se trata solo de generar respuesta inmediata.
- El modo “thinking” tiende a habilitar mejor planificación o razonamiento interno para tareas de desarrollo.
- El objetivo es que el agente cree un plan y ejecute acciones para armar el proyecto.
En el flujo mostrado, se indica que se va a trabajar “sin planificar” adicional, pero usando thinking como parte del modelo. La idea general: probar la potencia sin poner capas extra de complejidad.
🧩 El prompt base: de una idea a una app para personal trainers
Para que el modelo demuestre valor, necesitas una tarea clara. Aquí el ejemplo parte de una app web para personal trainers.
La idea es:
- Un sitio donde un personal trainer pone su información.
- Servicios y un formulario de contacto.
- Una sección para alumnos.
El prompt se copia completo y se pega dentro del agente. Luego se ejecuta con el modelo seleccionado (QWEN 3.6 Plus) y el modo correspondiente.
Esto es muy importante como guía: cuando pruebas modelos para desarrollo web, usa prompts que describan estructura y secciones, no solo “haz una web” sin más.
🧠 Qué ocurre cuando el agente empieza a ejecutar (y por qué importa la demanda)
Cuando le das el prompt, el modelo comienza a trabajar. En el flujo se ve algo que vale la pena tomar en cuenta para tu expectativa:
- Puede aparecer un aviso relacionado con alta demanda.
- La ejecución puede demorarse un poco, pero el trabajo continúa.
Esto no es raro. En modelos gratuitos o con alta demanda, la latencia y los tiempos de respuesta pueden fluctuar.
En el caso mostrado, el agente genera un plan y empieza a crear el ambiente. Además, aparece la creación del proyecto en un stack tipo Next.js.
Un signo bueno durante la ejecución es que el sistema vaya avanzando por pasos. Si todo se queda en “texto” sin crear archivos, probablemente algo no está aterrizando. Aquí, en cambio, se está construyendo el proyecto.
✅ Auto-approve rules: cómo dejar que el agente avance sin trabarse
Durante la creación del entorno, aparece algo como auto approve rules. En el flujo se deja todo como “permitido” (permitidos, run).
En términos prácticos, esto significa:
- El agente va a necesitar permisos para ejecutar o modificar cosas.
- La interfaz te pide aprobar acciones recurrentes.
- Si las reglas se dejan permitidas, el agente avanza más fluido.
Como consejo operativo: si estás probando y quieres velocidad, revisa esas reglas, pero si confías en el flujo de construcción y el agente ya está en contexto, aprobar lo necesario evita que se quede esperando interacción.
🧱 El contexto y su límite: cuando empieza la alucinación
Este es uno de los puntos más “pro” que aparecen en el flujo, porque toca un problema real: el context window, es decir, la cantidad de texto e información que el modelo puede usar en la conversación actual.
Se menciona un indicador del contexto, con un valor tipo “2% del … ventana de contexto”. La advertencia es clara:
- Cuando el contexto se acerca a llenarse (por ejemplo al 100%), aparecen problemas.
- Uno de esos problemas es que puede empezar la alucinación o que el modelo olvide cosas.
- La señal para actuar es que el límite se está llenando.
Y entonces el consejo práctico es inmediato: crear una conversación nueva o una task nueva cuando notas que el contexto está por saturarse.
Este enfoque te ahorra horas. No esperes a que el modelo se “rompa” para reiniciar. Reinicia a tiempo.
🎨 Resultado: una interfaz que se ve “redonda”
Después de correr el comando y terminar la creación, el proyecto se ve como si alguien lo hubiera diseñado en serio. Se menciona que luce similar a outputs generados antes con otros modelos (como Gemini, Sonnet u Opus, dependiendo del caso), pero que aquí está a la altura.
Lo que se resalta:
- Las imágenes que el modelo trae.
- Detalles que no se sienten genéricos.
- Que hay un estilo consistente.
- Que incorpora elementos animados o secciones con buena presentación (por ejemplo se menciona algo para WhatsApp, como intento de levantarlo).
- Se agradece que no sea “copiar y pegar plantilla”.
Ahora, también se observa un error: una página quizá no estaba lista (se menciona algo como “error porque no tiene esa página lista”).
Esto es normal en flujos de generación. Lo valioso es que el resultado base esté lo suficientemente cerca como para que luego puedas iterar en lugar de empezar desde cero.
🔁 Alternativa para probar: Open Router como vía de acceso
Hasta aquí, todo con QWEN 3.6 Plus. Pero hay un giro importante: probar el mismo modelo desde Open Router.
En el flujo se menciona:
- Existe opción para usar proveedores mediante Open Router.
- Necesitas una API Key para configurarlo.
- Al usar Open Router, el rendimiento puede sentirse más rápido o con “mejor performance”.
Además, se menciona que hay más extensiones para conectar con Open Router y mediadores, por lo que el ecosistema no se limita a un solo camino.
Lo útil aquí no es solo “hazlo y ya”. Es entender la lógica: cuando un modelo está alojado en diferentes proveedores, el comportamiento puede variar (latencia, rendimiento, estabilidad).
🧪 Ejemplo con Open Router: pedir solo el diseño de login
Para probar con Open Router sin que el modelo se enrede con backend, se hace una petición más acotada:
- “Hagan la página de inicio de sesión, por ejemplo”.
- Se indica específicamente: “solo el diseño”.
- La razón: evitar que intente aplicar backend y se complique.
Luego se inicia una conversación nueva (por la lógica de revisión del proyecto). El agente primero revisa el proyecto actual antes de generar cambios.
Después de eso, se pide corregir un error tipo 400. En el flujo se observa que:
- Con Open Router el modelo actúa de forma distinta (por cómo está alojado).
- El problema termina solucionándose.
- Al final, la página de login queda lista.
📱 Responsivo de verdad: prueba en tamaños tipo móvil y tablet
Un buen indicador de calidad en una app generada es que sea responsiva. En el flujo se comprueba que la página se adapta bien a dimensiones de móvil y tablet.
Se remarca que, al cambiar el tamaño de pantalla, se ajusta correctamente. No es solo que “se vea bonito en escritorio”. Funciona en formatos reales.
Este es el punto en el que muchos prompts fallan. Muchos modelos solo diseñan para “un tamaño”. Si el output ya respeta responsive, vas ganando tiempo de implementación.
🏁 Conclusión práctica: QWEN 3.6 Plus como reemplazo de modelos de pago
Lo que deja esta prueba es una sensación bastante clara: QWEN 3.6 Plus tiene capacidad real para ayudarte a crear apps web sin depender de modelos de pago en cada iteración.
Y además, aparece el “plan B”:
- Si el flujo gratuito está limitado por demanda o latencia, puedes probar vía Open Router.
- Eso puede simplificar la ejecución y mejorar velocidad en ciertos casos.
La conclusión no es “dejes de pagar nunca”. La conclusión es “evalúa costo contra resultados”. En muchos proyectos, el 80% del valor está en construir y refinar rápidamente interfaces, rutas, componentes y estructura. Si un modelo gratuito cumple, te conviene.
🧠 Checklist para que tus pruebas salgan bien (en vez de perder horas)
Si quieres replicar este tipo de resultados, usa este checklist mental:
- Prompt con estructura: describe secciones, formularios y objetivo (no solo “haz una web”).
- Limita el alcance cuando itera: “solo diseño”, “solo layout”, “solo página X”.
- Revisa auto-approve rules: para no quedarte trabado esperando permisos.
- Vigila el contexto: cuando se acerque al límite, empieza una tarea o conversación nueva.
- Si algo falla, corrige rápido: errores tipo 400 suelen ser arreglables con una instrucción clara.
🔎 ¿Cuándo conviene usar Open Router?
Con lo que se observa, Open Router es especialmente útil si:
- Quieres una experiencia más fluida o rápida.
- Te aparece “alta demanda” y necesitas bajar la latencia percibida.
- Prefieres manejar proveedores desde una integración central.
Y un detalle que se menciona: hay extensiones adicionales para conectar Open Router y mediadores. O sea, el ecosistema ofrece opciones.
📚 Siguiente paso: organiza tu aprendizaje con IA para apps web
Si tu meta es ir más allá de “generar pantallas” y empezar a construir apps reales con lógica, hosting y despliegue, lo más inteligente es seguir un sistema: prompts probados, recursos reutilizables y comunidad donde te compartan plantillas y flujos.
Por eso se enlaza en la descripción:
- Skool: https://www.skool.com/vibe-coding-crea-apps-con-ia-5930
- Hosting para publicar: https://hostinger.com/rodrigo
- Playlist de maratones: https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
La parte más potente no es solo el modelo. Es la combinación: modelo + agente + editor + flujo iterativo. Ahí es donde se logra la magia de “vibe coding” sin perder control.
🎥 Video para referencia
Notas finales
Si lo que buscas es reducir costos, ganar velocidad y construir con IA de forma consistente, QWEN 3.6 Plus (y el camino de Open Router cuando aplica) es una opción muy seria.
El objetivo no es impresionar. El objetivo es que tu app salga, que sea usable, que sea responsiva y que tú puedas iterar sin volver a empezar cada vez desde cero.
