Dirigir coding agents, no escribir código

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.

El code review. Cada línea que el agent escribe es una línea que leo. Bloqueo cambios con los que no estoy de acuerdo de la misma forma en que bloquearía el PR de un ingeniero junior. El agent es rápido pero no infalible — se salta assertions, sobrecomplica el control flow, de vez en cuando inventa llamadas a APIs. Esas las atrapás leyendo.

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 revisar código 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.