# Dirigir coding agents, no escribir código Una nota breve sobre qué cambia cuando la capa de implementación es un agent — qué permanece igual, qué desaparece y dónde vive el nuevo cuello de botella. - **Author:** Fedor Chishchin - **Published:** 2026-05-15 - **Updated:** 2026-10-16 - **Tags:** agents, methodology, ai-native - **Source:** https://fedorthinks.com/es/blog/directing-not-typing --- Ya no escribo el código. Dirijo coding agents — actualmente Claude Code sobre Opus — y soy dueño de la arquitectura, el spec, el review. Esto es lo que cambia en la práctica. ## Lo que desaparece **Las pulsaciones de teclado.** El día de un ingeniero senior solía ser 30% leer código, 20% escribir código, 50% todo lo demás. La línea de escribir-código baja a algo así como 5% — parches a mano para cosas que el agent todavía no puede alcanzar, o para cambios demasiado pequeños como para que valga la pena un prompt. **La fatiga del boilerplate.** Un nuevo endpoint con auth, validación, tests y una migración solía ser una tarea de dos horas. Ahora es un prompt de cinco minutos y un review de diez. El costo mental de "debería escribir un test para este edge case" desaparece — claro que hay un test, lo escribió el agent. **El IDE.** Estoy en una herramienta con forma de terminal más de la mitad del tiempo. El IDE aparece cuando necesito leer algo sobre lo que el agent razonó pero no me mostró, o cuando estoy revisando el diff antes del merge. Si no, el loop es prompt → diff → comentario → siguiente. ## Lo que permanece exactamente igual **La arquitectura.** Qué debería construirse, dónde están los límites, cuál es el modelo de datos, cuáles son los failure modes. Nada de eso se delega. Un coding agent construirá con gusto lo que sea que describas. Todo el trabajo está en describir lo correcto. **La verificación.** No leo cada línea que escribe el agent — eso no escala, y no es ahí donde se atrapan los errores. Demuestro que el código funciona: tests unitarios, de integración y end-to-end que el agent tiene que mantener en verde, controles estrictos (tipos, lint, cobertura) en cada commit, y logs y trazas en producción. El agent es rápido pero no infalible — se salta assertions, sobrecomplica el control flow, de vez en cuando inventa llamadas a APIs. Los tests y los controles atrapan eso siempre, sin cansarse. **El criterio de producción.** El instinto de que cierta abstracción va a tener fugas, de que cierto índice va a desaparecer, de que cierto límite async va a generar deadlock bajo carga — nada de eso está en los datos de entrenamiento de ningún agent. Está en veinte años de arreglar cosas. ## Hacia dónde se mueve el cuello de botella El nuevo cuello de botella es la **calidad de la especificación**. Si escribo un prompt que es ambiguo respecto a un error path, el agent se compromete con una interpretación y la lleva a producción. Si escribo un prompt que es completo pero mal priorizado, el agent acierta en lo equivocado. Ambos parecen fallas del agent desde afuera; ambos son fallas del spec. La disciplina que solía ir a "escribir código correcto" ahora va a "escribir especificaciones correctas y demostrar que el código es correcto". El producto del _tiempo invertido_ y la _densidad de pensamiento_ se conserva más o menos — solo se mueve más temprano en el pipeline. El trabajo me resulta más interesante. Leo más, escribo más prosa, reescribo el mismo párrafo tres veces antes de enviárselo al agent, y termino el día habiendo entregado aproximadamente cinco veces más de lo que entregaba hace dos años. El tradeoff es bueno.