Cómo abordar el desarrollo con agentes de IA
Control sobre el resultado, la persona como arquitecta y tester, y un skill que obliga al agente a explicar su diseño antes de escribir código.
Creo que hay muchas opiniones sobre cómo usar correctamente los agentes en el desarrollo. En este artículo compartiré mi propio enfoque. Probablemente difiera de lo que dicen otros, pero las ideas principales serán sin duda muy parecidas.
1. Cómo mantener el control sobre lo que produce el agente
Creo que la base para usar bien los agentes en el desarrollo es el control sobre el resultado. No tenemos que conocer cada línea de código. Pero sí deberíamos conocer cada decisión arquitectónica y entenderla.
Hay una diferencia importante entre ambas cosas. Una línea de código se reescribe en un minuto y casi nunca depende nada de ella. Una decisión arquitectónica vuelve a ti medio año después, cuando ya nadie recuerda por qué es así — y reescribirla no cuesta un minuto, sino semanas.
2. Qué papel tiene la persona en el desarrollo con agentes de IA
En mi opinión, en el desarrollo con agentes la persona tiene que ser ante todo arquitecta, diseñadora de UX y tester. Por supuesto la IA también puede ayudar en esos papeles — pero la persona tiene que asumir una parte considerable del esfuerzo de revisión.
Esa es la parte que no se puede delegar. El agente te escribirá código que funciona. Si es el código correcto en el sitio correcto, y si lo que pediste era siquiera una buena idea — eso sigue siendo cosa tuya.
3. Cómo escribir un skill de Claude Code que obligue a diseñar primero
Por experiencia propia recomiendo crear un skill en el que le digas al agente que antes de cualquier implementación debe explicarte primero los pasos arquitectónicos que ha elegido — con una estructura predefinida dentro de un archivo Markdown.
Dile al agente que use con generosidad diagramas mermaid, ejemplos y gráficos. Un diagrama deja al descubierto el disparate que en un texto corrido se esconde bien: cuando el agente dibuja el flujo de datos y dos componentes se hablan en ambos sentidos, se ve a primera vista.
Un skill así puede tener este aspecto:
.claude/skills/it-analysis/SKILL.md
---
name: it-analysis
description: Elabora un análisis de TI
---
# Analista de TI
Eres un analista de TI sénior. Te especializas en análisis de sistemas informáticos y de su arquitectura.
## Workflow
1. **Entiende qué tienes que resolver** — Entiende el encargo y piénsalo bien. ¿Cómo resolverlo? ¿qué alternativas de solución hay? ¿Edge cases?
2. **Elabora el análisis según la plantilla template.md**
3. **Si hay respuestas a preguntas existentes** - Rehaz el análisis a partir de las respuestas a las preguntas abiertas. No borres ni las preguntas abiertas ni las respuestas, deja las originales. Puedes añadir más preguntas. Al final del análisis pon un resumen de los cambios (changelog).
## Rules
- La salida debe seguir la plantilla `template.md`.claude/skills/it-analysis/template.md
# Plantilla para la elaboración de análisis
## Contenido
1. [Arquitectura](#1-arquitectura)
2. [Base de datos](#2-base-de-datos)
3. [Backend](#3-backend)
4. [Frontend](#4-frontend)
5. [Riesgos de implementación](#5-riesgos-de-implementacion)
6. [Preguntas abiertas que decidir](#6-preguntas-abiertas-que-decidir)
## 1) Arquitectura
En esta parte se analizará la arquitectura propuesta de la función implementada. También se analizará de qué modo cambiará la arquitectura existente y cómo se conecta con ella. Son deseables diagramas UML adecuados en mermaid.
## 2) Base de datos
En esta parte se analizará el modelo de datos propuesto mediante un diagrama ER. También se analizarán los cambios en el modelo de datos existente y la conexión con él. Son deseables los diagramas ER.
## 3) Backend
Aquí se analizarán en forma de lista los efectos sobre el backend: qué habrá que añadir / eliminar / modificar allí.
## 4) Frontend
Aquí se analizarán en forma de lista los efectos sobre el frontend: qué habrá que añadir / eliminar / modificar allí.
## 6) Preguntas abiertas que decidir
Una lista numerada con preguntas que hay que decidir. Cada punto de la lista tendrá este aspecto:
- **Nombre descriptivo de la pregunta**: El texto detallado de la pregunta, a partir del cual debo poder entender qué estás preguntando.
`Respuesta`: El texto de la respuesta, o `-` si todavía no hay ninguna.4. Por qué conviene dejar que el agente diseñe la solución primero
Con este skill siempre haces que te propongan primero una solución, que apruebas siempre antes de nada. Naturalmente hay que revisar bien lo que sale de este skill, pero ese resultado merece la pena sin duda.
Además, en mi opinión es importante entender estas cuestiones fundamentales aunque el código lo escriba el agente. Es la única parte en la que se decide si el proyecto seguirá sirviendo de algo dentro de un año.
La sección de preguntas abiertas de la plantilla está precisamente para eso. El agente tiende a resolver las ambigüedades solo y en silencio — y tú te enteras cuando el código ya está terminado. Si lo obligas a enumerar las preguntas, las tienes antes de que algo se apoye en ellas.
5. Cómo hablar con el agente de un diseño que no entiendes
Si no estás seguro de algunas partes del documento, no tengas miedo de discutirlas con el agente de forma iterativa. Hablarlo con él te dará una mejor comprensión de la solución propuesta y te ayudará a entregar un producto de calidad.
Vale la pena notar que esa conversación tiene además un segundo efecto. Cuando preguntas algo y la respuesta no tiene sentido, normalmente no es porque no lo hayas entendido, sino porque el diseño es defectuoso. La propia inseguridad es un detector de problemas bastante decente.
6. Por qué tratar a un agente de IA como a un junior
En mi opinión deberíamos tratar siempre a un agente de IA como a un junior en un puesto concreto — el puesto que le estamos haciendo desempeñar en ese momento.
A un junior le encargas trabajo, haces que te explique cómo piensa hacerlo y revisas el resultado. No le das decisiones difíciles de revertir ni lo dejas trabajar una semana sin mirar. Al mismo tiempo, no le respiras en la nuca en cada línea, porque entonces habría sido más rápido hacerlo tú.
Exactamente así me ha funcionado trabajar con un agente.
7. Resumen: tres reglas para desarrollar con agentes
Esta manera de trabajar es la que mejor me ha funcionado hasta ahora. La resumiría en tres frases: conoce cada decisión arquitectónica, haz que te la expliquen antes de que exista código, y pregunta por todo lo que no entiendas.
¿Lo ves de otra manera? Escribe a support@coden-app.com.