Respuesta corta: Trabajar con IA tiene menos que ver con vibe coding y más con operar un sistema capaz: establecer contexto, restricciones, criterio y flujos duraderos para que los agentes hagan trabajo útil.
Pensé que estaba aprendiendo a construir con IA.
Al mirar los últimos meses, creo que estaba pasando algo distinto.
Estaba aprendiendo a operar.
Nunca estuve haciendo “vibe coding” de verdad
Mi manera de trabajar con IA no empezó con código.
Empezó con lenguaje.
Probablemente tenga sentido si me conoces. Tengo una licenciatura en Letras, y bromeo con eso a menudo trabajando en la industria tecnológica, pero una de las habilidades más útiles que traje a todo este proceso fue poder tomar algo desordenado, partirlo en piezas modulares, diseccionarlo y reformularlo en algo más fácil de entender.
Eso siempre ha sido lo que me hace disfrutar el trabajo.
Me ayudó como capacitador de call center. Me ayudó como administrador de Salesforce. Me ayudó cuando enseñaba currículos difíciles de banca en línea a nuevos agentes. Me ayudó cuando construía flujos e intentaba que la automatización declarativa tuviera sentido.
Y luego, de forma inesperada, me ayudó a trabajar con LLM.
Modelos como Claude y Codex son potentes. Pueden razonar, investigar, escribir, generar código, inspeccionar archivos, resumir sistemas y avanzar más rápido que cualquier ciclo de trabajo normal.
Pero no se alinean automáticamente con el problema que tienes delante.
Siguen necesitando contexto.
Siguen necesitando prioridades.
Siguen necesitando restricciones.
Siguen necesitando que alguien decida qué significa “bien hecho”.
En ese sentido, trabajar con IA empezó a sentirse menos como “pedirle a algo que programe” y más como gestionar a un empleado nuevo muy capaz.
Ese empleado tiene un abanico enorme de habilidades, pero no sabe automáticamente cómo aplicarlas al problema concreto.
Ese pasó a ser mi papel.
No intentaba ser el ingeniero en el sentido tradicional. Actuaba más como Product Owner, gerente, formador y operador. Yo llevaba la visión general, descomponía el trabajo, aclaraba el resultado esperado y usaba Claude o Codex para ayudar a ejecutar, investigar, cuestionar y refinar el plan.
¿Te suena?
Debería.
Es algo que la gente hace todos los días en el trabajo con sus compañeros. La diferencia es que este compañero está disponible todo el tiempo, responde de inmediato, investiga rápido y puede darte algo útil cuando lo pides.
Sin plazos de dos semanas.
Sin “déjame y te aviso”.
Era instantáneo.
Por eso no creo que “vibe coding” describa con precisión lo que estaba haciendo.
El trabajo no era aleatorio. Era estructurado. Era guiado. Era revisado. Y con el tiempo dejó de tratarse de escribir mejores prompts sueltos y pasó a tratarse de diseñar mejores sistemas dentro de los cuales los agentes de IA pudieran operar.
Uno de mis prompts se veía así:
“Comparando lo que el cliente quiere y lo que construimos con Aster, ¿cómo lo generalizamos hacia nuestro constructor de agentes de IA? ¿Cuáles son los componentes de un runtime de agente con enrutamiento dinámico de intención? Dibuja este concepto en ASCII art y, a partir de eso, ¿cómo lo hacemos declarativo y construible por los usuarios durante la experiencia del constructor de agentes, y luego actualizable después?”
Ese no es realmente un prompt de “constrúyeme una cosa”.
Ese soy yo intentando tomar una idea desordenada, desarmarla, entender su forma y convertirla en algo que otra persona pudiera usar.
Herramienta diferente.
Mismo cerebro.
La fase inicial: prompts grandes, visión grande
Adoptar una mentalidad de operador dio forma a los prompts que enviaba.
Nunca me acerqué al código como si ya supiera cómo funcionaba todo. Traté eso como el dominio del LLM. Mi trabajo no era fingir ser el desarrollador. Mi trabajo era hacer las preguntas correctas, entender el sistema lo suficiente para tomar decisiones y luego aplicar criterio.
Se parecía mucho a cómo había trabajado con desarrolladores en el pasado.
Que ellos hagan la magia del código.
Que yo ayude a guiar el resultado.
Uno de mis primeros prompts se veía así:
“Explora el código de AgentShelf para entender la arquitectura de la capa de contexto, específicamente: 1. Cómo funcionan los manifiestos AGENTS.md… 2. Cómo funciona la inyección de contexto… 3. Cómo funcionan los archivos de agente y la biblioteca de contexto… 4. Cómo se conecta todo esto con los chats y los espacios de trabajo… Devuelve un resumen de todos los componentes y cómo se conectan.”
Eso no era pedirle a la IA que construyera algo a ciegas.
Era pedirle que me ayudara a entender el terreno.
Una vez que tenía el análisis, no me detenía ahí. Leía lo que me daba, decidía si tenía información suficiente y entonces hacía preguntas de seguimiento o avanzaba hacia un plan.
Esa es la parte que creo que mucha gente pasa por alto.
Les preocupa, con razón, la alucinación. ¿Y si el modelo se inventa algo? ¿Y si su respuesta está mal?
Mi respuesta es que esto no era confianza ciega.
Era confianza fundamentada.
Cuando le pedía al LLM que inspeccionara el código, no le pedía que inventara una respuesta a partir de conocimiento general. Le pedía que mirara archivos reales, siguiera flujos reales y me explicara el sistema en lenguaje natural.
¿Podía equivocarse igualmente?
Por supuesto.
Pero ahora tenía algo concreto que verificar.
Esa es una de las lecciones más grandes que aprendí trabajando con LLM:
El contexto es el rey.
Cuanto más ayudaba al modelo a trabajar dentro del contexto correcto, más útil se volvía.
Por eso importaban prompts como estos:
“Necesito entender cómo se maneja el historial de conversación y el contexto al enviar mensajes al LLM… Cuántos mensajes se envían… Se resume el historial… ¿Qué pasa si un usuario cambia de proveedor de LLM a mitad de una conversación?”
“Necesito que traces el flujo completo de cómo se supone que deben persistirse las ejecuciones de herramientas… Las herramientas se están ejecutando durante el chat en vivo… pero no se persiste nada después de la sesión…”
Estos prompts me ayudaron a entender, en lenguaje natural, qué estaba ocurriendo dentro del código.
Una vez que lo entendía, podía guiar al LLM hacia el resultado que necesitaba.
Luego probaba.
Si el resultado pasaba, genial.
Si no, llevaba el fallo de vuelta a la conversación, explicaba qué había salido mal, repasaba el plan a seguir y solo entonces le pedía hacer otro cambio.
Ese era el proceso.
Nada de magia.
Nada de vibes.
Mucho prompting, fundamentación, pruebas, corrección y guía hacia un resultado final.
Cuando tratas a un LLM como a un colega en lugar de como a una máquina expendedora, esto empieza a sentirse natural. Le das contexto. Le pides que explique. Cuestionas el resultado. Guías el siguiente paso.
Y con el tiempo dejas de pensar en ti mismo como alguien que intenta programar y empiezas a pensar en ti como alguien que opera el trabajo.
El cambio: specs, criterios de aceptación, PBI y memoria del agente
Esto lo aprendí por las malas con Storyweaver. Venía improvisando en ese proyecto de CLI, lanzando prompts con libertad, pasándomelo bien, y entonces, en una sesión, dejé que el modelo me convenciera de una “reducción del 70 % del código” sin preguntar primero qué pensaba recortar. Destripó el proyecto. Ese momento cambió mi forma de trabajar.
Un prompt de chat es temporal. El modelo no recuerda lo que dijo hace tres sesiones. No sabe qué estabas protegiendo. No sabe qué te costó dos semanas dejar bien. Eso no es un defecto: es simplemente la realidad de cómo funcionan hoy estos sistemas.
Así que dejé de intentar meterlo todo en un prompt perfecto y empecé a mover las partes importantes del trabajo hacia artefactos que el modelo pudiera consultar una y otra vez. Specs. Criterios de aceptación. PBI. Historial de Git. Instrucciones del espacio de trabajo.
Piensa en por qué los equipos escriben historias y tareas en JIRA. Para que puedas fichar la salida el viernes, volver el lunes y saber exactamente dónde lo dejaste. Qué se decidió. Qué está bloqueado. Qué viene después.
Los LLM necesitan esa misma superficie de operación.
No porque sean frágiles. Sino porque el contexto es el rey, y cuanto más ayudes al modelo a permanecer dentro del contexto correcto, menos probable será que vuelva a ofrecerse a borrar el setenta por ciento de algo que construiste.
La habilidad de verdad: el criterio
La lección de Storyweaver fue, en realidad, una lección de criterio.
El modelo no era malicioso. No estaba roto. Hacía lo que yo le pedía, dentro del contexto que le había dado, que no era suficiente. No le había dicho qué importaba. No le había dicho qué proteger. No le había pedido que mostrara su trabajo antes de dar el martillazo.
Esa es la parte de la que no se habla lo suficiente.
Cualquiera puede enviar un mensaje a un LLM y obtener una respuesta. La habilidad está en saber qué preguntar antes de decir adelante. Saber cuándo una respuesta suena emocionante pero todavía no está fundamentada. Saber cuándo frenar y pedirle al modelo que te enseñe un plan antes de empezar a ejecutarlo.
Criterio es darte cuenta de que la interfaz no está bien. Criterio es darte cuenta de que el flujo confunde. Criterio es reconocer cuándo algo funciona técnicamente pero todavía no tiene sentido como producto.
También es saber cuándo no fiarse de un número como “setenta por ciento”.
Los modelos han mejorado muchísimo recomendando cosas. Pero todavía hay que apuntarlos hacia las restricciones correctas. Todavía necesitan a alguien que haga las preguntas que obligan al trabajo a rendir cuentas con la realidad: límites de API, riesgo de regresión, lo que un usuario realmente necesita frente a lo que pidió literalmente.
Eso no es una habilidad específicamente de desarrollo. Es una habilidad de operador. Y resulta que años descomponiendo procesos complejos, escribiendo instrucciones claras y gestionando resultados entre sistemas fueron mejor preparación de lo que esperaba.
De constructor a operador de IA
Tener un espacio de trabajo bien definido para un agente de IA cambia lo que se vuelve posible.
Para mí, el objetivo siempre ha sido el patrón de relación de Iron Man y Jarvis.
No porque crea que literalmente estamos ahí.
Sino porque el modelo operativo es útil: un sistema que entiende el espacio de trabajo, recuerda la misión, conoce las herramientas disponibles y puede ayudar a coordinar el trabajo sin que haya que reexplicarlo todo.
Para acercarme funcionalmente a eso, tuve que definir mis espacios de trabajo de una forma que me permitiera confiar en que el agente entendía quién, qué, cuándo y cómo abordar la tarea.
Eso significó buscar patrones repetibles.
Empecé a reconocer qué prompts ya no eran prompts de una sola vez.
Si repetía un flujo de trabajo, pedía el mismo tipo de revisión, daba la misma advertencia una y otra vez o secuenciaba el trabajo de la misma manera entre PBI, esa era la señal de que debía pasar a formar parte del espacio de trabajo.
Ese criterio solía venir de mí.
No le pedía al agente que decidiera qué debía convertirse en una skill. Reconocía patrones en mi propio flujo de trabajo: los tipos de revisión que seguía pidiendo, los bucles de planificación que seguía repitiendo, los pasos de limpieza que quería después de cada PBI o los flujos con la CLI de Salesforce que sabía que tendrían que volverse reutilizables.
Una vez que veía el patrón, entonces sí podía usar al agente para ayudar a convertirlo en algo duradero.
Una skill.
Un comando de barra.
Un flujo de trabajo.
Una instrucción de proyecto.
Un patrón operativo reutilizable.
Esa distinción importa.
El agente puede ayudar a construir la skill, refinarla o aplicarla.
Pero el criterio de que algo merece convertirse en skill viene de entender el trabajo.
Después, igual que al trabajar con un colega, se vuelve más fácil seguir trabajando de la misma manera, porque le has enseñado a tu contraparte cómo operas.
Una vez montado esto, tus prompts empiezan a hacerse más pequeños.
No porque hayas dejado de aportar experiencia, sino porque ese prompt largo que solías enviar sobre cuidar X, Y y Z ahora vive en otro sitio. Pasa a formar parte del flujo de trabajo. Pasa a formar parte del espacio de trabajo. Pasa a formar parte del contexto duradero al que el agente puede volver.
A veces esos flujos generan más artefactos, que a su vez aportan un contexto aún más fundamentado dentro del cual el agente puede trabajar.
El contexto es el rey.
Con eso en su lugar, mis prompts de los últimos meses empezaron a verse así:
“Confirmemos todos los cambios y pasemos al siguiente PBI. ¿Podemos implementar todos los PBI por separado usando subagentes en paralelo?”
“Actualicemos ese diagrama entidad-relación con el estado actual del código lanzando varios subagentes en paralelo para abordar distintas partes del código.”
Esos prompts son más cortos, pero no menos informados.
Funcionan porque el contexto ya no está solo dentro del prompt. El contexto está en el espacio de trabajo, en los artefactos, en los PBI, en las specs, en las skills y en los patrones operativos que se han construido alrededor del trabajo.
Ahí fue cuando pude dejar de tratar a la IA como un único asistente de chat y empezar a tratarla como una capa operativa.
De pronto, pedirle a varios subagentes que revisaran algo se volvió menos arriesgado. El trabajo estaba definido dentro del espacio de trabajo. El agente podía leer los archivos relevantes, consultar los artefactos y entender los límites de la tarea.
Eso significaba que podía iniciar una sesión nueva, apuntar al agente hacia otra parte de una funcionalidad y no sentir que empezaba desde cero.
Sabía por dónde empezar.
Tenía mejor idea de cómo proceder.
Y, igual de importante, tenía mejor idea de qué no romper.
Por qué esto importa para AgentShelf
Todo lo anterior —la configuración del espacio de trabajo, el contexto duradero, el criterio del operador— tuve que descubrirlo yo mismo a base de prueba y error, incluido un código de Storyweaver destruido. La mayoría de la gente no va a hacer eso. Y no debería tener que hacerlo.
Esa es la razón honesta por la que estoy construyendo AgentShelf: infraestructura que permita a alguien trabajar como yo trabajo sin necesitar saber todo lo que yo sé para llegar ahí.
