🤝 DX × AX

Ya conoces DX (Developer Experience): todo lo que hace que el proyecto sea agradable para un humano programar — nombres claros, scripts listos, mensajes de error legibles. Matt Pocock presenta a su hermano: AX, de Agent Experience — literalmente, "la experiencia que el agente tiene en el codebase". Es la misma pregunta, solo que hecha desde el punto de vista de la IA: cuando el agente entra en tu proyecto, ¿se orienta? ¿Entiende qué hace cada cosa? ¿Puede hacer cambios sin romper otras tres cosas?

¿Por qué esto importa y por qué ahora? Porque el agente pasó a ser un «colaborador» que trabaja en tu codebase de verdad: lee archivos, ejecuta comandos y edita código. Si el codebase es un laberinto, el agente se pierde igual que una persona, solo que "se pierde" gastando tokens, probando, equivocándose, volviendo a leer. Una buena AX no es un detalle estético: es lo que hace que el agente acierte a la primera y cueste poco. El error común aquí es tratar AX como «algo de IA, separado de mi trabajo de desarrollo»; cuando, como veremos, es casi el mismo trabajo.

Aquí está el corazón del módulo y la frase exacta de Pocock: "Huge overlap between good DX and good AX" — hay una superposición enorme entre una buena experiencia de desarrollo y una buena experiencia de agente. ¿Por qué? Porque ambas chocan con los mismos obstáculos. Un nombre de variable confuso confunde al humano e el agente. Una prueba que falla pronto protege a ambos. Una carpeta organizada permite que ambos encuentren lo que necesitan. No son dos trabajos separados: es casi el mismo trabajo rindiendo el doble.

Pocock enumera lo que mejora el resultado de la IA: mejores skills, un modelo más potente, mejor harness y mejorar el codebase, que él llama «el que más se suele olvidar». Y concluye: "un buen senior sabe construir una DX que se convierte en AX". Es decir: las habilidades que te convierten en un buen ingeniero para las personas son exactamente las que hacen que tu codebase sea bueno para los agentes. El error común es imaginar que la IA exige un conjunto de prácticas exótico y nuevo; casi siempre, basta con cuidar lo básico que ya deberías hacer. Un detalle honesto: el overlap es enorme, no al 100 % — hay ajustes solo para agentes (por ejemplo, un archivo de instrucciones que lee el agente), pero la base es compartida.

Dos palancas concretas de AX. La primera son los guard rails (barreras de protección): tipos, pruebas automatizadas, linter, validaciones. Transforman un error silencioso (que solo aparece tres pasos después) en un error ruidoso e inmediato. Pocock relaciona esto directamente con el costo: con guard rails, el modelo se equivoca menos y gasta "fewer tokens banging its head against the wall" — menos tokens golpeándose contra la pared. Sin ellos, la IA lo intenta, rompe algo en otro lugar, lo descubre tarde y vuelve a hacerlo todo — caro y lento.

La segunda palanca es la navegabilidad: el agente necesita encontrar las cosas. Carpetas con nombres que indican qué contienen, archivos en el lugar previsto, módulos con límites claros. Un codebase navegable es un mapa; uno desordenado es un laberinto. Y fíjate: las dos palancas sirven tanto a las personas como a los agentes; es el overlap del tema 2 en acción. El error común es desactivar los guard rails «para ir más rápido»: cambias una advertencia barata e inmediata por un bug costoso y tardío.

La documentación forma parte del AX, pero tiene que ser del tipo adecuado. No es un texto largo y genérico que nadie lee: es documentación que señala el camino. Piensa en tres cosas: (1) un archivo de entrada que diga «este proyecto hace X, empieza por aquí, ejecuta tal comando»; (2) notas que conectan las partes ("si cambias esto, revisa también aquello"); y (3) ejemplos de "cómo hacemos las cosas aquí" (el estándar del proyecto). Para el agente, esto vale oro: ahorra decenas de lecturas de prueba y error.

Y, de nuevo, el solapamiento: el mismo letrero que orienta al agente orienta a la persona nueva del equipo. La regla de oro es documentar el camino, no todo — una flecha en el lugar correcto vale más que mil páginas. El error común tiene dos caras: o cero documentos (el agente adivina y se equivoca con el estándar), o documentos demasiado (el agente — y el humano — se ahoga y el texto queda desactualizado, convirtiéndose en una trampa que apunta al lugar equivocado). El objetivo es el punto medio: pocas flechas, precisas y actualizadas.

Vuelve al módulo 1.1: el harness son cuatro cosas: prompts, skills, entorno y codebase. Pocock destaca que el codebase es la pieza «que se olvida con más frecuencia» cuando se quiere mejorar el resultado de la IA. La gente afina el prompt y busca skills, pero deja desordenado el terreno. Mejorar el codebase é mejorar el entorno donde vive el agente —y, como vimos en el glosario, un entorno confuso = más tokens chocando entre sí, es decir, más costo y más errores.

Aquí está el puente al resto de la Trilha 1, en las palabras exactas de Pocock: "Have a codebase that's easier to make changes in → you can employ a stupider/cheaper model to do the same work". En otras palabras: una base de código fácil de modificar permite usar un modelo más barato para el mismo trabajo, porque los guard rails ahorran intentos. Y lo contrario: "Hamstring your model from day one → you need a smart model" — si saboteas la IA con un codebase deficiente desde el primer día, necesitarás (y pagarás) un modelo caro solo para compensarlo. Este es precisamente el tema del próximo módulo, 1.5 — Economía de tokens. El error común: tratar «refactorizar el codebase» como un lujo opcional; en realidad, es la forma más económica de reducir costos que tienes.

Para cerrar: ¿cómo saber si tu AX es buena? No por intuición, sino por señales observables en el trabajo del agente. ¿Acertó a la primera o tuvo que rehacerlo varias veces? ¿Encontró rápido el archivo correcto o leyó medio proyecto? ¿Rompió otra cosa o los guard rails lo impidieron? ¿Gastó pocos o muchos tokens? Cada vez que vayas a «mejorar la IA», tradúcelo como «mejorar la AX» — y usa la lista de verificación de abajo para diagnosticar. Copia y pega cuando el agente se atasque en tu proyecto:

O agente patinou no projeto? Antes de trocar de modelo, cheque a AX:
[ ] NAVEGABILIDADE — pastas/nomes dizem o que contêm? O caminho é óbvio?
[ ] GUARD RAILS — tem tipos + testes + linter avisando o erro CEDO?
[ ] DOCS QUE APONTAM — há "comece aqui", o padrão do projeto, "mude X -> veja Y"?
[ ] CODEBASE LIMPO — fácil de mudar, ou um labirinto que gasta tokens?
Sinais de boa AX: acerta de 1a · acha rápido · não quebra o resto · poucos tokens.
Se 2+ falharam, o problema é a AX (o ambiente) — não o modelo.