Un modelo mental claro sobre cómo la IA genera código y decisiones en apps—tokens, ventana de contexto, herramientas y tests—además de límites y consejos prácticos para el prompting.
Cuando la gente dice “la IA piensa”, suele querer decir algo como: entiende tu pregunta, razona sobre ella y luego decide una respuesta.
Para las IA modernas basadas en texto (LLMs), un modelo mental más útil es más simple: el modelo predice qué texto debería salir a continuación.
Eso puede sonar decepcionante—hasta que ves hasta dónde puede llegar ese “siguiente texto”. Si el modelo ha aprendido suficientes patrones durante el entrenamiento, predecir la siguiente palabra (y la siguiente, y la siguiente) puede producir explicaciones, planes, código, resúmenes e incluso datos estructurados que tu app puede usar.
No necesitas aprender las matemáticas subyacentes para construir buenas funciones de IA. Lo que sí necesitas es una manera práctica de anticipar el comportamiento:
Este artículo es ese tipo de modelo: no es hype ni un paper técnico profundo—solo los conceptos que te ayudan a diseñar experiencias de producto fiables.
Desde la perspectiva de un creador de apps, el “pensamiento” del modelo es el texto que genera en respuesta al input que le das (tu prompt, mensajes del usuario, reglas del sistema y cualquier contenido recuperado). El modelo no verifica hechos por defecto, no navega la web y no “sabe” lo que contiene tu base de datos a menos que le pases esa información.
Ajusta expectativas: los LLM son increíblemente útiles para redactar, transformar y clasificar texto, y para generar salidas tipo código. No son máquinas mágicas de verdad.
Dividiremos el modelo mental en unas cuantas partes:
Con estas ideas puedes diseñar prompts, interfaces y salvaguardas que hagan que las funciones de IA se sientan consistentes y confiables.
Cuando la gente dice que una IA “piensa”, es fácil imaginar razonamiento humano. Un modelo mental más útil es más sencillo: está haciendo autocompletado extremadamente rápido—un fragmento pequeño a la vez.
Un token es un fragmento de texto con el que trabaja el modelo. A veces es una palabra completa (“manzana”), a veces parte de una palabra (“man” + “zana”), a veces puntuación y a veces espacio. El troceado exacto depende del tokenizer del modelo, pero la conclusión es: el modelo no procesa texto como oraciones ordenadas—procesa tokens.
El bucle central del modelo es:
Eso es todo. Cada párrafo, lista y “cadena de razonamiento” que veas se construye repitiendo esta predicción del siguiente token muchas veces.
Porque el modelo ha visto enormes cantidades de texto durante el entrenamiento, aprende patrones como cómo fluyen las explicaciones, cómo suena un email educado o cómo se describe típicamente una corrección de bug. Cuando haces una pregunta, genera una respuesta que encaja con los patrones que ha aprendido y que coincide con el contexto que le diste.
Por eso puede sonar confiado y coherente incluso cuando está equivocado: está optimizando por qué texto debería venir después, no por comprobar la realidad.
El código no es algo especial para el modelo. JavaScript, SQL, JSON y mensajes de error son todas secuencias de tokens. El modelo puede producir código útil porque ha aprendido patrones comunes de programación, no porque realmente “entienda” tu aplicación como lo haría un ingeniero de tu equipo.
Cuando la gente pregunta “¿de dónde sacó eso el modelo?”, el modelo mental más útil es: aprendió patrones a partir de un gran número de ejemplos y ahora recombina esos patrones para predecir qué texto viene después.
Durante el entrenamiento, el modelo ve muchos fragmentos de texto (libros, artículos, código, documentación, preguntas y respuestas, y más). Practica repetidamente una tarea simple: dada una secuencia de texto, predecir el siguiente token. Cuando se equivoca, el proceso de entrenamiento ajusta los parámetros internos del modelo para que sea un poco más probable predecir mejor la próxima vez.
Con el tiempo, esos ajustes suman. El modelo empieza a codificar relaciones como:
Porque aprende regularidades estadísticas—no un guion fijo—puede combinar patrones de formas nuevas. Si ha visto muchos ejemplos de “explicar un concepto” y muchos ejemplos de “tu escenario de app”, a menudo puede fusionarlos en una respuesta a medida.
Por eso un LLM puede redactar un email de incorporación plausible para un producto de nicho o adaptar una explicación genérica de integración de API a un stack específico. No está recuperando un párrafo almacenado; está generando una nueva secuencia que coincide con patrones aprendidos.
Aunque algunos datos de entrenamiento incluyeran un hecho específico (por ejemplo, un plan de precios o una política interna), no deberías asumir que el modelo puede “consultarlo” de forma fiable. El entrenamiento no funciona como indexar una base de conocimiento que puedas consultar más tarde. Es más parecido a compresión: muchos ejemplos se destilan en pesos que influyen en predicciones futuras.
Eso significa que el modelo puede sonar seguro sobre detalles que está adivinando en función de lo que suele aparecer en contextos similares.
El aprendizaje por patrones es poderoso para producir texto fluido y relevante, pero fluidez no es lo mismo que verdad. El modelo puede:
Para los creadores de apps, la conclusión clave es: las respuestas de un LLM suelen derivar de patrones aprendidos, no de hechos verificados. Si la corrección importa, deberás anclar la salida con tus propios datos y comprobaciones (veremos esto en secciones posteriores).
Cuando un LLM escribe una respuesta, no extrae una “frase correcta” de una base de datos. En cada paso predice una gama de tokens posibles, cada uno con una probabilidad.
Si el modelo siempre eligiera el token único más probable, las respuestas serían muy consistentes—pero también repetitivas y a veces torpemente rígidas. La mayoría de sistemas en cambio muestran (sample) desde las probabilidades, lo que introduce aleatoriedad controlada.
Dos configuraciones comunes influyen en cuánto varían las salidas:
Si construyes una app, estos controles tratan menos sobre “ser creativo” en sentido artístico y más sobre elegir entre:
Porque el modelo optimiza texto plausible, puede producir afirmaciones que suenan ciertas—aunque la afirmación subyacente sea incorrecta o le falte contexto. La confianza en el tono no es evidencia. Por eso las apps suelen necesitar anclaje (recuperación) o pasos de verificación para tareas factuales.
Pide a un LLM: “Escribe una función en JavaScript que elimine duplicados de un array.” Puedes obtener cualquiera de estas, todas válidas:
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicit
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
Diferentes elecciones de muestreo conducen a estilos distintos (conciso vs explícito), compensaciones distintas (velocidad, legibilidad) e incluso distinto manejo de casos límite—todo sin que el modelo “cambie de opinión”. Simplemente está eligiendo entre continuaciones de alta probabilidad.
Cuando se dice que un modelo “recuerda” la conversación, lo que realmente tiene es contexto: el texto que puede ver ahora mismo—tu último mensaje, las instrucciones del sistema y la porción del chat anterior que aún encaja.
La ventana de contexto es un límite fijo sobre cuánto texto el modelo puede considerar de una vez. Cuando la conversación es lo bastante larga, las partes antiguas salen de la ventana y efectivamente desaparecen de la vista del modelo.
Por eso verás comportamientos como:
Si sigues añadiendo mensajes a un hilo, compites por espacio limitado. Las restricciones importantes se empujan fuera por el intercambio reciente. Sin un resumen, el modelo debe inferir qué es lo importante a partir de lo que todavía está visible—y puede sonar confiado mientras pasa por alto detalles clave.
Una solución práctica es resumir periódicamente: vuelve a plantear el objetivo, las decisiones y las restricciones en un bloque compacto y continúa desde ahí. En apps, esto suele implementarse como un “resumen de conversación” automático que se inyecta en el prompt.
Los modelos tienden a seguir instrucciones que están cercanas a la salida que van a generar. Así que si tienes reglas que deben cumplirse (formato, tono, casos límite), colócalas cerca del final del prompt—justo antes de “Ahora produce la respuesta.”
Si construyes una app, trata esto como diseño de interfaz: decide qué debe permanecer en contexto (requisitos, preferencias del usuario, esquema) y asegúrate de incluirlo siempre—ya sea recortando el historial del chat o añadiendo un resumen conciso. Para más sobre cómo estructurar prompts, ver /blog/prompting-as-interface-design.
Los LLM son muy buenos produciendo texto que suena como la respuesta esperada de un desarrollador competente. Pero “suena correcto” no es lo mismo que “es correcto”. El modelo predice tokens probables, no verifica la salida contra tu código, tus dependencias o el mundo real.
Si el modelo sugiere una corrección, un refactor o una función nueva, sigue siendo solo texto. No ejecuta tu app, no importa tus paquetes, no llama tu API ni compila tu proyecto a menos que lo conectes explicitamente a una herramienta que haga esas cosas (por ejemplo, un runner de tests, un linter o un paso de build).
Ese es el contraste clave:
Cuando la IA se equivoca, suele fallar de formas previsibles:
Estos errores pueden ser difíciles de notar porque la explicación circundante suele ser coherente.
Trata la salida de la IA como un borrador rápido de un compañero que no ejecutó el proyecto localmente. La confianza debe aumentar mucho después de que tú:
Si los tests fallan, asume que la respuesta del modelo es solo un punto de partida, no una solución final.
Un modelo de lenguaje es bueno proponiendo lo que podría funcionar—pero por sí solo sigue produciendo texto. Las herramientas permiten a una app respaldada por IA convertir esas propuestas en acciones verificadas: ejecutar código, consultar una base, buscar documentación o llamar a una API externa.
En flujos de trabajo para construir apps, las herramientas suelen ser:
El cambio importante es que el modelo ya no finge conocer el resultado—puede comprobarlo.
Un modelo mental útil es:
Así reduces la “conjetura”. Si el linter informa imports no usados, el modelo actualiza el código. Si los tests fallan, itera hasta que pasen (o explica por qué no puede).
eslint/ruff/prettier para confirmar estilo y detectar problemas.Las herramientas pueden ser poderosas—y peligrosas. Sigue el principio de menor privilegio:
Las herramientas no hacen al modelo “más inteligente”, pero hacen tu IA en la app más anclada—porque puede verificar, no solo narrar.
Un modelo de lenguaje es excelente escribiendo, resumiendo y razonando sobre el texto que puede “ver”. Pero no conoce automáticamente tus cambios de producto más recientes, las políticas de tu empresa o los detalles de la cuenta de un cliente. Retrieval-Augmented Generation (RAG) es una solución simple: primero obtén los hechos más relevantes y luego pide al modelo que escriba usando esos hechos.
Piensa en RAG como “IA con libro abierto”. En lugar de pedirle al modelo que responda de memoria, tu app extrae rápidamente unos cuantos pasajes relevantes (snippets) de fuentes confiables y los añade al prompt. El modelo entonces genera una respuesta basada en ese material proporcionado.
RAG es una buena opción por defecto siempre que la corrección dependa de información externa al modelo:
Si el valor de tu app depende de “la respuesta correcta para nuestro negocio”, RAG suele ser mejor que esperar que el modelo lo adivine.
RAG solo es tan bueno como lo que recupera. Si el paso de búsqueda devuelve pasajes desactualizados, irrelevantes o incompletos, el modelo puede producir una respuesta equivocada pero ahora “anclada” en la fuente equivocada. En la práctica, mejorar la calidad de la recuperación (chunking, metadata, frescura y ranking) suele aumentar la precisión más que ajustar prompts.
Un “agente” es simplemente un LLM en un bucle: hace un plan, ejecuta un paso, observa qué pasó y decide qué hacer a continuación. En vez de responder una vez, itera hasta alcanzar un objetivo.
Un modelo mental útil es:
Plan → Hacer → Comprobar → Revisar
Este bucle es lo que convierte un prompt único en un pequeño flujo de trabajo. También explica por qué los agentes pueden sentirse más “independientes” que un chat: el modelo no solo genera texto, decide acciones y las secuencia.
Los agentes necesitan reglas claras para saber cuándo detenerse. Condiciones comunes de parada incluyen:
Las salvaguardas son las restricciones que mantienen el bucle seguro y predecible: herramientas permitidas, fuentes de datos autorizadas, pasos de aprobación (humano en el bucle) y formatos de salida.
Porque un agente siempre puede proponer “un paso más”, debes diseñar para fallos. Sin presupuestos, timeouts y límites de pasos, un agente puede enroscarse en acciones repetitivas (“intenta otra vez con una consulta ligeramente distinta”) o acumular costos.
Defaults prácticos: limitar iteraciones, registrar cada acción, validar resultados de herramientas y fallar de forma elegante con una respuesta parcial más lo que intentó. Eso suele ser mejor diseño de producto que dejar que el agente se ejecute indefinidamente.
Si construyes con una plataforma de tipo vibe-coding como Koder.ai, este modelo mental de “agente + herramientas” es especialmente práctico. No solo estás chateando por sugerencias—estás usando un flujo donde el asistente puede ayudar a planear características, generar componentes React/Go/PostgreSQL o Flutter, e iterar con puntos de control (por ejemplo, snapshots y rollback) para avanzar rápido sin perder control de los cambios.
Cuando pones un LLM detrás de una función de producto, tu prompt deja de ser “solo texto”. Es el contrato de interfaz entre tu producto y el modelo: qué intenta hacer el modelo, qué se le permite usar y cómo debe responder para que tu código lo consuma de forma fiable.
Una mentalidad útil es tratar los prompts como formularios de UI. Los buenos formularios reducen la ambigüedad, constriñen opciones y hacen la siguiente acción obvia. Los buenos prompts hacen lo mismo.
Antes de lanzar un prompt, asegúrate de que indique claramente:
Los modelos siguen patrones. Una forma potente de “enseñar” el patrón que quieres es incluir un ejemplo único de buena entrada y buena salida (especialmente si la tarea tiene casos límite).
Incluso un solo ejemplo puede reducir ida y vuelta y evitar que el modelo invente un formato que tu UI no pueda mostrar.
Si otro sistema va a leer la respuesta, estructúrala. Pide JSON, una tabla o listas estrictas.
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
"result": "string",
"confidence": "low|medium|high",
"warnings": ["string"],
"next_steps": ["string"]
}
Esto convierte el “prompting” en diseño de interfaz predecible.
Añade una regla explícita como: “Si faltan requisitos clave, haz preguntas aclaratorias antes de responder.”
Esa sola línea puede evitar salidas equivocadas que parecen seguras—porque el modelo está permitido (y se espera) que se detenga y pida los campos faltantes en vez de adivinar.
En la práctica, los prompts más fiables coinciden con la forma en que tu producto construye y despliega. Por ejemplo, si tu plataforma admite planear primero, luego generar cambios y luego exportar código o desplegar, puedes reflejar eso en el contrato del prompt (plan → producir diff/pasos → confirmar → aplicar). El “planning mode” de Koder.ai es un buen ejemplo de cómo convertir el proceso en fases explícitas puede reducir la deriva y ayudar a los equipos a revisar cambios antes de enviarlos.
La confianza no viene de que un modelo “suene” seguro. Viene de tratar la salida de IA como cualquier otra dependencia de producto: medida, monitorizada y constriñida.
Empieza con un pequeño conjunto de tareas reales que tu app debe ejecutar bien. Luego conviértelas en comprobaciones repetibles:
En lugar de preguntar “¿Está bien?”, controla “¿Con qué frecuencia pasa?” Métricas útiles incluyen:
Cuando algo falla, debes poder reproducirlo. Registra (con la redacción adecuada):
Esto hace la depuración práctica y te ayuda a responder “¿Cambió el modelo o cambiaron nuestros datos/herramientas?”.
Unos cuantos defaults evitan incidentes comunes:
Normalmente significa que el modelo puede producir texto coherente y dirigido a un objetivo que parece comprensión y razonamiento. En la práctica, un LLM hace predicción del siguiente token: genera la continuación más probable dado tu prompt, instrucciones y cualquier contexto provisto.
Para los desarrolladores de aplicaciones, la conclusión útil es que “pensar” es el comportamiento de salida que puedes moldear y restringir, no una garantía interna de veracidad.
Un token es un fragmento de texto que el modelo procesa y genera (una palabra completa, parte de una palabra, puntuación o espacio). Como los modelos operan sobre tokens y no sobre “frases”, los costes, límites y truncamientos se miden en tokens.
En la práctica:
Porque la generación es probabilística. En cada paso el modelo asigna probabilidades a muchos tokens posibles y la mayoría de sistemas muestra (sample) desde esa distribución en vez de elegir siempre la opción más probable.
Para hacer salidas más repetibles:
Los LLM optimizan producir texto plausible, no verificar hechos. Pueden sonar seguros porque la redacción confiada es un patrón común en los datos de entrenamiento, incluso cuando la afirmación subyacente es una conjetura.
En diseño de producto, trata la fluidez como “buena redacción”, no como “correctitud”, y añade verificaciones (recuperación, herramientas, tests, aprobaciones) cuando la exactitud sea crítica.
La ventana de contexto es la cantidad máxima de texto que el modelo puede considerar de una vez (instrucciones del sistema, historial de la conversación, fragmentos recuperados, etc.). Cuando el hilo se alarga demasiado, la información antigua sale de la ventana y el modelo deja de “verla”.
Mitigaciones:
No automáticamente. Por defecto el modelo no navega por la web, no lee tu base de datos ni ejecuta código. Solo tiene acceso a lo que incluyes en el prompt y a las herramientas que conectes explícitamente.
Si la respuesta depende de hechos internos o actualizados, pásalos mediante recuperación (RAG) o una llamada a herramienta en lugar de “preguntar más fuerte”.
Usa herramientas cuando necesites resultados verificados o acciones reales en vez de texto plausible. Ejemplos comunes:
Un buen patrón es proponer → comprobar → ajustar, donde el modelo itera según las salidas de las herramientas.
RAG (Retrieval-Augmented Generation) es “IA con libro abierto”: tu app recupera fragmentos relevantes de fuentes confiables (docs, tickets, políticas) y los incluye en el prompt para que el modelo conteste usando esos hechos.
Usa RAG cuando:
El principal modo de fallo es una mala recuperación: mejorar la búsqueda, el chunking y la frescura suele ser más efectivo que ajustar prompts.
Un agente es un LLM que ejecuta un bucle de múltiples pasos (planear, ejecutar una acción, comprobar resultados, revisar) usando a menudo herramientas. Es útil para flujos como “buscar info → redactar → validar → enviar”.
Para mantener agentes seguros y previsibles:
Trata los prompts como un contrato de interfaz: define objetivo, entradas, restricciones y formato de salida para que tu aplicación pueda consumir resultados de forma fiable.
Constructores de confianza prácticos: