En esta ola de programación con IA, los conceptos vuelan por todas partes, las herramientas cambian de “piel” cada día, pero en el fondo no hay tanta “mística”.
Un Agent no es magia; en esencia, es ponerle a un LLM inestable una capa de “restricciones estructuradas” (Harness) para que la salida sea más controlable. Claude Code y Codex van por este camino.
1) Primero entiende el LLM: solo está adivinando el siguiente Token
Cuando entiendes esto, muchos “problemas místicos” dejan de serlo.
Según cómo le des contexto, así se desviará; según cómo lo guíes, hacia ahí irá.
Por eso es inevitable que los prompts pasen de la “adoración al formato” a la “expresión natural”, pero saber preguntar sigue siendo una habilidad dura.
2) Prompt no es que ya no sirva, sino que debe ser “menos inducción, más retroalimentación”
- No empieces metiendo una solución; primero cuenta el estado actual y el objetivo, y deja que el modelo te dé perspectivas;
- Iteración orientada a problemas: mira el resultado → señala el error → reescribe la instrucción → valida en una nueva conversación;
- Si fijas demasiado las palabras clave, es más fácil llevar al modelo al hoyo.
En una frase: menos controlar el camino, más verificar el resultado.
3) AGENTS.md es muy importante, pero no lo escribas como una “enciclopedia de aros de restricción”
En la comunidad hay muchos “debe/prohibido/principios” larguísimos; la mayoría es ruido.
Si le metes demasiadas restricciones al modelo, normalmente no se vuelve más estable, sino más torpe.
Las instrucciones globales deben definir límites y explicar herramientas, no domesticar el estilo.
4) No te dejes arrastrar por el “marketing de términos nuevos”
RAG, Context Engineering, MCP, Skills…
Muchas cosas son, en esencia, problemas viejos reempaquetados, o la estandarización del Prompt.
Lo que vale la pena perseguir no es la “palabra”, sino: si realmente puede reducir tu fricción y acortar el camino de entrega.
5) El desarrollo en paralelo tiene un tope: dos tareas es el límite de la mayoría
Abrir tres o cuatro Agent parece muy eficiente; en la práctica es reventar la caché del cerebro.
Notificaciones sonando sin parar solo interrumpen el flujo y crean la ilusión de “estoy muy ocupado”.
Sugerencia: apaga las notificaciones y revisa el progreso de forma activa.
Responder pasivamente a notificaciones = que el ritmo te controle; inspeccionar tareas activamente = tú controlas el ritmo.
6) Los archivos son memoria: mueve el contexto del “cerebro” al “sistema de archivos”
Un CLI Agent depende más de la lógica de búsqueda de texto.
Para que el Agent sea estable, no dependas de rezar, sino de documentación del proyecto que sea buscable y reutilizable.
Los archivos deben estar orientados a la ejecución final; no metas basura de proceso.
En esencia, es compensar las carencias innatas del modelo en contexto y atención.
7) Simplificación del flujo: primero planifica, luego programa
Tu método de dos pasos ahora es muy práctico:
- Discutir repetidamente y fijar el plan (PLAN / directorio plans)
- Implementar el código según el plan final y consolidar documentación de implementación (directorio docs)
El archivo de plan es el ancla; el código es el producto.
8) Orientación a resultados: menos obsesión con el “proceso elegante”, más foco en la “entrega verificable”
Pasar de “le enseño al Agent a escribir código paso a paso” a “yo gestiono la solución y los criterios de aceptación”.
Los errores pequeños en medio no los rebusques de inmediato; júntalos y corrígelos en bloque en la fase de revisión.
La calidad del código no se decide por emociones, sino por pruebas y una estructura depurable.
El objetivo central es uno solo: It just works.
9) Mejora de mentalidad: de ejecutor a gestor
Usa Codex como “cerebro externo + patito de goma”: tú te encargas de descomponer el problema, fijar estándares y hacer trade-offs;
él se encarga de la ejecución a gran escala.
No trates al Agent como un dios, ni como un juguete: es un amplificador, amplifica tu criterio y también amplifica tu caos.
10) Lecciones de malas prácticas
- Perseguir a ciegas “autonomous” funcionando por mucho tiempo no tiene mucho sentido;
- Lo realmente valioso es reducir la intervención manual y aumentar la probabilidad de entrega estable;
- Copiar tal cual el Prompt/Skills de otros permite arrancar rápido, pero no necesariamente encaja con tu proyecto;
- La ruta de crecimiento más efectiva: vigilar el proceso de ejecución, encontrar la causa raíz de los fallos e iterar tu propia metodología.
