0. La mente entre el humano y la AI — Trabajar con un proceso sin deseo

Lo que pienso de la AI es que se trata de un proceso con un cerebro muy capaz pero al que le falta conocimiento del dominio — como una persona sin deseo. Debido a eso, para usar la AI con el fin de realizar el trabajo que quiero hacer, lo importante es transmitir a la AI exactamente lo que quiero. Por el hecho de que una o dos ideas se presenten de forma abstracta, al modo en que lo haría una persona, la AI no piensa como una persona y no llevará el trabajo adelante en la forma que la persona espera.

La trampa más fácil en la que puede caer alguien que usa AI es justamente este punto. La AI posee un cerebro extraordinariamente capaz para el cómputo y el razonamiento, pero si no se le entregan los valores de entrada exactos y la meta, puede producir resultados distintos a la intención del operador. Esta brecha existe porque los datos con los que la AI arranca su cómputo y razonamiento son diferentes a las expectativas que el operador sostiene en su cabeza. Por lo tanto, para obtener los resultados que el operador quiere a través de la AI, lo más importante es entender bien los principios de funcionamiento de la AI, y asegurarse de que los pensamientos del operador queden escritos y se trasladen a la AI sin omisiones. Una descripción tan detallada que uno casi se pregunta "¿de verdad tengo que explicar y definir incluso esto?" es la única buena manera de evitar que la AI se desvíe del rumbo.

Por esta razón, al principio hubo muchas charlas sobre técnicas y métodos de prompting. Inicialmente toda la conversación era prosa. Originalmente la única palanca que tenía el operador era el siguiente prompt. Después, procesos automatizados como skills y hooks ganaron popularidad como forma de reducir la brecha entre la AI y las personas. Más tarde, el enfoque de controlar el camino con un harness — evitando que la AI se salga del carril previsto — ganó terreno. Todas estas distintas maneras de usar la AI de manera eficiente son, al final, lo que se necesita para eliminar la ambigüedad dentro de una memoria limitada expresando lo que el operador quiere con la mayor exactitud posible, y para fijar el objetivo con precisión.

Las cuatro capas acumuladas

Lo que creo que el campo ha estado haciendo realmente durante los últimos años es acumular capas — no reemplazarlas. Cada capa deja en su sitio a las anteriores y añade una palanca más para que el operador exprese su intención:

1. Persona — un único system prompt que fija el rol, el tono y los valores por defecto del colaborador. Tratado en Part 2 — Persona design.
2. Skills y slash commands — nombrar los procedimientos recurrentes para que el operador pueda invocarlos por vocabulario en lugar de por párrafos. Tratado en Part 4 — Skills and slash commands.
3. Hooks — los mismos procedimientos, pero auto-disparados por el sistema en el momento adecuado, de modo que el operador no tenga que acordarse. Tratado en Part 5 — Hooks and automation.
4. Harness — los rieles de ejecución que mantienen a la AI sobre el camino previsto incluso cuando el operador no está mirando. Loops de verificación, gates de release, el Ralph loop.

No es porque la capa nueva vuelva obsoleta a la antigua, sino más bien porque cada capa atiende un modo de fallo distinto de la misma brecha. El prompting sigue ocurriendo dentro de una persona. Los skills siguen invocándose mediante prompts. Los hooks invocan skills. El harness dispara hooks. La pila es acumulativa.

Cómo se ve "trasladarlo todo sin omisiones" en la práctica

Un ejemplo concreto, sobre qué es /verify en realidad. Es un skill que ejecuta un loop de verificación de siete pasos justo antes de reportar "hecho" — lint, build, type check, test, security, diff check, sanity check del reporte. El operador puede invocarlo explícitamente como slash command, o un hook puede auto-dispararlo justo antes de que el asistente emita la palabra "hecho". El mismo procedimiento, dos rutas de entrada. Tratado en Part 7 — Verification loops.

Sin ese hook, la brecha aparece justo donde uno la esperaría: el asistente reporta "hecho" mientras el build está roto, ya que reportar hecho y correr el build son dos acciones diferentes y la mente del operador ("hecho significa que los tests también pasan") nunca se escribió. Con el hook, el procedimiento se dispara recuerde el asistente o no. La intención del operador — "hecho significa verificado" — ha salido de su cabeza y entrado en una pieza de maquinaria que se ejecuta sin él.

Loading diagram…

El mind mismo sigue cambiando

No importa cuánto avance la AI ni cuánto mejore su rendimiento, creo que será difícil que la AI anticipe la intención del operador por adelantado y produzca resultados con los que el operador quede satisfecho. Eso se debe a que los deseos, la satisfacción y los objetivos del operador no dejan de cambiar. Por la mañana uno puede querer ver el mar, pero por la tarde puede querer ver las montañas.

Porque la mente es un blanco móvil, la disciplina no puede ser predecir al operador. Tiene que ser hacer barato leer el estado actual del operador. Por eso el PRD se trata como una única fuente de verdad — no como una spec única, sino más bien como un enunciado vivo que el operador actualiza cada vez que el destino cambia. Tratado en Part 10 — PRD as single source.

Lo que el PRD hace por el destino, la persona y los skills lo hacen por el método. Dicho de otro modo, lo que la persona es para Alice se decide en ese mismo lugar. El operador actualiza la persona cuando se da cuenta de que "en realidad, prefiero updates de estado escuetos en lugar de los verbosos". Esa actualización queda visible para toda sesión futura — la mente se trasladó, en un lugar donde la siguiente sesión la puede encontrar.

Por qué esto importa más para un desarrollador senior

Para un desarrollador como yo, que lleva mucho tiempo trabajando como desarrollador de software, la tecnología de AI de hoy es extraordinariamente atractiva. Eso es porque, desde la posición de haber gestionado comercialmente muchísimos diseños y arquitecturas, uno puede trazar el gran cuadro y delegar los elementos necesarios a la AI para construir el sistema deseado en poco tiempo. Lo que antes había que explicar a cada desarrollador — con el trabajo dividido, los resultados combinados y el sistema puesto a funcionar — ahora puede ejecutarlo en gran parte un AI Agent. Pienso que el cambio no es que la AI reemplace a los desarrolladores, sino más bien que un desarrollador senior con un modelo mental claro hoy puede entregar un sistema pulido con un equipo muy pequeño, ya que el costo de transmisión de la intención se ha desplomado.

Si uno compone bien el PRD y el TRD, construye el diseño, descompone el plan concreto de implementación a lo largo de él en unidades muy pequeñas, pone gates en cada componente y deja que un gate de release comercial haga la verificación final, se ha vuelto posible desarrollar un sistema bastante pulido con un equipo pequeño.

Hacia dónde sigue esta serie

El resto de esta categoría recorre cada capa acumulada de una en una, empezando por la razón por la que le di un nombre al colaborador. La siguiente parte — Part 1 — Why Alice — es la versión personal: dónde dejó de funcionar usar Claude como herramienta, y cómo persona, memoria, skills, hooks y gates de verificación se acumularon hasta formar un compañero diario que ahora llamo Alice.