En marzo de 2026, Matt Van Horn publicó un hilo largo en la plataforma X con un título muy directo: "Cada truco de Claude Code que conozco". El número de visualizaciones de esa publicación finalmente se detuvo en 913,000, y la sección de comentarios se convirtió en un verdadero caos.
Lo que desató la controversia no fue un comando o parámetro de configuración específico, sino una afirmación que hizo al principio: No IDE. Al describir su forma de trabajar, mencionó que durante todo el proceso no abrió ni una sola vez un editor gráfico, y que todas las operaciones de desarrollo ocurrían en la línea de comandos de la terminal y en un archivo llamado plan.md. Algunos lo encontraron absurdo y le preguntaron cómo manejaba la lectura, depuración y refactorización del código; otros ingenieros experimentados comentaron diciendo "esta es la forma que llevo tiempo buscando".
Dos meses después, el desarrollador chino meng shao compiló y publicó esta metodología junto con las prácticas derivadas de la comunidad, bajo el título "Registro completo de trucos prácticos de ingeniería de agentes". No es una reseña de herramientas, sino un conjunto de principios operativos centrados en el ciclo "Investigar → Planificar → Trabajar", respaldados por 22 técnicas específicas reproducibles o discutibles.
Este artículo compila algunas de las guías de flujo de trabajo con IA más discutidas en línea, de las cuales quizás podamos extraer elementos comunes.
Cerrar el IDE: ¿Qué pierdes realmente?
Un IDE gráfico ofrece al desarrollador mucho más que un área de edición de código. Es un sistema sensorial completo: el resaltado de sintaxis te permite distinguir a simple vista variables y palabras clave, las sugerencias de errores en tiempo real te indican dónde hay problemas mientras escribes, la depuración con puntos de ruptión te permite observar los cambios en el estado de las variables línea por línea, y la navegación con árbol de archivos y migas de pan te ayuda a no perderte en proyectos grandes. Todo este mecanismo de retroalimentación visual constituye una suposición por defecto: quien escribe código necesita ver con sus propios ojos el estado de cada línea.
El flujo de trabajo basado en terminal + archivo Markdown elimina esa capa protectora visual. Frente a ti solo queda un cursor parpadeante y un archivo de plan que has escrito tú mismo. No hay subrayados rojos marcando errores, ni ventanas emergentes de autocompletado, ni árbol de archivos. Matt Van Horn usó el término "No IDE" en su tuit, cuyo significado real no es rechazar todas las herramientas gráficas, sino cambiar la lógica de control del desarrollo de "confirmar manualmente línea por línea" a "delegar y ejecutar por lotes".
Boris Cherny es el responsable de Claude Code. Entre finales de 2025 y principios de 2026, compartió su propio método de uso de Claude Code a través de Threads y otros canales. Su enfoque prioriza la CLI, utilizando el modo de planificación como punto de partida para todas las tareas. Esto presenta una diferencia fundamental con la mentalidad del IDE: en el IDE tradicional, la persona es el productor activo de código y la IA solo asiste; en el flujo de trabajo dirigido por planificación en la terminal, la persona establece la dirección y valida, mientras que la generación del código y la ruta de implementación las elige el Agente de forma autónoma.
Abandonar el IDE implica perder la sensación de seguridad de "escribir cada línea de código con tus propias manos". Suena como una pérdida, pero para desarrolladores que ya han experimentado numerosos cambios de contexto en proyectos grandes, también es una descarga. Porque ya no necesitas saltar constantemente entre leer código, escribirlo, buscar documentación y cambiar de archivo. Solo necesitas explicar claramente un requisito y luego dejar el proceso de ejecución en manos de un conjunto de Agentes que funcionan en paralelo.
El marco que meng shao propone en su resumen es "la persona lidera la dirección, los agentes ejecutan". En la era del IDE, la persona debía tanto liderar la dirección como ejecutar los detalles; ambos roles estaban entrelazados. El nuevo flujo de trabajo intenta separar estos dos roles, dejando a la persona solo la primera parte.
plan.md no es un documento, es un contrato
El nombre de archivo que más aparece en este flujo de trabajo es plan.md. Suena a documentación del proyecto, pero su función es completamente diferente.
El README o la documentación de desarrollo de un proyecto son para que los humanos los lean; sirven para explicar decisiones de arquitectura, registrar acuerdos de interfaz y ayudar a los nuevos miembros a empezar. El lector principal de plan.md no es un humano, es un Agente. Su estructura se organiza en torno a tres elementos: definición del problema, descripción de la solución y una lista de verificación en forma de casillas (Checkbox). meng shao lo expresó claramente en su tuit: la función de plan.md es "obligar al agente a no ser vago".
Los LLM tienen un problema conocido en conversaciones largas, que la comunidad denomina "corrupción del contexto". A medida que el historial de la conversación se alarga, la atención del modelo hacia los objetivos iniciales decae naturalmente. Puede olvidar los límites de la necesidad original a mitad de camino, o saltarse pasos de verificación por pereza. Un proyecto comunitario llamado "洁癖.skill" (Hábito de limpieza) se enfoca específicamente en este problema, proporcionando métodos para organizar automáticamente archivos de sesión y actualizar bibliotecas de memoria persistentes. Su premisa central es que el rendimiento a largo plazo de un Agente no depende de la calidad de un único Prompt, sino de si cuenta con un mecanismo de memoria externa estable.
plan.md es esa memoria externa. Reside en el sistema de archivos y no desaparece al finalizar la sesión. Cada nueva sesión de Agente puede recargar el contexto desde este archivo, en lugar de depender del registro de chat ya desvanecido de la conversación anterior.
Compound Engineering es el complemento principal de código abierto que sustenta este flujo de trabajo, desarrollado por Kieran Klaassen de Every Inc. Proporciona un conjunto de comandos de terminal, entre los cuales /ce:plan puede generar automáticamente un borrador de plan.md basado en la entrada del desarrollador. Después de generarlo, el trabajo del desarrollador es revisar y corregir: el Agente podría tener suposiciones erróneas sobre la selección tecnológica, subestimar la complejidad de un módulo o malinterpretar completamente la lógica del negocio. La intervención humana en este punto no es ajustar el código, sino inyectar en el archivo de planificación el conocimiento del dominio que el Agente desconoce, y luego devolver el plan corregido al Agente para su ejecución.
Este diseño es muy consistente con un punto que Boris Cherny enfatiza en sus principios de uso de Claude Code: concentrar el juicio del experto humano en el único nodo de revisión del plan, y no distribuirlo en cada paso de la ejecución. En sus palabras, si en cada paso hay que supervisar y confirmar, eso no es diferente de escribir el código manualmente.
Un plan.md efectivo no suele ser largo. Normalmente contiene criterios de aceptación claros, cada uno de los cuales puede corresponder a una casilla de verificación (Checkbox). Estas casillas son puntos de anclaje de ejecución para el Agente y también criterios de validación para la persona. Una vez completada la fase de Trabajo, el desarrollador no lee el código, sino que verifica si estas casillas de verificación han sido marcadas una por una.
Las tres formas de un requisito: Investigar → Planificar → Trabajar
El esqueleto central de este flujo de trabajo es un ciclo cerrado compuesto por tres fases: Investigar, Planificar, Trabajar. No es complejo, pero cada fase tiene una división clara en cuanto al soporte de herramientas y la forma de intervención humana.
El objetivo de la fase de Investigación es que el Agente establezca una ventaja informativa antes de actuar. Una forma común es usar el comando /ce:brainstorm o cargar paquetes de habilidades de Investigación específicos. Matt Van Horn hizo público una habilidad llamada last30days-skill, cuyo número de estrellas en GitHub superó las 10,000 a finales de marzo de 2026. Su función es permitir que el Agente capture en paralelo contenidos relacionados con un tema específico de los últimos 30 días en comunidades como Reddit, X y Hacker News, y luego genere un resumen de análisis estructurado. Supongamos que inicias un proyecto que involucra una nueva pila tecnológica; tu Agente puede, en minutos, obtener las últimas valoraciones, los problemas conocidos y las alternativas recomendadas sobre esa pila tecnológica en la comunidad, en lugar de obligarte a abrir manualmente una docena de pestañas en el navegador.
El resultado de la Investigación no es la respuesta final, sino la información de entrada. Esta información pasa a la fase de Planificación, convirtiéndose en material para generar plan.md.
La fase de Planificación utiliza el comando /ce:plan. Basándose en los hallazgos de la fase de Investigación, los requisitos iniciales proporcionados por el desarrollador y el contexto del código existente del proyecto, el Agente genera un borrador de plan.md. La filosofía de diseño de Compound Engineering es dedicar el 80% del tiempo a la planificación y revisión, y el 20% a la ejecución. Esta proporción parece muy agresiva a primera vista, pero su lógica es directa: un plan escrito con claridad, con límites bien definidos y criterios de aceptación específicos, puede reducir al mínimo el costo de re-trabajo durante la fase de ejecución.
Lo que el desarrollador debe hacer en la fase de Planificación incluye: corregir las suposiciones erróneas del Agente sobre la solución técnica, complementar las restricciones empresariales que el Agente desconoce, ajustar el nivel de desglose de tareas y el orden de ejecución, y añadir a las casillas de verificación los casos extremos que el Agente tiende a omitir. Este proceso de revisión en sí mismo también es una "inyección de memoria externa", porque en este momento la persona escribe en el archivo de planificación ese conocimiento implícito que es difícil de expresar naturalmente en una conversación.
La fase de Trabajo utiliza el comando /ce:work. El Agente lee plan.md, desglosa las tareas en subtareas y las asigna a subagentes para su ejecución en paralelo. Boris Cherny compartió una vez un dato: usando este flujo de trabajo impulsado por planificación, generó 259 PR en un mes. Este número no habla de la calidad del código, sino de que, cuando la capacidad de decisión en la fase de ejecución se delega al Agente, el cuello de botella humano ya no está en la velocidad de escritura.
Hay un punto clave que a menudo se pasa por alto entre las tres fases: las fases de Investigación y Planificación pueden repetirse varias veces. Si el Agente revela lagunas de información durante la Planificación, se puede volver al modo de Investigación en cualquier momento para complementar. Si se descubre un error en el plan una vez iniciada la fase de Trabajo, también se puede volver a la fase de Planificación para corregirlo. Este ciclo no es un flujo lineal en cascada, es un bucle que permite retrocesos y ajustes.
Seis técnicas que puedes probar ahora mismo
De la información públicamente disponible hasta la fecha, las siguientes seis técnicas tienen una procedencia clara y detalles suficientes para que un desarrollador pueda probarlas directamente. No son principios abstractos, sino operaciones concretas que llegan a "qué escribir en la terminal", "qué poner en el archivo" y "qué herramienta usar".
Técnica 1: Genera un plan en cuanto tengas una idea, no intentes deducir todo mentalmente primero.
meng shao colocó este punto en un lugar muy destacado en su publicación original. Su lógica es que el cerebro humano es bueno revisando, pero no construyendo de la nada la estructura arbórea completa de una lógica compleja. Al recibir un nuevo requisito, los desarrolladores suelen reflexionar repetidamente sobre la ruta de implementación en su mente, pero este proceso es muy ineficiente debido a la capacidad limitada de la memoria de trabajo. La forma correcta es hacer que el Agente genere la primera versión del plan en cuanto aparezca la idea, aunque sea tosca, errónea y necesite muchas correcciones. Revisar un plan con problemas es mucho más fácil que escribir un plan perfecto desde cero.
Técnica 2: No leas tú el plan, haz que el Agente lo resuma en unas pocas frases.
Leer un archivo de planificación largo es en sí mismo un elemento con costo. Uno de los 22 consejos de Boris Cherny es usar comandos en lenguaje natural para que el Agente proporcione un TLDR (demasiado largo; no leí), o usar "eli5" (explícamelo como si tuviera 5 años) para que explique los puntos clave del plan de la manera más sencilla. Si tienes 5 minutos para revisar, dedica los primeros 3 al resumen del Agente y los últimos 2 a comprobar solo las partes que consideres de riesgo. La esencia de esta técnica es delegar también la "comprensión lectora"; la persona solo ve lo que debe ver.
Técnica 3: Paraleliza en múltiples terminales.
Matt Van Horn mencionó en su tuit que solía abrir 4 o más ventanas de terminal simultáneamente, para que diferentes instancias de Agente manejaran distintas subtareas. Una trabajando en la interfaz frontal, otra escribiendo la API del backend, otra ejecutando pruebas, otra extrayendo documentación. Esta práctica convierte el desarrollo tradicional de un solo hilo en una programación multihilo. El costo es que necesitas gestionar tú mismo la salida y el estado de las diferentes terminales; no hay un escritorio gráfico que las unifique y supervise. Para los desarrolladores acostumbrados a tener el control global en una sola ventana de IDE, al principio habrá ansiedad por "no saber en qué parte ha fallado".
Técnica 4: Usa voz en lugar del teclado para instrucciones de arquitectura complejas.
meng shao menciona el uso de herramientas de voz como monologue para la entrada. El procedimiento concreto es: frente a una línea de pensamiento sobre diseño de sistemas que requiera una descripción larga, en lugar de escribir línea por línea con el teclado, se expresa todo el pensamiento en voz alta, y se deja que la herramienta de conversión de voz a texto vierta el contenido en la terminal o en el archivo de planificación. Matt Van Horn llama a esto "Get Voice-Pilled" (Vuélvete adicto a la voz). Cree que la voz mantiene la coherencia del pensamiento arquitectónico complejo más fácilmente que la escritura, porque el ritmo del habla y el flujo lógico natural se ajustan mejor. La efectividad real de esta técnica para desarrolladores de habla hispana aún carece de suficiente retroalimentación, y la capacidad de soporte de voz en español de herramientas como monologue también está por confirmarse más a fondo.
Técnica 5: Dispara tareas asíncronas por correo electrónico.
Matt Van Horn compartió una escena concreta en un tuit de abril de 2026: mientras acostaba a su hijo, envió un correo a su instancia de Claude Code a través de la herramienta agentmail, disparando una tarea remota de construcción de código. Cuando el niño se durmió, la construcción ya había terminado y los resultados estaban esperando su validación en la terminal. Esto libera esencialmente el acto de desarrollo de la restricción física de "tener que sentarse frente al ordenador", permitiendo que el Agente trabaje continuamente en segundo plano. El requisito previo es que tu nivel de confianza en el Agente sea lo suficientemente alto como para permitirle ejecutar de forma autónoma sin ver la pantalla.
Técnica 6: Usa el conjunto de herramientas como un mercado de habilidades.
Proyectos como AgentSkills ofrecen una idea central: los desarrolladores no necesitan construir desde cero cada capacidad del Agente. Habilidades genéricas como gestión de archivos, monitoreo de noticias o extracción web ya tienen paquetes de habilidades mantenidos por la comunidad que se pueden cargar. En el flujo de trabajo de terminal, la operación de cargar una nueva habilidad es similar a instalar un complemento; solo necesitas declarar en la configuración el origen y los parámetros del paquete de habilidades, y el Agente podrá adquirir automáticamente la capacidad de invocar la herramienta correspondiente. Como ejemplo de práctica comunitaria, Claude Code Video Toolkit añade capacidad de comprensión de contenido de video al entorno CLI, aunque su ámbito de aplicación aún es bastante específico, muestra que los límites de capacidad de los Agentes en terminal se pueden ampliar continuamente mediante paquetes de habilidades.
Cuándo este flujo puede volverse en tu contra
Las voces críticas hacia este flujo de trabajo no son pocas. Sintetizando los debates de la comunidad, los problemas se centran principalmente en tres direcciones.
El primer problema es el límite de la audiencia a la que se aplica. Los 22 consejos de Boris Cherny tienen una premisa implícita: el usuario necesita tener suficiente capacidad de desglose arquitectónico y de restricción mediante Prompt. Quien puede completar de forma independiente el diseño de un sistema sabe cuáles son los límites de "qué debe hacer el Agente y qué no". Para los desarrolladores que aún necesitan las sugerencias de error, el resaltado de sintaxis y la depuración con puntos de ruptión del IDE para entender la lógica del código, cerrar el editor gráfico equivale a cerrar los canales de obtención de información que les son familiares. Esto no es una cuestión de mayor o menor habilidad, sino de la dependencia de diferentes canales sensoriales en la forma de trabajo. Los desarrolladores novatos construyen su modelo mental del proceso de ejecución del programa depurando línea por línea, y este proceso de aprendizaje carece de una alternativa en el flujo de trabajo de terminal.
El segundo problema es la concentración del riesgo. En el IDE tradicional, los errores se exponen gradualmente durante la ejecución: errores de compilación, incompatibilidad de tipos, excepciones en tiempo de ejecución. La persona tiene la oportunidad de descubrir y corregir problemas en cada etapa. En el flujo de trabajo dirigido por planificación, toda la revisión de decisiones se comprime en un solo nodo: la fase de Planificación. Si la revisión humana en este nodo no es lo suficientemente exhaustiva, los errores serán amplificados de manera fiel y eficiente por el Agente durante la fase de Trabajo. Cuando te des cuenta, puede que varios archivos ya estén contaminados por lógica errónea.
El tercer problema lo mencionó el propio Matt Van Horn, quien lo llamó "Psicosis de la IA". Este término no se refiere a que la IA tenga un problema, sino a que la persona lo tiene: construir ciclos de Agente en sí mismo genera una intensa gratificación intelectual, similar a la retroalimentación positiva de optimización continua en un juego de estrategia. El desarrollador puede obsesionarse con pulir el propio flujo de trabajo del Agente, probando constantemente nuevas técnicas, añadiendo nuevos subagentes, optimizando la estructura del Plan, y olvidando una pregunta básica: ¿qué valor estás realmente entregando al usuario? La herramienta se convierte en el fin, y el requisito pasa a un segundo plano.
Estos tres problemas apuntan a la misma conclusión: el flujo de trabajo de terminal impulsado por plan.md es un amplificador de eficiencia diseñado para personas que "saben claramente lo que quieren", no es una herramienta de aprendizaje para quienes "aún están explorando qué deberían hacer". Su límite de aplicabilidad no está en la elección de la pila tecnológica, sino en la etapa del usuario. Si eres de los que ya ha dibujado en papel la arquitectura completa de un sistema, este flujo de trabajo puede multiplicar por diez tu velocidad de ejecución. Si aún estás comprendiendo el problema en sí mismo a través de la escritura manual de código, entonces el sistema de retroalimentación visual del IDE es la muleta que no deberías soltar por ahora.
Actualmente, los componentes centrales de este flujo de trabajo incluyen Claude Code CLI o Codex CLI en la capa de entorno de ejecución, el complemento Compound Engineering en la capa de gestión de procesos, y proyectos como last30days-skill y agentmail en la capa de extensión de habilidades. Todos están en rápida iteración, y es posible que cambien los formatos de comando, las convenciones de archivos y los sistemas de complementos. Los desarrolladores que se unan ahora deben aceptar un hecho: los problemas que encuentres pueden no tener aún respuesta en la comunidad, porque toda la cadena todavía se encuentra en una etapa de prácticas tempranas, lejos de alcanzar el estándar de una "cadena de herramientas estable". Pero precisamente esta es también la ventana de oportunidad en la que quienes abren camino primero pueden establecer una ventaja cognitiva.
