¿Qué significa ser un desarrollador AI First? Una reflexión

Joel Humberto Gómez Paredes publicó en dev.to un post que me hizo revisar cómo trabajo: Tratando de ser un desarrollador AI First sin vender humo. Su definición de AI First es corta: "usar la AI como herramienta principal para potenciar el valor de la organización". Lo que me quedó dando vueltas es la segunda mitad de su argumento: todo lo que no toca ese valor es humo, por más agentes que tengas corriendo.

Su post está escrito con humor y vale la pena leerlo entero. Lo que sigue es lo que pensé después, mirando cómo trabajo yo con agentes.

Primero el valor, después la herramienta

Joel arranca por la organización: antes de decidir dónde meter IA, hay que entender qué hace que exista y cómo opera, y eso, dice, se descubre hablando con las personas más que escribiendo un prompt.

Coincido del todo, y lo noto a escala chica, en mi propio trabajo. Que un agente escriba más código y más rápido no me sirve de mucho por sí solo, porque escribir el código casi nunca fue lo que me frenaba. Donde la IA me agrega valor de verdad es en todo lo que rodea al código y se come las horas sin que se note. Cuando solo me hace producir más rápido algo que nadie necesitaba, es exactamente el humo del que habla él.

El contexto hay que escribirlo

Una de sus ideas más útiles es que el modelo no sabe nada de lo que queda fuera de su contexto: ni tu stack, ni tu arquitectura, ni por qué algo es importante. Y que entre tú y el modelo hay un harness que decide qué contexto le llega.

Esto, en la práctica, significa escribir. El repositorio de este sitio tiene un CLAUDE.md con los comandos, el flujo para publicar, las reglas de marca y las cosas que no se hacen (como poner el año del footer con new Date().getFullYear()). Tiene también un catálogo de componentes en .claude/rules/. No tiene nada de sofisticado: es la documentación que antes vivía en mi cabeza, puesta donde el agente la puede leer.

Skill first: lo que repites se vuelve skill

Joel propone una regla que me pareció la más aplicable de todo el post: si repites algo en más de una sesión, piensa si puede ser una skill. Y advierte contra crear agentes demasiado pronto, con una comparación que me gustó: es como arrancar un proyecto con microservicios sin conocerlo todavía.

Es lo que me llevó a publicar abr4xas/skills. Lo que rodea al código son cosas como los comentarios que un bot de review dejó en el PR, la cadena de ramas que no se puede mergear, la decisión que tomé hace semanas y ya no sé defender. Son procedimientos chicos, con detalles que se aprenden en una tarde y se olvidan el viernes, y que le terminaba explicando al agente en cada sesión. Así que los escribí una vez:

• answer-reviewers responde los comentarios de los reviewers y resuelve los hilos del PR desde la terminal, con gh y jq, sin abrir el navegador.
• resolve-stacked-conflicts vuelve mergeable una cadena de PRs apilados, conflicto por conflicto y en orden, porque solo el primero de la cadena es real y resolverlo cambia todos los que siguen.
• decision-recap arma una página HTML con las decisiones detrás de un trabajo terminado: qué otras opciones hubo y por qué perdieron.
• fix-context-drift corre driftwatch sobre el AGENTS.md, el CLAUDE.md y las skills del repo para encontrar lo que dejó de ser cierto. Es el complemento del punto anterior: el contexto que escribes también envejece.

Las cuatro son archivos que se instalan con npx skills, quedan en tu repo y puedes editar. Los subagentes llegan después, cuando una tarea necesita su propia ventana de contexto para no ensuciar la sesión principal.

La postura que le agregaría: verificar

Joel dice, con razón, que la IA no te exime de aprender. Yo le sumaría que tampoco te exime de comprobar.

La IA, en su conjunto, sabe más que cualquiera de nosotros, y es un gran compañero para discutir decisiones antes de tomarlas. Pero entrega con la misma seguridad algo que funciona y algo que solo parece funcionar, y el segundo caso es el peligroso porque no avisa.

Dos de mis skills existen justo por eso. Un agente escribe Alpine.js con mucha soltura, pero el código que produce se lee correcto aunque Alpine falle sin decir nada. Un segundo elemento raíz dentro de un <template x-for> se descarta sin error; un x-transition sobre un x-if no hace nada. La skill alpinejs reúne esas trampas y revisa contra ellas todo lo que el agente escribe.

Con GitHub pasa algo parecido. En un PR real, la API REST reportaba como Copilot al mismo reviewer que GraphQL llamaba copilot-pull-request-reviewer, así que un filtro que funcionaba en una API no encontraba nada en la otra, otra vez sin error. Ese tipo de detalle es el que answer-reviewers deja escrito para que el agente no lo tenga que descubrir cada vez.

En los dos casos el resultado se veía bien y estaba mal, y solo lo detecta algo que no sea la propia IA. Es la misma idea que me dejó el post de Luis Güette sobre si Claude te está haciendo más tonto: la fricción de ir a la fuente es el precio de no repetir el error de otro.

La calma también es una decisión técnica

La última parte del post de Joel es la que más falta hace leer: vendehumos siempre hubo, con la IA se multiplicaron, y cada opinión que te llega viene de un contexto que no es el tuyo. Él lo ilustra con el loop engineering, cuya utilidad depende de tu harness y de tu presupuesto.

Comparto eso, y le encuentro un lado práctico. Que alguien con un presupuesto ilimitado de tokens automatice todo su flujo no significa que a ti te convenga. Elegir qué adoptar y qué ignorar es tan parte del trabajo como escribir el código. Y a quien recién empieza le cuesta el doble mantener la calma, porque además del ruido se encuentra con que los puestos de entrada, donde antes se aprendía, son justo los que se están cerrando.

Entonces, ¿qué es ser un desarrollador AI First?

Con lo que dice Joel y lo que veo en mi propio trabajo, mi versión es esta: entender qué valor entregas, escribir el contexto que la IA necesita para ayudarte con eso, convertir en skill lo que repites y verificar lo que te entrega antes de que llegue a alguien más.

Para eso no hacen falta veinte agentes; hace falta conocer tu flujo mejor de lo que lo conocías antes de que existiera la IA.

Fuentes

• Tratando de ser un desarrollador AI First sin vender humo, de Joel Humberto Gómez Paredes, el post que dio pie a esta reflexión.
• abr4xas/skills, mis skills para el trabajo alrededor del código.
• Is Claude making you dumber?, de Luis Güette.