Cómo desarrollo software con agentes de programación
Los agentes de programación son mi flujo principal: más de 2.600 commits asistidos por IA solo en un ERP en producción. El agente escribe mucho código. Las decisiones son mías, y este proceso es lo que lo hace seguro.
El proceso
Partir de las reglas del proyecto
Cada repo tiene un archivo corto que dice cómo instalarlo, cómo probarlo y qué no tocar. El agente lo lee primero y luego revisa la rama y si hay trabajo sin commit. Aquí hay uno real.
Planificar antes del trabajo riesgoso
Todo lo grande, o lo que toque pagos, producción, documentos tributarios o datos personales, parte con un plan escrito que apruebo antes de cambiar un solo archivo.
Construir en pasos chicos y verificables
Cada bloque de trabajo es lo bastante chico para revisarlo, y las pruebas corren después de cada uno. En algunos proyectos, un hook corre tipos y pruebas unitarias automáticamente cuando el agente termina.
Probar sin tocar nada real
Las pruebas no usan red, credenciales ni datos reales. Los flujos críticos del ERP tienen unos 180 archivos de prueba, más invariantes en PostgreSQL que bloquean datos inconsistentes.
$ uv run pytest -q10 passed in 0.16s$ gh run list -R Ssebv/odoo-rag -L 1 --json conclusion,status -q '.[0]'{"conclusion":"success","status":"completed"}Repetición de comandos reales.

Integración continua en el repo público. Medir lo que las pruebas no ven
Que una prueba pase no dice si una respuesta de IA es buena. Para eso construyo evaluaciones y comparo opciones con las mismas preguntas. En Odoo RAG, así descubrí que traducir importaba más que la búsqueda híbrida.
Revisar, y contrastar lo que se afirma con el código
Los cambios pasan por revisión de código antes del commit, y por revisión de seguridad si tocan autenticación, pagos o datos personales. También vale para lo que escribo sobre mi trabajo: una revisión detectó que un artículo mío decía que un monitoreo corría cada seis horas, y el código decía que una vez al día. Corregí el artículo.
Desplegar por etapas
Los cambios pasan por staging antes de producción, y los despliegues a producción evitan el horario laboral. En la migración del ERP comparé el resultado contra una línea base previa: facturas, pedidos y despachos quedaron idénticos.
Vigilar en producción
Un health check diario corre más de 40 detectores, con alertas urgentes cada 30 minutos. Escribí sobre lo que encontró, incluido el detector mío que estaba seguro y equivocado.
Lo que el agente no puede hacer solo
- Subir a las ramas de producción o staging del ERP.
- Enviar correos: solo escribe borradores.
- Leer archivos con secretos o forzar un push: esos comandos están bloqueados por regla.
- Tomar las decisiones difíciles de revertir: esas quedan en mis manos.