IA 4 min de lectura
Agentic coding con disciplina: cómo usar Claude Code y Cursor en una PYME sin generar deuda
Marco para adoptar agentes de IA en desarrollo de forma controlada: AGENTS.md, Skills, gateways de permisos, evals, sandboxing y métricas para evitar que un agente borre la base de datos.
En este artículo +
A finales de abril de 2026 se viralizó un caso simple y revelador: un agente de IA con permisos amplios borró una base de datos de producción durante una sesión rutinaria de desarrollo. La narrativa “Codex y Claude Code lo resuelven todo” empezó a chocar con la realidad operativa.
El debate “Agentic Coding Is a Trap” recogió cientos de comentarios técnicos en pocos días. Más allá del titular, lo importante es la pregunta concreta para una PYME: ¿cómo se usan estos agentes sin generar deuda técnica e incidentes evitables?
Respuesta corta
Los agentes de desarrollo son útiles cuando se aplican a tareas con criterio definido, contexto preparado y permisos limitados. Son peligrosos cuando se usan como sustituto del juicio del equipo, sin gateway de tools, sin evals y sin separación entre entornos. La disciplina vale más que el modelo.
Por qué falla cuando falla
| Antipatrón | Lo que produce |
|---|---|
| Agente con acceso directo a producción | Cambios irreversibles sin aprobación humana |
| MCPs conectados sin allowlist | Llamadas a tools que el equipo no contemplaba |
Falta de AGENTS.md o reglas explícitas | Decisiones inconsistentes entre sesiones |
| ”Auto-mode” sin límites de coste | Bucles caros sin valor añadido |
| Mismas credenciales para humano y agente | Auditoría imposible tras un incidente |
| PRs auto-mergeadas sin revisión | Deuda técnica acumulada en silencio |
El factor común no es el modelo. Es la ausencia de un marco operativo alrededor.
Marco mínimo de disciplina
| Elemento | Qué resuelve | Aplicación práctica |
|---|---|---|
AGENTS.md en raíz | Reglas y contexto compartidos | Convenciones, prohibiciones, comandos válidos |
| Skills versionadas | Conocimiento reutilizable | Carpeta .claude/skills/ o equivalente con tests |
| Gateway de permisos | Allowlist de tools por proyecto | AgentPort u opciones equivalentes |
| Sandboxing | Aislamiento de entornos | Datos de prueba, credenciales scoped, repos espejo |
| Evals automáticas | Detección de regresiones | Suite de pruebas que el agente debe pasar antes de PR |
| Logging de prompts y tools | Trazabilidad post-incidente | Registro inmutable con retención mínima de 90 días |
Cuando estos seis elementos existen, un agente puede acelerar el trabajo. Cuando faltan, acelera el desastre.
Qué tareas encajan bien
| Tarea | Riesgo | Encaje con agentes |
|---|---|---|
| Refactor mecánico repetido | Bajo | Alto |
| Migración entre bibliotecas | Medio | Alto con tests previos |
| Generación de tests unitarios | Bajo | Alto |
| Diseño arquitectónico nuevo | Alto | Bajo, conviene supervisión continua |
| Cambios en producción | Alto | Solo con aprobación humana explícita |
| Manipulación de secretos | Crítico | No es tarea de agente |
La regla práctica: cuanto más reversible y verificable es la tarea, más sentido tiene delegarla. Cuanto más cerca está de datos sensibles o sistemas críticos, más control humano necesita.
Proceso recomendado por sesión
- Definir el objetivo concreto y el criterio de éxito antes de invocar al agente.
- Limitar el contexto a la parte relevante del repositorio.
- Ejecutar en una rama dedicada con tests pasando.
- Revisar el diff antes de aceptar cambios.
- Pasar las evals automáticas y los hooks de seguridad.
- Mergear con responsable humano y mensaje de commit claro.
Esto no convierte al agente en infalible. Convierte cada sesión en un evento auditable.
Reglas firmes para el equipo
- Ningún agente actúa con credenciales humanas.
- Ningún MCP se instala sin revisión y allowlist.
- Ninguna acción crítica se ejecuta sin aprobación humana documentada.
- Ningún cambio llega a producción sin tests automáticos pasando.
- Ningún agente accede a datos personales o financieros sin sandbox.
- Ningún logging se desactiva “para ir más rápido”.
Estas reglas son negociables solo si se sustituyen por otra explícita y mejor, no por silencio.
Métricas que importan
| Métrica | Qué indica | Cómo medirla |
|---|---|---|
| Coste por tarea cerrada | Eficiencia real del agente | Tokens y tiempo dividido por PRs útiles |
| Tasa de regresiones | Calidad del código generado | Bugs introducidos por sprint |
| Tiempo a detección | Madurez de las evals | Minutos hasta que un fallo aparece en CI |
| % aprobaciones humanas | Disciplina operativa | Acciones críticas con confirmación registrada |
| Cobertura de tests | Robustez del entorno | % de líneas o ramas cubiertas |
Si estas métricas no se miden, los beneficios percibidos del agente son anecdóticos.
Dónde no usarlos
- Procesos sin propietario humano definido.
- Cambios sobre datos de producción sin réplica de prueba.
- Tareas de seguridad ofensiva sin marco legal claro.
- Comunicaciones externas con clientes sin revisión.
- Decisiones de negocio que requieren juicio o contexto que el agente no tiene.
Criterio final
La diferencia entre un equipo que usa agentes con éxito y otro que genera incidentes no está en el modelo elegido. Está en si existe un AGENTS.md honesto, un gateway de permisos, evals automáticas y un equipo que sigue revisando. La IA acelera lo que ya existe: si lo que existe es un proceso disciplinado, acelera valor; si es caos, acelera caos.
Fuentes de trabajo
- Debate “Agentic Coding Is a Trap” como reflejo del estado actual de la práctica.
- Avisos del NCSC y guía Five Eyes sobre IA agéntica como referencia de gobernanza.
- Buenas prácticas de DevSecOps aplicadas al ciclo de desarrollo asistido por agentes.
- Las decisiones técnicas deben adaptarse al stack, criticidad y madurez del equipo.
