La inteligencia artificial está avanzando a una velocidad absurda. Cada semana aparece una herramienta nueva, un modelo nuevo, un agente nuevo o una promesa nueva de que ahora sí, esta vez sí, la IA va a hacerlo todo por nosotros.
Pero cuanto más la uso, más clara tengo una cosa: el problema no es solo es estar actualizado, o saber escribir prompts. El problema es saber trabajar con contexto. Y esto cambia bastante la forma de entender la IA.
Durante mucho tiempo hemos usado herramientas como ChatGPT, Claude, Gemini… como si fueran un oráculo. Preguntamos algo, esperamos una respuesta y luego decidimos si nos sirve o no. Pero esa forma de usar la IA se queda corta. La IA no funciona bien cuando le pedimos cosas vagas. Funciona mejor cuando le damos contexto, límites, ejemplos, restricciones y una forma clara de validar si lo que nos devuelve tiene sentido.
Es decir: no se trata de pedirle hazme esto. Se trata de diseñar mejor el trabajo que queremos que haga.
1. Un LLM no piensa como una persona
Lo primero es quitarle un poco de magia al asunto.
Un LLM, no piensa como una persona, no entiende el mundo, no razona como lo haría un profesional y no tiene criterio propio sobre lo que está diciendo. Lo que hace, simplificandolo mucho, es predecir cuál es la siguiente palabra más probable a partir del texto que tiene delante. Y para entender bien esto, hay un concepto clave: el token.
Un token es la unidad mínima de texto que procesa el modelo, puede ser una palabra completa, una parte de una palabra o incluso un signo de puntuación. Cuando escribimos un prompt, el modelo no «comprende» nuestra intención como la comprende una persona. Lo que hace es usar patrones estadísticos aprendidos durante su entrenamiento para generar una continuación probable, token a token.
Por eso, cuando le damos más contexto útil, suele responder mejor. No porque «entienda más» en un sentido humano, sino porque tiene más señal e información estadística para predecir una respuesta útil, coherente y ajustada a lo que necesitamos, sin inventarse cosas.
No es lo mismo decirle:
«Hazme una estrategia de producto para mi SaaS»
Que decirle:
«Tengo un SaaS B2B para agencias de viaje. Los clientes tardan demasiado en completar el onboarding, soporte recibe muchas dudas repetidas y queremos reducir el tiempo hasta activación. Analiza estos mensajes de clientes, agrupa los problemas por causa y propón mejoras priorizadas por impacto y esfuerzo.»
La segunda respuesta va a ser mucho mejor. No porque la IA se haya vuelto mágicamente más inteligente, sino porque le hemos dado mejor material para trabajar.
Hay además otro punto importante, un LLM no es determinista. Si tu le das el mismo prompt 10 veces, te va a devolver respuestas distintas. El proceso de generación incluye cierta aleatoriedad controlada, lo que hace que el modelo no responda siempre exactamente igual, esto tiene implicaciones prácticas importantes, sobre todo, si usas IA profesionalmente, no deberías tratar una única respuesta como una verdad universal. Conviene comparar varias salidas, pedir revisiones y definir criterios claros para saber si lo que devuelve sirve o no.
2. La IA no arregla una mala definición del problema
Este es uno de los errores más comunes, le pedimos a la IA algo como Dame ideas para mejorar mi producto y nos devuelve una lista bastante correcta, pero también bastante genérica. Nos hablará de mejorar el onboarding, añadir analítica, escuchar a los usuarios, optimizar la conversión o personalizar la experiencia. Todo suena bien, pero no sirve demasiado para tomar decisiones, porque falta lo importante, que es el problema concreto.
¿Qué producto es? ¿Para qué tipo de cliente? ¿Qué métrica queremos mover? ¿Qué está pasando ahora? La IA no elimina la necesidad de pensar bienn, de hecho, hace justo lo contrario, deja más en evidencia cuando no hemos definido bien el problema. Si tú no sabes qué estás intentando resolver, la IA probablemente tampoco. Y lo que hará será rellenar huecos con respuestas que suenan bien, pero que pueden no servir para nada.
3. Más contexto no siempre es mejor
Aquí hay otro mito bastante peligroso «Cuanto más contexto le dé a la IA, mejor trabajará.»
No necesariamente. Más contexto no siempre significa mejor contexto. A veces significa más ruido. Puedes pasarle veinte documentos, diez conversaciones, cinco tickets, tres PDFs y una explicación larguísima. Puede que algo de eso ayude, pero también puede que el modelo acabe mezclando información, perdiendo lo importante o dando el mismo peso a cosas que no lo tienen.
El contexto funciona como una mesa de trabajo, si encima de la mesa tienes lo necesario, trabajas bien. Si encima de la mesa tienes todos los papeles de la empresa, probablemente acabes perdiendo lo importante, lo ideal no es darle contexto infinito, es darle contexto útil.
Aquí entra el concepto de ventana de contexto. Los modelos no pueden procesar texto infinito: trabajan con un límite máximo de tokens que depende de cada modelo, que es todo lo que el modelo puede «ver» en un momento determinado. Ese contexto incluye tus instrucciones, el historial de la conversación, los archivos que le has pasado y las respuestas anteriores.
Cuando ese límite se llena, el modelo ya no puede ver todo lo anterior tal cual ocurrió. Para poder continuar, hacen una especie de resumen automático de la conversación. Ese resumen permite seguir trabajando, pero también tiene un precio, puede omitir detalles importantes, puede asumir cosas que no se dijeron explícitamente, puede dar demasiado peso a una parte de la conversación y poco a otra, e incluso puede introducir errores o pequeñas «alucinaciones» porque ya no tiene el contexto completo, si no un resumen.
A partir de ese momento, el modelo ya no trabaja con la realidad completa de la conversación, sino con una versión comprimida e imperfecta. Esa versión pierde matices, restricciones o decisiones previas, y la IA empieza a completar huecos por su cuenta. Ahí aparecen muchas de las famosas alucinaciones, no siempre porque el modelo sea malo, sino porque está trabajando con contexto incompleto, contradictorio o demasiado ruidoso.
4. De chats a agentes
Hasta hace unos meses, la mayoría hemos usado la IA como un chat. Tú preguntas, la IA responde, y después tú copias, corriges o adaptas. Pero cada vez se habla más de agentes. La diferencia es sencilla: un chat te responde, un agente puede actuar, puede leer archivos, modificar código, consultar documentación, ejecutar comandos, revisar errores o conectarse con herramientas externas de forma automática.
En desarrollo de software, por ejemplo, un agente puede leer un repositorio, entender dónde está una funcionalidad, modificar varios archivos y ejecutar tests o redactar un ticket, subirlo a Jira y asignárselo a una persona. Esto ya no es solo dame una respuesta, es ayúdame a hacer el trabajo. Pero no todo es oro lo que reluce, seguimos con el problema de la ventana de contexto.
5. El agente todoterreno suele ser mala idea
Un error habitual es pedirle a un solo agente que lo haga todo, que analice el proyecto, entienda la arquitectura, diseñe la solución, escriba el código, cree los tests, corrija errores, documente el cambio y que ha PR, suena cómodo, pero no suele funcionar bien.
El problema no es solo que sean muchas tareas, el problema vuelve a ser estructural, y es el límite de tokens en la ventana de contexto. El agente lee archivos, toma decisiones, recibe instrucciones, ejecuta cambios, encuentra errores y sigue acumulando información. Al principio funciona bien, pero en tareas largas o complejas, el contexto empieza a llenarse rápido y cuando se llena, se resume, y cuando se resume, se pierden cosas.
Puede perderse una restricción importante, puede olvidarse una decisión previa, puede diluirse una regla de negocio. El agente sigue operando, pero ya no tiene acceso real a todo lo que necesitaría para hacerlo bien. Trabaja con una versión parcial, comprimida o imperfecta del problema. Por eso los agentes generalistas pueden parecer muy potentes en tareas pequeñas, pero empezar a fallar en trabajos largos, no porque no sepan, sino porque el contexto, pierde calidad, se degrada.
Es parecido a pedirle a una sola persona que haga de product manager, tech lead, developer, QA y documentación, poder puede, pero no es la mejor forma de asegurar calidad.
6. Subagentes: dividir el trabajo para reducir ruido
Una forma validad y mejor para trabajar con IA es dividir el trabajo, en vez de tener un único agente haciendo todo, puedes tener un agente principal que coordina y varios subagentes especializados. Uno analiza el problema, otro revisa la arquitectura, otro propone un plan, otro desarrolla, otro escribe tests y otro verifica si se cumple la especificación, etc. etc…
La ventaja es que cada uno trabaja con un contexto más pequeño y más concreto, no necesita saberlo todo, solo lo necesario para su tarea. Esto se parece mucho más a cómo trabajamos bien en producto y desarrollo, primero entendemos el problema, después diseñamos una solución, luego implementamos y después validamos. Cuando mezclamos todas esas fases, normalmente tomamos peores decisiones, con la IA pasa igual.
7. Skills: conocimiento bajo demanda
Otro concepto interesante es el de Skills, una Skill es, básicamente, una forma de darle a la IA conocimiento específico para una tarea concreta, sin meterle todo el contexto de golpe. Podrías tener una Skill para escribir tickets funcionales, otra para redactar release notes, otra para analizar entrevistas de usuario o para trabajar con una arquitectura concreta.
La clave es que la IA no necesite cargar siempre todas las reglas, si va a escribir un ticket funcional, carga las reglas para escribir ticketsm, así ahorras tokens. Si va a revisar copy, carga las reglas de tono y claridad, así ahorras tokens. Es una especie de contexto bajo demanda. Y esto tiene mucho sentido porque uno de los grandes problemas de trabajar con IA no es que le falte información, sino que muchas veces le damos demasiada información que no necesita, una Skill bien definida ayuda a reducir ruido, y reducir ruido suele mejorar el resultado, aparte de consumir menos tokens y optimizar nuestro gasto.
8. SDD: especificar antes de pedir
Aquí entra un concepto que me parece especialmente útil, SDD o Spec Driven Development. La idea es muy sencilla, antes de pedirle a la IA que desarrolle algo, defines bien qué tiene que hacer. Está inspirado en el TDD.
No le dices Hazme un endpoint para registrar usuarios. Le dices algo más parecido a esto:
Necesitamos un endpoint para registrar usuarios. Debe recibir nombre, email y contraseña. El email debe tener formato válido. La contraseña debe tener mínimo 8 caracteres. Si el email ya existe, debe devolver error 409. Si los datos son inválidos, error 400. Si se crea correctamente, devuelve 201. Debe incluir tests para éxito, email duplicado, email inválido y contraseña corta.
Esto ya no es una petición vaga, es una especificación, y cambia mucho el resultado, porque la IA tiene menos espacio para inventar. No tiene que decidir qué debería hacer el sistema, tiene que cumplir unas reglas concretas.
Aunque el SDD suene muy técnico, la idea aplica perfectamente a producto. En vez de Diseña una pantalla para gestionar reservas, sería:
Necesitamos una pantalla para gestionar reservas en estado propuesta. Estas reservas no están confirmadas y no deben ocupar stock. El usuario debe poder filtrarlas por tour, cliente, fecha de creación y estado. Desde la pantalla debe poder convertir una propuesta en reserva confirmada, descartarla o duplicarla.
A partir de ahí la IA puede ayudarte a sacar casos de uso, criterios de aceptación, dudas funcionales, riesgos o tickets para desarrollo. Pero la dirección la marcas tú.
9. La IA no sustituye el criterio
La IA no elimina la necesidad de pensar, de hecho, cuanto mejores son estas herramientas, más importante se vuelve tener criterio. La IA puede darte respuestas muy convincentes, y ese es precisamente el riesgo. Una mala respuesta escrita con seguridad puede parecer buena. Una solución mal enfocada puede sonar razonable. Por eso no deberíamos usarla como una máquina de respuestas finales, sino como una herramienta para pensar mejor, ordenar información, detectar patrones y revisar nuestro propio trabajo.
Pero también tiene otro papel muy valioso: puede ayudarte a explorar los bordes de tu pensamiento. Puede ayudarte a identificar lo que no sabes que no sabes: ángulos ciegos, preguntas que no te habías planteado, riesgos que no ves o dependencias que todavía no habías visto. También puede ayudarte a reconocer cosas que ya sabías pero que todavía no habías conseguido articular o explicar bien. A veces tienes una intuición sobre un problema, pero no la has convertido en una explicación clara. La IA puede ayudarte a ponerle estructura. No porque tenga mejor criterio que tú, sino porque puede devolverte un espejo ordenado de lo que estás pensando.
También puede cuestionarte, puedes pedirle que busque puntos débiles en una decisión, que piense como un cliente escéptico, que revise una propuesta desde negocio, desde soporte, desde tecnología o desde operaciones. Eso no significa que tenga razón. Significa que te obliga a mirar el problema desde más ángulos. Y eso es especialmente útil cuando trabajas solo o cuando un equipo lleva demasiado tiempo mirando el mismo problema desde los mismos sesgos. La decisión sigue siendo nuestra. Pero podemos llegar a ella con más perspectiva.
Conclusión
Para mí, la mejor forma de resumirlo es esta: la IA multiplica tu forma de trabajar. Si trabajas con claridad, te acelera. Si trabajas con método, te ayuda a producir más y mejor. Pero si trabajas con caos, también te acelera el caos. Si no defines restricciones, inventará supuestos. Si no validas lo que devuelve, puedes acabar dando por bueno algo que simplemente suena bien.
La IA no va solo de hacer mejores prompts. Va de trabajar con mejor contexto, mejores especificaciones y mejores formas de validar el resultado.
El salto importante no es pasar de un prompt corto a uno largo. El salto importante es pasar de «A ver qué me responde la IA» a «Voy a darle el contexto correcto, una tarea concreta, límites claros y una forma de comprobar si lo que devuelve sirve.» Ese cambio parece pequeño, pero lo cambia todo.
Porque trabajar bien con IA no consiste en tener fe en el modelo. Consiste en trabajar con más método. Y cuanto más avanzan estas herramientas, más importante se vuelve algo que ya era clave antes de la IA: definir bien los problemas, escribir mejor las especificaciones y validar mejor las soluciones.
