♟️ Táctico × Estratégico

Antes de hablar de IA, necesitamos una regla de referencia. Matt Pocock la toma prestada de John Ousterhout, profesor de Stanford y autor de "A Philosophy of Software Design". En el libro, separa el trabajo de programar en dos modos muy diferentes: programación táctica e programación estratégica. No son «niveles de habilidad», son maneras de pensar sobre lo que estás haciendo ahora.

La diferencia, en la imagen del propio Pocock: el táctico es «ganar la batalla»: el día a día de escribir sintaxis, encontrar bugs, hacer commits. O estratégico es «ganar la guerra»: es el general en la parte superior pensando en cómo debe ser el codebase y qué estrategias aumentan la velocidad a largo plazo. El porqué de que esto se haya vuelto tema ahora: la IA cambió radicalmente quién hace cada modo. Un error común es tratar ambas cosas como si fueran lo mismo ("todo es programar"): requieren enfoques distintos.

A programación táctica es el trabajo que tú ve ocurriendo: abrir el editor y escribir las líneas, recordar dónde va el paréntesis, ejecutar el programa, ver que falla, buscar el bug, corregirlo y guardar con un commit. Es el «piso de fábrica» del software. Durante décadas, fue aquí que la mayoría de los programadores pasaba el 80% del tiempo, y aquí se medía "quién programa bien".

Es un trabajo honesto e indispensable: sin lo táctico, nada funciona. Pero tiene una característica peligrosa: es mecánico y estandarizable. Casi todas las tareas tácticas ya fueron realizadas millones de veces por alguien: crear un endpoint, validar un formulario, escribir un bucle. Por eso porqué importa: todo lo que es repetible y está bien definido es exactamente el tipo de cosa que las máquinas aprenden a hacer. El error común es confundir «estoy ocupado escribiendo» con «estoy creando valor»: escribir mucho puede ocultar que tomas pocas decisiones.

A programación estratégica es lo opuesto a «está escribiendo». Es pensar antes e alrededor del código: cómo el codebase debe estar estructurado, cuáles interfaces conectan las partes, qué decisiones de hoy acelerarán (o frenarán) al equipo dentro de un año. En palabras de Pocock, es "ganar la guerra, no la batalla": el trabajo de general en la parte superior.

Para Ousterhout, lo estratégico implica dibujar las partes difíciles antes, definir bien el alcance de cada tarea, pensar en las interfaces entre módulos, planificar pruebas y escenarios, y diseñar un codebase fácil de trabajar. El porqué de que esto sea poco común: puedes «entregar» sin hacer nada de esto; basta con enviar código táctico que funciona hoy. El precio llega después, en forma de deuda técnica. O error común es posponer lo estratégico «para cuando tengas tiempo»: ese momento nunca llega y el codebase se deteriora.

Aquí está la frase que da nombre al módulo. Matt Pocock es directo: "AI has basically eaten tactical programming. It's gone." — básicamente, la IA "se comió" la programación táctica, se acabó. No en el sentido de que lo táctico ya no exista, sino en el sentido de que ya no es donde está tu valor: la IA se encarga de lo táctico mejor y más barato que tú. ¿Recuerdas el tema 2? Lo táctico es repetible y está bien definido — y es exactamente en eso en lo que un modelo de lenguaje brilla.

La consecuencia práctica es contundente: ahora tienes acceso a una "flota infinita de programadores tácticos" que trabajan 24h, no se cansan y cuestan centavos. Pero —y aquí está el punto— una flota solo vale lo que vale quien la dirige. El porqué de que esto te impulse a avanzar: si lo táctico se volvió barato y abundante, el cuello de botella pasó a ser el estratégico. O error común es seguir compitiendo en lo táctico («voy a escribir más rápido que la IA»): es una carrera que pierdes contra alguien que no duerme.

Si lo táctico ya se absorbió, la jugada es subir de nivel: empezar a operar en el plano estratégico. Pocock deja claro que "la programación estratégica no cambió con la IA" — los fundamentos para diseñar bien un sistema siguen siendo los mismos de siempre. Lo que cambió fue para quien delegas lo táctico: antes les pasabas las tareas mecánicas a juniors y mid-levels; ahora tú delega para la IA. El porqué de que esto sea liberador: pasas menos tiempo escribiendo y más tiempo decidiendo, que es donde se forma el resultado real. El error común es «subir de nivel» solo en la tarjeta de presentación (convertirte en «líder») sin soltar nunca lo táctico en la práctica; así te conviertes en un cuello de botella que revisa cada línea. Subir de verdad es confiar la ejecución y enfocarte en el diseño.

Al cerrar el módulo: la metáfora del general en la parte superior es el resumen de todo. La IA es tu tropa táctica; tú eres el general estratégico. Para delegar bien a esta tropa —el tema de toda la Trilha 2—, Pocock presenta la lista de Ousterhout: dibujar las partes difíciles primero, definir muy bien el alcance de las tareas, pensar en las interfaces entre módulos, pensar en pruebas y escenarios, y tener documentación suficiente para orientar a la IA hacia los lugares correctos. Antes de «dejar que la IA programe», ejecuta la lista de verificación de abajo: es el resumen práctico de este módulo. Cópiala y pégala cuando delegues una tarea:

Antes de mandar a IA codar, pense como GENERAL (estratégico):
[ ] PARTES DIFÍCEIS — qual é o pedaço arriscado? Desenhei ele na frente?
[ ] ESCOPO — a tarefa está nítida e fechada, ou está vaga demais?
[ ] INTERFACES — como este módulo conversa com os outros? Defini o contrato?
[ ] TESTES — quais cenários provam que ficou certo (inclusive os de borda)?
[ ] DOCUMENTAÇÃO — apontei a IA pros arquivos/padrões certos do projeto?
Se respondeu tudo, o tático (a IA) é só execução. Você ganhou a guerra.