Sistema de Boundaries

Por que boundaries

Los agentes de codigo pueden ejecutar comandos, crear archivos, instalar dependencias y hacer commits. Sin restricciones claras, un agente bien intencionado puede:

• Instalar una dependencia de produccion que no necesitas
• Eliminar un test que “falla” en vez de arreglarlo
• Commitear un archivo .env con secretos
• Hacer force-push a main

Los boundaries definen los limites de autonomia del agente.

El sistema de tres niveles

El patron mas efectivo (segun el analisis de GitHub de 2,500+ repos) usa tres niveles:

Always do (siempre hacer)

Acciones que el agente debe realizar sin preguntar:

### Always do
- Run tests after modifying any source file
- Run linter before committing
- Add TypeScript types to all new functions
- Create test file for every new module
- Validate inputs with Zod at API boundaries

Ask first (preguntar primero)

Acciones que requieren aprobacion humana antes de ejecutarse:

### Ask first
- Before adding new production dependencies
- Before modifying database migrations
- Before changing CI/CD pipeline configuration
- Before deleting any file
- Before modifying public API interfaces

Never do (nunca hacer)

Acciones prohibidas, sin excepciones:

### Never do
- Never commit .env, credentials, or API keys
- Never delete or skip failing tests
- Never use `any` as TypeScript type
- Never force-push to main or develop
- Never install packages globally
- Never modify vendor/ or node_modules/
- Never run destructive database commands (DROP, TRUNCATE)
- Never disable security rules or linting

Boundaries por dominio

Seguridad

### Security boundaries
- Never hardcode secrets, tokens, or passwords
- Never log sensitive data (PII, passwords, tokens)
- Never use weak cryptography (MD5, SHA1 for passwords)
- Never disable CORS or security headers
- Always use parameterized queries (no string concatenation for SQL)

Datos

### Data boundaries
- Never run migrations in production without explicit approval
- Never seed production database
- Ask before adding or removing database columns
- Always create a migration file for schema changes (never modify DB directly)

Dependencias

### Dependency boundaries
- Ask before adding any production dependency
- Never add dependencies with known vulnerabilities
- Prefer stdlib or existing deps over new packages
- Dev dependencies are OK to add without asking

Infraestructura

### Infrastructure boundaries
- Never modify Docker production configs without asking
- Never change port mappings in docker-compose
- Ask before modifying nginx/reverse proxy configs
- Never expose internal services to public network

Boundaries efectivos vs inefectivos

Efectivo	Inefectivo
”Never commit files matching .env*"	"Be careful with secrets"
"Functions must be under 30 lines"	"Keep functions small"
"Run bunx vitest run after changes"	"Test your code"
"Use Zod schemas for input validation"	"Validate inputs”

La diferencia: los boundaries efectivos son verificables y accionables. El agente puede determinar si los esta cumpliendo o no.

Boundaries dinamicos

Algunos boundaries cambian segun el contexto. Puedes expresarlos condicionalmente:

### Conditional boundaries
- If modifying files in `src/domain/`: run domain tests with `bun test:domain`
- If modifying API routes: update OpenAPI spec in `docs/api.yaml`
- If adding a new endpoint: include rate limiting middleware
- If the file has more than 100 lines after changes: consider splitting

La restriccion mas comun (y mas util)

Segun el estudio de GitHub, la restriccion mas mencionada en AGENTS.md exitosos es:

“Never commit secrets”

Parece obvio, pero los agentes no tienen el mismo juicio que un humano sobre que constituye un secreto. Ser explicito previene accidentes.

Resumen

• Boundaries definen los limites de autonomia del agente
• Tres niveles: Always (sin preguntar), Ask first (con aprobacion), Never (prohibido)
• Boundaries efectivos son verificables y accionables, no vagos
• Cubrir dominios: seguridad, datos, dependencias, infraestructura
• “Never commit secrets” es la restriccion mas comun y mas util

---

← Capitulo 4: Monorepos y Jerarquias | Capitulo 6: Optimizacion de Tokens →