Cómo trabajo

El ciclo

1. Interrogatorio

   Empiezo con una entrevista, no con un prompt: una pregunta a la vez hasta poner sobre la mesa el problema, las restricciones y los casos límite. El resultado es un árbol de decisiones que puedo defender, no una lista de deseos.

2. Especificación

   Las respuestas se convierten en una especificación breve y escrita: qué construimos, qué no, las decisiones ya tomadas y los riesgos abiertos. Una especificación vaga produce código seguro de sí mismo y equivocado, así que aquí es donde invierto la hora extra.

3. Tickets

   Divido la especificación en porciones verticales que entregan algo usable cada una. Cada ticket lleva criterios de aceptación y nombra lo que lo bloquea, así que el orden es un grafo y no una suposición.

4. Agentes en paralelo

   Los tickets independientes se ejecutan a la vez, cada uno en su propio worktree y su propia sesión, con las mismas convenciones y el mismo contexto. Los agentes no hacen merge, no empujan a ramas protegidas ni tocan credenciales de producción; eso queda en mis manos.

5. Controles de revisión

   Nada entra porque un agente diga que terminó. El chequeo de tipos, el lint y las pruebas corren en CI, un escaneo de seguridad y una primera revisión con IA corren sobre el merge request, y yo leo el diff antes de que salga. Los lanzamientos tienen su propio control.

Qué delego

• La implementación una vez especificada la porción: componentes, endpoints, migraciones y pruebas.
• El trabajo mecánico: renombres, actualizaciones de dependencias, cableado, código repetitivo y andamiaje de pruebas.
• Una primera pasada de revisión de código y de listado de los modos de fallo evidentes.
• Investigación con un resultado escrito: comparar dos librerías, mapear un código desconocido y redactar el desglose de tickets.
• Documentación y ADRs a partir de decisiones que ya tomamos.

Qué me quedo

• La especificación, la arquitectura y el modelo de datos. Los agentes proponen; yo decido.
• Todo lo que toca pagos, autenticación, datos personales o configuración de producción.
• Las migraciones de base de datos y cualquier cosa que no se pueda revertir limpiamente.
• La lectura final de cada diff que se entrega y el lanzamiento mismo.
• La conversación con producto y con el cliente. El contexto que solo vive en una reunión es contexto que un agente no tiene.

Límites de seguridad

Un ciclo más rápido solo sirve si es seguro ejecutarlo muchas veces al día. Estos son los límites que fijo antes de que un agente empiece:

• Un AGENTS.md breve y documentos de convenciones por repositorio, para que un agente reciba las mismas reglas que un desarrollador nuevo.
• Acceso de solo lectura a producción, con cada comando aprobado, y sin permiso para hacer merge ni empujar a ramas protegidas.
• Un ticket por worktree, con la especificación y los criterios de aceptación en el prompt.
• Un tope de presupuesto por ejecución y por repositorio, para que los agentes en paralelo no se conviertan en una factura sorpresa.
• Una persona en cada paso irreversible: cambios de esquema, secretos, lanzamientos y datos de clientes.

Dónde se rompe

Este método es rápido en trabajo bien acotado y más lento al principio a propósito. No rescata una decisión de producto vaga y no sustituye depurar un incidente en producción ni sentarse con alguien a entender qué necesita de verdad. También encarece una mala especificación: un agente implementará lo equivocado a fondo, con pruebas. El control de revisión existe para detectarlo, y es la parte que me niego a automatizar.