Tareas Slam Dunk

Definición

Tareas Slam Dunk son tareas donde un agente de IA puede ejecutar con alta confianza y mínima supervisión porque ya han sido validadas múltiples veces y el agente ha demostrado consistentemente su capacidad para completarlas correctamente. El término proviene del basketball (mates seguros) y fue popularizado por Mitchell Hashimoto en su framework de trabajo con agentes de IA. La filosofía es simple: una vez que sabes que un agente puede manejar una tarea de manera confiable, delégala completamente mientras tú trabajas en algo más interesante o complejo. Criterios para Slam Dunk:

• El agente ha completado la tarea exitosamente 5+ veces
• Existen harnesses que previenen errores comunes
• La tarea tiene criterios de éxito claros y medibles
• No requiere juicio arquitectónico complejo
• Los fallos son detectables automáticamente Principio core: “Outsource the Slam Dunks” - delega lo que sabes que funciona.

Por Qué Importa

Multiplicador de tiempo: Delegando Slam Dunks a agentes, engineers pueden enfocarse en trabajo de alto valor (arquitectura, decisiones estratégicas, features complejas) mientras los agentes manejan tareas repetitivas o bien definidas. Reducción de context switching: En lugar de alternar entre tareas complejas y simples, te mantienes en estado de flow en problemas difíciles mientras los agentes ejecutan las tareas simples en paralelo. Escalabilidad personal: Mitchell Hashimoto reporta 3-5× increase en output personal después de identificar y delegar sus Slam Dunks. No porque el agente sea más rápido, sino porque él puede trabajar continuamente en tareas de high-leverage mientras los agentes manejan el resto. Path hacia autonomía completa: Slam Dunks son el primer paso hacia multi-agent orchestration. Si puedes identificar 5-10 tipos de tareas Slam Dunk, puedes construir un equipo de agentes especializados que operen con mínima supervisión.

Ejemplos de Tareas Slam Dunk

Development

Writing unit tests:

• Después de 3-5 features, agent aprende el pattern de testing
• Harness: Test coverage mínimo 80% en CI/CD
• Supervision: Code review solo si coverage baja Implementing CRUD endpoints:
• Agent sabe pattern REST estándar
• Harness: OpenAPI schema validation + integration tests
• Supervision: Spot check cada 5-10 endpoints Database migrations:
• Agent genera migrations siguiendo naming conventions
• Harness: Dry-run en staging + rollback tests
• Supervision: Review manual solo para cambios de schema complejos Refactoring for consistency:
• Agent aplica patterns establecidos en codebase
• Harness: Linters + test suite existente
• Supervision: Diff review al final del batch

DevOps

Infrastructure as Code updates:

• Agent modifica Terraform siguiendo modules existentes
• Harness: terraform plan + cost estimation
• Supervision: Approval humana solo si cost increase >10% CI/CD pipeline maintenance:
• Agent actualiza GitHub Actions cuando dependencies cambian
• Harness: Test pipeline en branch antes de merge
• Supervision: Monitor first run en main Log analysis y alerting:
• Agent identifica patterns en logs y propone alerts
• Harness: Alert testing en staging
• Supervision: Review mensajes de alerta por clarity

Documentation

API documentation:

• Agent genera OpenAPI docs desde código
• Harness: Schema validation + example testing
• Supervision: Spot check clarity para external users Code comments:
• Agent añade JSDoc/docstrings siguiendo conventions
• Harness: Linter checks format
• Supervision: None (low risk) README updates:
• Agent mantiene README sincronizado con cambios
• Harness: Markdown linting
• Supervision: Quick read antes de release

Cómo Identificar tus Slam Dunks

Framework de Evaluación

Para cada tipo de tarea, pregúntate: 1. Repetibilidad

• ¿La tarea sigue un pattern consistente?
• ¿Hay ejemplos claros en el codebase?
• ¿Los criterios de éxito son objetivos? 2. Risk Level
• ¿Qué pasa si el agente se equivoca?
• ¿Los errores son detectables automáticamente?
• ¿Cuánto cuesta arreglar un error? 3. Track Record
• ¿El agente ha completado esta tarea antes?
• ¿Cuántas veces? ¿Con qué success rate?
• ¿Los errores anteriores tienen harnesses? 4. Complexity
• ¿Requiere decisiones arquitectónicas?
• ¿Involucra trade-offs complejos?
• ¿Necesita domain expertise profundo?

