en este post vamos a metemos de lleno en una de esas cosas que suenan a ciencia ficción, pero que están ya funcionando el Deep Research.
¿Qué es el Deep Research?
Imagina que le pides a un modelo de lenguaje que investigue a fondo sobre un tema. No te responde de inmediato, sino que se toma su tiempo: consulta fuentes, rastrea Internet, recopila datos y, solo entonces, te devuelve una respuesta elaborada. Eso es Deep Research.
Este post es un resumen de mi vídeo, si quieres mayor profundidad puedes verlo:
Las herramientas usadas
Para esta entrada he seguido dos implementaciones públicas:
Dearflow: Un proyecto mucho más profesional y complejo, pensado para ser realmente útil en producción.
Gemini-fullstack-langgraph-quickstart: sencilla y educativa
Esta demo se basa en LangGraph, un framework para trabajar con agentes. Pero tranquilo, que no vamos a entrar en el código. Solo vamos a entender cómo funciona:
El flujo de agentes
Generate Query Genera las queries de búsqueda a partir del prompt del usuario. Intenta cubrir distintos ángulos del tema y evita repetir.
Web Search Ejecuta esas búsquedas en internet, elige fuentes fiables y resume resultados.
Reflection Evalúa si ya hay suficiente información. Si no, genera nuevas queries y repite el proceso.
Answer Generator Crea la respuesta final
¿Qué modelos se usan?
Para cada agente, se usa un modelo distinto, del más rápido al más potente:
Gemini 2.0 Flash → búsqueda y resúmenes
Gemini 2.5 Flash → evaluación
Gemini 2.5 Pro → generación final
Deerflow: la versión pro
Aquí las cosas se complican un poco más. Dearflow no es solo educativo: quiere ser una herramienta útil y versátil.
El corazón del sistema
Coordinator Decide si una consulta merece un Deep Research o se puede responder de forma simple.
Planner Orquesta toda la lógica: qué agentes se llaman, qué información falta, si hay que seguir buscando, etc.
Research Team Conjunto de agentes especializados (algunos incluso capaces de ejecutar código).
Reporter Redacta el informe final (puede convertirse en un podcast o una presentación PowerPoint)
Estilos y formato dinámico
Una cosa chula de Dearflow: puedes elegir el estilo del texto generado. Los prompts incluyen bloques dinámicos que se adaptan según el estilo que configures.
Conclusión
Si estás empezando, te recomiendo que juegues primero con la demo de Google. Te permite entender muy bien cómo funciona el proceso. Y cuando tengas soltura, lánzate con DeerFlow. Es una herramienta más robusta, pero también más compleja.
¿Te animas a crear tu propia herramienta de Deep Research?
Hoy vamos a tratar una pregunta que, aunque parezca más filosófica que técnica, tiene una base muy concreta: ¿los modelos de lenguaje pueden razonar?
¿Loros estocásticos?
Una de las principales críticas a los modelos de lenguaje es, que no hacen más que predecir la siguiente palabra en un texto, como una especie de loro estocástico. Es decir, dado un texto, el modelo calcula cuál es el siguiente token (unidad básica del lenguaje, parecida a una palabra o fragmento de palabra) más probable. Ese nuevo texto se vuelve a procesar, se calcula el siguiente token, y así sucesivamente.
Lo interesante es que entre token y token, el modelo no recuerda nada. Cada petición es independiente, lo cual parece alejarse bastante de cualquier forma de razonamiento.
Si no razonan ¿Cómo explicamos esto?
Para ilustrarlo, hice una pequeña prueba: le pedí a un modelo que generara una adivinanza completa, incluyendo la solución al final. Aunque las adivinanzas que genera no son obras maestras, suelen tener sentido y, sorprendentemente, la respuesta es coherente.
Vuelo sin alas, lloro sin ojos, paso sin pies y no me ves. ¿Qué soy? Respuesta: El viento.
Esto plantea una pregunta clave: si el modelo solo predice el siguiente token, sin saber la respuesta de antemano, ¿Cómo consigue generar una adivinanza con sentido y con una solución correcta si esta no se escribe hasta el final?
El razonamiento está en el procesamiento del texto
La clave está en lo que ocurre antes de que el modelo empiece a predecir tokens. Cuando recibe un texto, no lo procesa tal cual: lo transforma en una representación matemática sobre la que operan sus redes neuronales. Capa a capa, esta representación se modifica, se afina, y finalmente permite calcular los tokens más probables para continuar.
Este proceso —aunque distinto del razonamiento humano— puede considerarse una forma de razonamiento, en tanto que transforma información, la analiza y genera una conclusión coherente.
Además, el texto que genera el modelo tiene una doble función: 1. Responder al usuario. 2. Servir como soporte para su propio proceso de razonamiento.
De hecho, si ampliamos el texto con reflexiones, pasos intermedios y análisis, los resultados suelen ser mucho mejores. Por eso los llamados modelos razonadores generan respuestas más largas: ese “rollo” intermedio es parte del razonamiento.
¿Y cómo ha aprendido a hacer esto?
Aquí no hay magia: como cualquier red neuronal, un modelo de lenguaje aprende por imitación. Si se entrena con ejemplos de entradas y salidas, acabará imitando ese comportamiento. En este caso, al entrenarse con textos que contienen razonamientos, el modelo aprende a imitar cómo escribimos cuando razonamos.
De hecho, cada vez más, los modelos se entrenan con datos específicamente diseñados para reforzar su capacidad de razonar.
¿Token a token?
Una crítica habitual es que, si un modelo solo puede generar una palabra (token) a la vez, no puede estar razonando como lo hacemos nosotros. Pero eso no es del todo cierto.
Existen otros tipos de modelos, como los modelos de lenguaje de difusión, que generan todo el texto al mismo tiempo. Inicialmente en forma de “borrador”. Luego, en cada iteración, van refinando todos los tokens hasta que el texto tiene sentido. Este enfoque se parece mucho más al proceso humano de pensar y escribir.
¿Imitar es razonar?
Otra cuestión habitual es que los modelos no razonan porque solo imitan nuestro comportamiento. Aquí podríamos entrar en un debate filosófico largo, pero os lanzo esta reflexión:
¿Razonar es un proceso concreto y solo es válido si se hace exactamente como lo hacen los humanos? ¿O es un resultado y cualquier proceso que llegue a una conclusión que consideramos razonada puede llamarse razonamiento?
¿Y si en vez de imitar… aprenden por sí mismos?
Existe otra técnica de entrenamiento llamada aprendizaje por refuerzo, que permite a los modelos mejorar a base de ensayo y error, sin limitarse solo a imitar. Aunque es solo una parte del entrenamiento, se utiliza especialmente en tareas complejas como matemáticas o programación, y aumenta la capacidad de razonamiento del modelo.
Entonces… ¿razonan o no razonan?
Eso os lo dejo a vosotros. Lo que está claro es que la frontera entre imitación y razonamiento es más difusa de lo que parece.
Os traigo una técnica que promete cambiar la forma en la que funcionan los modelos de lenguaje (¿Cuantas van ya este año?). Esta nueva propuesta, presentada por el equipo de modelos Qwen, se llama Parallel Scaling. Vamos a desgranarlo poco a poco.
Tipos de modelos
Modelos densos
Son los clásicos. Cada vez que generan un token, usan todos sus parámetros. ¿Quieres que sea más listo? Añades más parámetros. Fácil, pero caro en términos de tiempo y memoria.
Modelos MOE (Mixture of Experts)
Estos modelos no usan todos sus parámetros en cada paso. Solo activan una pequeña parte, lo que los hace mucho más rápidos. Para igualar la inteligencia de un modelo denso, eso sí, necesitan tener un número total de parámetros mucho mayor. MOE permite ganar velocidad a cambio de usar más memoria.
Modelos razonadores
Aquí entra un enfoque llamado Inference Scaling, también conocido como modelos razonadores. ¿La idea? Darle más tiempo al modelo para pensar antes de responder. Esto se traduce en mayor inteligencia sin aumentar el número de parámetros, pero con un coste: las respuestas tardan más y requieren más cálculo.
Inference Scaling puede aplicarse tanto a modelos densos como MOE. Incluso, un mismo modelo puede funcionar de forma razonadora o no, según la necesidad.
Parallel Scaling: la gran novedad
Y aquí llega la joya de la corona: Parallel Scaling. Consiste en ejecutar múltiples veces la misma entrada en el modelo de lenguaje, pero con prefijos distintos.
Cada uno de estos prefijos guía al modelo a «pensar» de una manera diferente.
El modelo ha sido entrenado para interpretar cada prefijo como una pista que activa un estilo de razonamiento distinto.
¿Resultado? Respuestas distintas que una red neuronal final se encarga de combinar.
Y ahora viene lo potente: todo esto se puede ejecutar en paralelo. Es decir, aumentamos la inteligencia sin aumentar el tiempo de respuesta. Más cálculo sí, pero distribuido y ejecutado de forma simultanea.
¿Cómo se entrena parallel scaling?
Aunque se puede entrenar desde cero, lo ideal es tomar un modelo ya entrenado y aplicarle un post-training para enseñarle a trabajar en paralelo.
En Hugging Face ya hay modelos entrenados con esta técnica, disponibles con distintos tamaños y conjuntos de datos.
¿Y ahora qué?
El futuro de esta técnica dependerá de si demuestra superioridad frente a otros métodos en múltiples escenarios.
Desde luego, la idea de mantener la memoria RAM bajo control y aun así aumentar la capacidad de razonamiento es muy prometedora. Además, en informática llevamos décadas acostumbrados a paralelizar tareas, así que… ¿por qué no aplicarlo también a la IA?
Qwen ha presentado una nueva versión de su familia de modelos. Con modelos para todos los gustos.
Voy a dividirlos en dos bloques, modelos MOE y modelos densos. Explicando rápidamente la diferencia entre ambos, mientras que los modelos densos usan todos sus pesos para calcular el siguiente token, los modelos MOE solo emplean una parte.
Modelos densos:
Empiezo por los modelos densos que son a los que más acostumbrados brazos estamos.
Aquí el rey es un modelo de 32 mil millones de parámetros. De ese modelo han destilado otros de 14, 8, 4, 1.7 y 0.6 mil millones de parámetros. Hay versión base (completar textos) y versión entrenada para seguir instrucciones (la de chatear, vamos)
Todos tienen un contexto de 32.000 tokens. Aunque los modelos de 32, 14 y 8 mil millones de parámetros pueden extenderse hasta 128.000 tokens.
Modelos MOE:
Los MOE son solo 2 modelos: Qwen 3 235B A22B y su versión destilada Qwen 3 30B A3B
Si estos nombres a medio camino entre modelo de lenguaje y código de almacén de ferretería te confunden te los explico rápidamente:
Nombre del modelo Versión Número de parámetros “A”Número de parámetros activos en cada consulta.
Los MOE son interesantes a nivel profesional ya que permiten reducir el tiempo de cómputo y por tanto el consumo de GPU. Por otro lado sus resultados no son tan buenos como un modelo denso del mismo tamaño.
Comparar modelos MOE y densos:
Os lo explicó con un ejemplo: Si tengo que elegir entre Qwen 3 32B y Qwen 3 30B A3B ¿Con cuál me quedo?
Ambos ocupan más o menos lo mismo. Esto nos lo indica el número de parámetros. 32B y 30B, para tener una aproximación podemos multiplicar éstos por los bytes que consume cada peso. Generalmente 2 (aunque hay modelos que pueden llegar hasta cuatro). Si el modelo está cuantizado pueden ser un bytes o menos. Este valor es un valor mínimo puesto que luego el modelo necesita más memoria para almacenar el contexto y los cálculos intermedios.
El tiempo de respuesta del modelo nos lo da el número de parámetros activos. En el caso de los modelos densos todos sus parámetros están activos.
¿Y en inteligencia? ¿Cómo se comparan? Hay una fórmula no oficial y aproximada de que un modelo MOE es comparable a un modelo denso cuyo número de parámetros sea la raíz cuadrada de multiplicar el total de parámetros por el número de parámetros activos. En este caso SQRT(30*3) es equivalente a un modelo de 16.4B. Cómo ya he dicho es una fórmula aproximada y creo que un poco injusta. Los MOE han ido mejorando.
En mis pruebas de programación, pruebas muy básicas nada complejo, aunque ambos han resuelto correctamente los que les he pedido creo que la versión 32B ha escrito código de mejor calidad que 30B A3B. Ahora, está última generaba tokens a tal velocidad que era imposible seguirla.
Pero aquí estamos para darles vueltas a las cosas y voy a daros una tercera solución que combina la inteligencia del modelo 32B y acelera su velocidad. Aunque requiere usar un poco más de memoria. Usar Qwen 3 32B junto con Qwen 3 0.6B usando speculative decoding para acelerar los cálculos.
Multilenguaje
Volviendo al resto de las características de los modelos, cabe destacar el soporte multilenguaje con más de 119 lenguas soportadas. Debo decir que al menos en lo que al español se refiere ha mejorado mucho. Mi experiencia con versiones anteriores es que usar el inglés (y supongo que el chino) era mucho mejor que el español. Sin embargo está versión ha mejorado.
Modo híbrido razonador/no-razonador
Para mí la gran novedad de este sistema es la capacidad de poder usar el mismo modelo como modelo razonador y no razonador al mismo tiempo. Basta con incluir la etiqueta /think o /nothink al final del prompt de sistema o de usuario para activarlo.
En el modo razonador se generara el texto con el razonamiento encerrado entre dos etiquetas <think> </think>. Después de ellas escribirá la respuesta final. En caso de que la conversación continué hay que quitar estas etiquetas y el texto contenido entre ellas. Basta con dejar la conclusión final. Esto ayuda a no agotar el contexto disponible. Cosa habitual en los modelos razonadores que tienden a generar muchos tokens durante su razonamiento.
Puede parecer tentador combinarlos en una misma conversación pero no están sencillo, ya que los parámetros del sampling recomendados para cada caso son diferentes.
No thinking (No razonador):
Temperature=0.7,TopP=0.8,TopK=20,MinP=0
Thinking (Razonador):
Temperature=0.6,TopP=0.95,TopK=20,MinP=0
Para conseguir un modelo con estas capacidades han partido del modelo base y han realizado un post-entrenamiento de cuatro etapas:
En la primera le han entrenado usando ejemplos de cadenas de pensamiento.
En la segunda han usado aprendizaje por refuerzo centrado en matemáticas y programación recompensando aquellas estrategias que incentivan el razonamiento
En la tercera integran ambas formas de respuesta (razonador y no razonador) entrenado con datos de ambos tipos
En la cuarta realizan aprendizaje por refuerzo pero con mayor variedad de tareas que en la segunda etapa.
Uso de herramientas (ahora llamado “capacidades agénticas”)
Todos los modelos han sido entrenados en el uso de herramientas, en este caso se ha hecho especial hincapié en que soporte en el protocolo MCP
Qué viene ahora
En el caso de otros modelos esto sería un punto y final pero no es la forma de trabajar de los modelos Qwen. Ahora a lo largo del año irán apareciendo nuevos modelos basados en Qwen 3. Math, Coder, con capacidades visuales, auditivas, quizás una nueva versión de Qwen Omni.
¡Bienvenidos a Construyendo a Chispas! Hoy exploramos una de las tendencias más emocionantes en el mundo de la inteligencia artificial: el futuro de los agentes. Cada vez más, la IA se está orientando hacia el uso de agentes capaces de realizar diversas tareas de manera autónoma, con el objetivo de facilitarnos la vida.
Pero para que esta revolución funcione, necesitamos algo fundamental: estándares y protocolos que definan cómo deben comunicarse estos agentes entre sí y con nuestras herramientas. Hoy vamos a hablar de dos de esos protocolos, que no solo son innovadores, sino que además se complementan perfectamente: A2A de Google y MCP de Anthropic.
Para información en mayor detalle puedes ver el siguiente vídeo:
¿Qué es A2A?
A2A (Agent-to-Agent) es el protocolo de Google diseñado para facilitar la comunicación entre agentes y también entre usuarios y agentes. Está pensado para entornos profesionales y construido sobre estándares de seguridad y autenticación ya existentes.
Entre sus características más destacadas:
Multimodalidad: soporta entradas de audio, texto, vídeo, o cualquier otro formato. Es totalmente agnóstico respecto al tipo de contenido.
Comunicación asíncrona: ideal para tareas que pueden tardar desde minutos hasta horas en completarse.
Tres actores principales:
Usuario: quien solicita la tarea.
Cliente: el software que realiza la comunicación.
Agente remoto: quien ejecuta la tarea.
La comunicación en A2A se estructura alrededor de tareas (tasks), que incluyen:
Mensajes: el intercambio tipo chat entre usuario y agente.
Artefactos: los resultados generados (como ficheros HTML, imágenes, etc.).
Estado de la tarea: que permite conocer en todo momento si la tarea está en proceso, completada o ha fallado.
Además, A2A introduce un mecanismo de descubrimiento de agentes usando archivos Model Card, que describen capacidades, versiones y direcciones de los agentes, y permiten localizarlos en tiendas públicas o privadas, ¡igual que una app store, pero para agentes de IA!
¿Qué es MCP?
Por otro lado, tenemos MCP (Model Contest Protocol) de Anthropic, que se centra en permitir que los agentes usen recursos y herramientas que tenemos disponibles, tanto locales como remotos.
En MCP participan:
Host: el modelo de lenguaje o IA que quiere acceder a los recursos.
Cliente: la aplicación que conecta el host y el servidor.
Servidor: el sistema instalado en tu máquina que gestiona qué recursos están disponibles.
MCP maneja diferentes tipos de mensajes (peticiones, resultados, errores y notificaciones) y ofrece cinco tipos de recursos:
Recursos: ficheros, documentos, imágenes.
Prompts: plantillas de prompts específicas para ciertas tareas.
Tools: APIs o herramientas con las que interactuar.
Sampling: peticiones de continuación de texto al agente.
Roots: recursos que el agente considera relevantes .
¿Cómo trabajan juntos A2A y MCP?
Imagina que quieres crear una página web. Gracias a A2A, puedes buscar un agente especializado en diseño web mediante su Model Card. Este agente, a su vez, puede colaborar con otros agentes para generar imágenes, escribir contenido o diseñar la estructura.
Con MCP, puedes darle a los agentes acceso a los documentos que contienen el contenido de la web o permitirles publicar el resultado directamente en tu servidor.
El trabajo entre ambos protocolos te permite no solo buscar agentes adecuados, sino también equiparlos con los recursos que necesitan para trabajar de forma eficiente y autónoma.
El futuro ya está aquí
Estos protocolos, aún en sus primeras versiones, marcan el inicio de un futuro donde podríamos tener nuestro propio «Jarvis» en casa: un asistente capaz de coordinar múltiples agentes para resolver nuestras necesidades cotidianas.
Sea cual sea el camino que tome esta tecnología, desde Construyendo a Chispas seguiremos contándote las novedades.
En el mundo de la inteligencia artificial, escuchar que algo puede revolucionarlo todo es casi rutina. Sin embargo, esta innovación realmente podría marcar un antes y un después en cómo funcionan los modelos de lenguaje: los Modelos de Lenguaje con Difusión (Diffusion LLMs).
Puedes ver el vídeo para más información
¿Qué es un modelo de difusión?
Para entender esta nueva idea, hay que mirar atrás. Los modelos de difusión clásicos, como Stable Diffusion, se entrenan para limpiar ruido de imágenes de forma progresiva, guiados por un texto (prompt). Este proceso ocurre en el espacio latente y es dirigido por una red llamada UNet.
Todo cambió cuando se sustituyó esa UNet por un transformer, el mismo tipo de arquitectura que usan los modelos de lenguaje actuales. Así nació un nuevo enfoque: enseñar a transformers a eliminar ruido. ¿La clave? Estos modelos pueden generar contenido de manera no secuencial.
¿Y si aplicamos esta idea al texto?
Aquí está lo revolucionario. En vez de generar texto palabra por palabra (como hacen los LLMs tradicionales), los modelos de lenguaje con difusión generan todo el texto a la vez. Todas las palabras influyen en las demás desde el inicio, una forma más parecida a cómo pensamos los humanos.
Al no poder crear tokens de texto con ruido se crea una máscara con una entrada para token, que indica si el token es válido (desenmascarado) o ruidoso (en mascarado). Técnicamente, el proceso comienza con todos los tokens del texto enmascarados. Luego, en varias iteraciones, el modelo va desenmascarando aquellos tokens que considera más probables. Incluso puede volver a enmascarar tokens ya revelados para mejorar la coherencia general.
¿Qué modelos existen hoy?
Actualmente hay tres modelos destacados que usan esta técnica:
Mercury (Inception Labs) Especializado en generación de código. Es privado. Presume de su velocidad generando código frente a los LLM clásicos.
LLaDA 8B Un modelo open source con 8.000 millones de parámetros. Tiene versión base e instruct (esta última preparada para seguir instrucciones, como en un chat). LLaDA utiliza un transformer bidireccional y un proceso iterativo de enmascarado y desenmascarado. Curiosamente, el número de iteraciones es fijo, sin importar la longitud del texto, lo que puede suponer ventajas en velocidad, aunque también plantea retos con textos largos.
Block Diffusion Una propuesta híbrida: aplicar el proceso de difusión por bloques de tokens. Dentro de cada bloque se aplica la lógica de difusión; entre bloques, se mantiene una estructura más parecida a los LLM clásicos. Aunque esta implementación es conservadora (usa bloques pequeños y sin que se puedan volver a enmascarar tokens), tiene un gran potencial, especialmente si se amplía a párrafos u otras unidades mayores.
Pros y contras:
Los modelos de lenguaje con difusión (DLLM) presentan algunas ventajas claras frente a los LLM tradicionales. Al generar todo el texto a la vez en lugar de palabra por palabra, los DLLM pueden lograr una mayor coherencia global, ya que todas las palabras se ajustan mutuamente durante el proceso. Esto se acerca más a cómo razonamos y escribimos los humanos. Además, al tener un número fijo de iteraciones, pueden ser más rápidos en tareas cortas y permiten un razonamiento más flexible en el espacio latente. Sin embargo, también tienen limitaciones: su entrenamiento y optimización todavía están en fases tempranas, carecen de las mejoras acumuladas que ya existen para los LLM, y su rendimiento puede degradarse con textos largos. Además, es más difícil reutilizar cálculos entre iteraciones, lo que puede afectar a su eficiencia en comparación con los modelos tradicionales altamente optimizados.
¿Qué futuro tienen?
Estos modelos podrían integrarse mejor en sistemas multimodales (que combinan texto, imagen, sonido…) y ofrecen nuevas posibilidades para tareas complejas como el razonamiento. Eso sí, todavía estamos dando los primeros pasos. Los LLMs tradicionales están muy optimizados, y cambiar de paradigma implica reaprender muchos procesos.
Un dato curioso: los creadores de LLaDA observaron que el modelo a veces puede generar la respuesta correcta antes de completar todo el razonamiento. Los tokens aún enmascarados ya contienen información útil, lo que sugiere que el razonamiento está ocurriendo en un plano latente.
Hoy quiero confesaros algo. Cuando empecé a planear este contenido, pensaba criticar el vibe coding. Sin embargo, tras reflexionar un poco, me he dado cuenta de que el problema no es la técnica en sí, sino cómo se aplica. De hecho, el vibe coding puede ser una herramienta muy útil si se usa correctamente. Así que, en vez de criticarlo, hoy os voy a contar cómo sacarle partido, tanto si tenéis mucha experiencia programando como si estáis empezando.
¿Qué es el Vibe Coding?
El término vibe coding viene a significar «programar por vibras». Imaginad al protagonista de El Gran Lebowski programando: te sientas con una IA, le pides algo, ajustas lo que genera, vuelves a pedir cambios… todo de forma informal. ¿Funciona? Bueno, depende del tipo de proyecto que quieras desarrollar.
Hay quienes dicen que ya no necesitamos programadores, solo ideas y una IA. Pero como alguien que lleva más de 20 años en esto, os aseguro que esa frase la he escuchado muchas veces antes: con la programación visual, los generadores automáticos, el low code, y ahora con la inteligencia artificial. Y aquí sigo, picando líneas y líneas de código para poner un botón.
Origen del término y su auge
El término fue popularizado por Andrej Karpathy, un experto en IA que ha trabajado para Tesla y OpenAI. En uno de sus tweets hablaba maravillas del vibe coding… pero matizaba: lo ve útil para webs o proyectos de fin de semana, no para montar un SaaS (Software as a Service).
Además, el auge del vibe coding viene de la mejora brutal en los modelos de lenguaje. Ahora son capaces de programar un Tetris, un Comecocos o un Snake y estos ejemplos resultan impresionantes para la mayoría de la gente, pero hay que tener en cuenta que literalmente son ejercicios que se realizan en clase mientras estudias informática. Un proyecto real puede tener cientos de miles de líneas de código y muchos más retos.
Programar es mucho más que escribir código
Pensad en esto: aunque la IA os haga un SaaS que parece funcional, ¿habéis pensado en temas como la protección de datos? ¿La gestión de compras y devoluciones? ¿Compatibilidad en distintos dispositivos? ¿Pruebas? ¿Seguridad? Programar es mucho más que escribir código.
Por eso, si quieres montar algo serio, rodéate de expertos. Y no te fíes de campañas virales que prometen miles de dólares al mes con juegos feos hechos por IA. Incluso quienes presumen de usar vibe coding al 100%, terminan permitiendo modificaciones humanas.
Cómo usar el Vibe Coding correctamente
Si quieres aplicar esta técnica de forma eficaz, aquí tienes los pasos clave:
Elige bien tus tecnologías. Cuanto mejor las conozcas, más fácil será guiar a la IA.
Evalúa si realmente necesitas una app. A veces una hoja de cálculo basta.
Control de versiones. Usa Git o, si no sabes, guarda cada versión generada con fecha.
Haz una lista de funcionalidades. Divide tu app en versiones y fases claras.
Crea una arquitectura limpia. Separar controladores, servicios y datos te permitirá delegar mejor a la IA.
Desarrolla por tareas. Describe cada una en un prompt, revisa el resultado, testea y guarda.
Pon límites a la IA. Si una tarea no se resuelve tras varios intentos, decide si continuar o revertir.
Automatiza donde puedas. Pero también aprende cuándo intervenir a mano.
El flujo de trabajo en Vibe Coding: paso a paso
Una de las claves para que el vibe coding funcione realmente bien es organizarse con un flujo claro. No se trata solo de pedirle cosas a la IA y esperar milagros, sino de establecer un proceso iterativo y controlado. Este sería un flujo básico que puedes seguir:
1. Crear una lista de tareas
Antes de escribir ni una línea de código, define qué funcionalidades debe tener tu aplicación. Divide esas funcionalidades en tareas pequeñas y manejables. Por ejemplo:
Mostrar lista de usuarios
Añadir nuevo usuario
Validar email al registrarse
Esta lista puede estar escrita por ti o generada inicialmente con ayuda de una IA.
2. Redactar prompts para cada tarea
Para cada una de esas tareas, redacta un prompt claro que describa lo que quieres. Sé específico.
Puedes añadir condiciones, estructuras de datos, objetos o interfaces previamente definidas.
3. Evaluar si el código generado funciona
Una vez la IA te devuelve el código:
Si es un lenguaje compilado: comprueba si compila y arranca.
Si es interpretado: simplemente ejecútalo y observa si arranca correctamente.
4. Corregir errores si no funciona
Si da error, copia ese error y pásaselo a la IA junto con el código.
La IA intentará corregirlo. Puedes repetir este paso varias veces, pero pon un límite de intentos para no quedarte atrapado en un bucle infinito.
5. Testear el código
Cuando el código ya «funciona», toca comprobar si hace lo correcto.
Ideal: tener tests automáticos definidos.
Alternativa: probar a mano, pero siempre siguiendo un guión claro de qué debería pasar.
6. Guardar versiones que funcionen
Cada vez que una funcionalidad funciona y pasa los tests, guárdala.
Si usas Git, haz un commit.
Si no sabes usar Git, guarda el archivo en una carpeta con fecha/nombre descriptivo.
Esto es importante porque la IA, a veces, rompe cosas que antes funcionaban y luego no sabe repararlas. Tener una versión estable te permite comparar y recuperar fácilmente.
7. Si no se puede resolver una tarea…
A veces la IA no logra resolver una tarea, por más intentos que hagas.
En ese caso, tienes dos opciones:
Guardar el progreso parcial si la app sigue funcionando. Aunque sea de forma incorrecta
Revertir a una versión anterior y dejar esa tarea para después.
La idea es no frenar todo el proyecto por una sola parte atascada.
Un ejemplo real
En mi día a día, uso un sistema híbrido: tengo un motor de plantillas que genera parte del código con IA y parte de forma clásica. Desde SQL hasta controladores web, todo está dividido por capas, lo que me permite testear fácilmente y generar componentes reutilizables.
Eso sí, hay límites: en el frontend, por ejemplo, todavía no logro que la IA respete del todo los estilos y convenciones, así que prefiero crear esqueletos básicos que luego el programador humano completa.
Conclusión
El vibe coding no es magia, pero tampoco es humo. Si se hace bien, puede acelerar el desarrollo, sobre todo para tareas repetitivas o proyectos pequeños. Pero para crear productos reales, sólidos y mantenibles, hace falta mucho más que IA: hace falta conocimiento, planificación y buen criterio.
Hace poco Meta anunció un proyecto donde había conseguido leer directamente de la mente de 35 voluntarios que teclas iban a pulsar en el teclado.
Los resultados son sorprendentes, una tasa de acierto del 80%
Si deseas ampliar el contenido de este post puedes ver este vídeo.
¿Pero como de real es eso de leer teclas de mente de una persona?
Y es que lo de «leer la mente» suena mejor que decir que leyeron la corteza neuromotora para saber que movimientos se ordenaban a los dedos. Para leer estas señales del cerebro probaron con dos técnicas no invasivas:
EEG: Electroencefalografía, leer las señales eléctricas del cerebro.
MEG: Magnetoencefalografía, leer los campos magnéticos que causan las señales eléctricas en el cerebro.
El problema de leer señales biológicas de forma no invasiva es la pésima relación señal ruido. Básicamente la señal está envuelta en un montón de ruido que índuce errores e incertidumbre en su lectura.
En este caso los resultados fueron mucho mejores con MEG que con EEG, lo cuál es una lastima porque EEG es un sistema más asequible y “simple” que MEG.
El proceso de captura de datos :
La tarea de cada voluntario consistía en tres pasos: Leer, esperar, escribir.
Cada usuario leía una frase de un monitor
Después se mostraba en la pantalla una cruz negra al desaparecer de pantalla empezaba la tercera fase
En pantalla se mostraba un cuadrado girando mientras los usuarios escribían la frase en un teclado
Todo este proceso se hace para asegurarse de que la información procede de las “ordenes de teclear” y no por ejemplo de lo que están viendo los ojos.
Hay ciertas peculiaridades en el texto, para evitar que una letra fuera más de una pulsación (lo que complicaría el procesado de datos). Todo eran letras mayúsculas, sin tildes, diéresis y por algún motivo sin Ñ (¿Saben los americanos que tenemos una letra Ñ en el teclado?)
Cada sentencia era grabada y almacenada para luego poder ser procesada por la IA.
Arquitectura de la IA
La IA se compone de tres módulos que trabajan con un sentencia completa.
Modulo Convolucional
Se compone de cuatro partes, con las siguientes tareas:
Codificar la posición espacial de cada sensor
Adapta los datos a cada usuario
Modulo convolucional (combina los datos de varios sensores próximos)
Agrupación temporal
Transformer
Toma los datos del modelo anterior y calcula cual es la probabilidad (realmente no es la probabilidad son los logits, para los que sepáis de que hablo) de que sea cada carácter. Su función es integrar el contexto de la frase dentro de las predicciones.
Modelo de lenguaje:
Nada que ver con los LLMs, simplemente modela la relación estadística existente entre los caracteres (usando 9grams). Esto sumado a las datos del paso anterior nos da como resultado la sentencia escrita (si todo sale bien).
El resultado es tan bueno que puede llegar a corregir errores reales de tecleo del voluntario.
Teclear con la mente.
Aunque la idea de usar la mente para escribir un texto puede resultar muy atractiva, está lejos de ser la realidad de este sistema. Hay muchos “peros”.
A nivel de datos:
Solo 35 personas. Poca variedad. Sin ningún tipo de lesión.
Mecanógrafos expertos. Señal limpia, sin dudar a la hora de pulsar una tecla y pocos errores.
Entorno clínico, controlado. Sin distracciones. Ni ruido ambiente.
Cómo a nivel práctico :
Una máquina de resonancia magnética necesita un entorno clínico o de laboratorio con muchas restricciones.
Se trabaja sobre datos grabados, sentencias completas. No carácter a carácter.
Letras limitadas
¿Es un paso prometedor? Lo es. Significa que podremos teclear con la mente. Por ahora no, pero si algún día podemos será gracias a estudios como este.
Kokoro-82M es un nuevo modelo de texto a voz que permite fácilmente y con pocos recursos convertir de texto a voz en varios idiomas:
🇪🇸 ‘e’ => Spanish es 🇫🇷 ‘f’ => French fr-fr 🇮🇳 ‘h’ => Hindi hi 🇮🇹 ‘i’ => Italian it 🇧🇷 ‘p’ => Brazilian Portuguese pt-br 🇺🇸 ‘a’ => American English 🇬🇧 ‘b’ => British English 🇯🇵 ‘j’ => Japanese 🇨🇳 ‘z’ => Mandarin Chinese
Entre ellos el español, lo cual no es tan habitual como cabria esperarse por su número de hablantes.
Su uso es realmente sencill, para instalarlo basta con seguir los siguientes pasos.
Lo primero es instalar kokoro y soundfile:
pip install kokoro soundfile
También necesitaremos instalar espeak-ng, la forma de instarlo variará según el sistema operativo que tengamos:
Para Windows podemos descargar la última versión aquí
Realmente no tenemos existe una definición formal de que es la AGI así que no tenemos un objetivo claro para llegar a ella. La forma en que actualmente tratamos de aproximarnos a ella es a través de los benchmarks (que como ya vimos que tiene sus propios problemas). Cada vez que se supera un benchmark aparece otro que sube el listón.
De hecho ya han sido varias las pruebas superadas que se suponía nos llevaban a la AGI:
Ganar al ajedrez
Ganar al go
Superar el test de Turing
Demostraciones matemáticas
…
Y aquí seguimos sin nada que podamos considerar AGI.
Principalmente hay tres caminos que se mezclan:
Agentes: combinar varios modelos de lenguajes expertos en diferentes tareas.
LLM + entrenamiento: entrenar a un modelo de lenguaje para mejorar sus capacidades de razonamiento.
LLM + algoritmos clásicos: el modelo de lenguaje genera múltiples caminos de razonamiento y se usan algoritmos clásicos para elegir cual se desarrolla.
No son tres caminos independientes si no que se pueden combinar para mejorar el sistema.
Además estos modelos pueden usar las siguientes
Ingeniería de prompts.
RAG
Uso de herramientas (function calling)
Generación y ejecución de código
No basta con conseguir la AGI, no todo es inteligencia:
Comprensibles. No basta con que la respuesta sea correcta, tiene que estar claramente explicada para que sea comprensible. Por como funcionan los modelos de lenguaje esta explicación debe de producirse durante la generación de la respuesta. No puede producirse a posteriori. Ahora mismo lo que hay es un galimatías caótico. (un ejemplo clásico es ¿Cuál es el secreto de la vida el universo y todo lo demás?)
Confiables. Tenemos que poder confiar en la respuesta de estos modelos, ahora mismo las alucinaciones hacen que no podamos confiar en ellos plenamente. Está relacionado con el punto anterior ya que si podemos comprender el “porqué” de la respuesta podemos aprender a detectar las respuestas erróneas.
Razonamiento general: Es capaz de enfrentar problemas de todo tipo y crear estrategias para resolverlos. Un ser humano inteligente no es aquel que sabe la solución a un problema, es el que puede usar sus recursos para hallarla o aproximarse.
Coste asumible: Estos modelos tienen que funcionar en una escala realista. Se estima que a O3 superar el test ARC-AGI le costó más de un millón de dólares. Por mucho menos puedes contratar a un grupo de expertos humanos. La necesidad de potencia de cálculo, recursos como la RAM y tiempo puede disparar el precio de estos modelos.
Agentes:
Como ingeniero es mi solución favorita.
En lugar de un único modelo usa varios modelos diferentes colaborando en un flujo de trabajo para hallar la solución. Esto permite modelos más pequeños especializados en ciertas tareas.
Pueden lanzarse varios flujos de trabajo en paralelo afrontando el problema desde distintos puntos de vista.
Ventajas:
Modelos especializados y más pequeños
Modelos más fáciles de entrenar
Es fácil integrar diversas fuentes de datos y herramientas
Es más entendible.
Muy flexible.
No es necesario entrenar todas sus partes solo la que necesites mejorar.
Es fácil incluir “humanos” en el proceso
Problemas:
Un fallo en un agente puede propagarse a los demás.
Puedes usar agentes que verifican las respuestas. ¿Pero quién verifica al verificador?
Comunicar a los agentes entre si. Usar lenguaje natural puede no ser la mejor opción.
Requiere mucho trabajo y tiempo ir creando los diversos flujos de trabajo
LLM + entrenamiento:
Como fan de la ciencia ficción es mi solución favorita. Es la que más se aproxima a la idea que tenemos de IA inteligente.
Un modelo único capaz de generar respuestas inteligentes.
Ventajas:
La idea es simple
Problemas:
Requiere grandes modelos difíciles y caros de entrenar
Grandes cantidades de datos de calidad. Es difícil encontrar buenos ejemplos de razonamiento.
Ahora mismo su “razonamiento” no es muy entendible. A veces incluso llega a la respuesta correcta y la ignora.
Caros de usar
Ejemplos:
O1, O3, DeepSeek V3, QwQ 32B
LLM + algoritmos clásicos:
Como desarrollador de software es mi solución favorita. Combina el razonamiento de los modelos de lenguaje con pasos intermedios que ayudan a guiar este razonamiento hacia las mejores ideas.
Ventajas:
Se puede aplicar a modelos de lenguaje no entrenados para razonar.
Reduce los costes de razonamiento
Problemas:
¿Cómo saber lo buena qué es una idea?. Generalmente se usan LLM entrenados para ello, pero no son buenos cuantificando las ideas.
Ejemplos:
Marco-O1
Problemas del transformer:
Los actuales LLM usan diferentes modificaciones de un transformer, una arquitectura de red neuronal que pese a sus buenos resultados impone serias limitaciones.
Para nuestro caso nos afectan principalmente dos:
El contexto tiene un tamaño limitado. Pasado de cierto punto el modelo “pierde el hilo” del texto que está generando. Lo cual limita el tamaño del “razonamiento” que puede generar.
El modelo de lenguaje no predice una palabra, predice una distribución de probabilidad de que cada una de las palabras (realmente, tokens) que conoce sea el siguiente. Pero de ese resultado elegimos solo una y esa información se pierde. Por lo que el modelo de lenguaje pierde toda la información entre cada palabra.
Construyendo a Chispas 