Scoring System

Slam Dunk threshold: Score ≥7.5/10

Progresión: De Supervisión a Slam Dunk

Stage 1: New Task (100% supervision)

• Agent intenta tarea por primera vez
• Engineer supervisa continuamente
• Identifica errores y construye harnesses

Stage 2: Learning (50% supervision)

• Agent ha completado tarea 2-3 veces
• Harnesses básicos en place
• Engineer hace spot checks

Stage 3: Reliable (10% supervision)

• Agent ha completado tarea 5+ veces
• Harnesses comprensivos
• Engineer solo revisa output final

Stage 4: Slam Dunk (0% supervision)

• Agent completamente autónomo
• Harnesses automatizan validación
• Engineer solo interviene si harness falla Timeline típico: 2-6 semanas dependiendo de complejidad de tarea

Casos Reales

Ghostty - Mitchell Hashimoto

Slam Dunks identificados en 3 meses:

1. Writing Zig unit tests
   • Progresión: 3 semanas → Slam Dunk
   • Success rate: 97% (agent solo)
   • Time saved: ~15 horas/semana
2. Terminal escape sequence parsing
   • Progresión: 6 semanas → Slam Dunk
   • Success rate: 92% (agent solo)
   • Time saved: ~8 horas/semana
3. Documentation updates
   • Progresión: 1 semana → Slam Dunk
   • Success rate: 99% (agent solo)
   • Time saved: ~3 horas/semana Total time savings: ~26 horas/semana = 3.25 días/semana dedicados a arquitectura y features complejas

E-commerce Startup

Slam Dunks después de 2 meses con Devin:

• CRUD endpoints: 15+ exitosos → Slam Dunk
• Stripe integration patterns: 8 exitosos → Slam Dunk
• React component scaffolding: 20+ exitosos → Slam Dunk
• Database migrations: 12 exitosos → Slam Dunk Resultado: Engineer puede lanzar 2-3 features/semana vs 0.5-1 feature/semana previamente.

Anti-Patterns: Lo que NO es Slam Dunk

Arquitectura de sistemas: Requiere juicio, trade-offs, experiencia. Agent puede proponer, human decide. Security-critical code: Auth, payments, PII handling. Siempre requiere review humana. Decisiones de producto: Qué features construir, priorización, UX decisions. Agent informa, human decide. Performance optimization crítica: Requiere profiling, entendimiento de bottlenecks, trade-offs. Agent ayuda, human lidera. Legacy code sin tests: Alto risk, difícil validar correctness. Construir harnesses primero.

Herramientas y Frameworks

Task Management:

• Linear / Jira con labels “slam-dunk-candidate”
• Tracking success rate por tipo de tarea
• Identificación automática de patterns Harness Infrastructure:
• Pre-commit hooks
• CI/CD con validaciones
• Monitoring y alerting Agent Delegation:
• Claude Code / Cursor para tareas individuales
• Devin para tareas end-to-end
• Custom orchestration para multi-task

Términos Relacionados

• Ingeniería del Harness - Práctica que habilita Slam Dunks
• Codificación Agéntica - Paradigma donde agentes ejecutan código autónomamente
• Agent-Ops - Rol que identifica y optimiza Slam Dunks
• Orquestación Multi-Agente - Escalar Slam Dunks a múltiples agentes

Recursos Adicionales

• Mitchell Hashimoto: My AI Adoption Journey
• Outsource the Slam Dunks — Zed Blog
• Notes on Agentic Engineering in Action

Última actualización: Febrero 2026 Categoría: AI Development Popularizado por: Mitchell Hashimoto (HashiCorp, Ghostty) Relacionado con: Harness Engineering, Agentic Coding, Agent Delegation, Autonomous Tasks Keywords: slam dunk tasks, mitchell hashimoto, agent delegation, high-confidence tasks, agentic coding, autonomous ai agents, task automation