Tareas atómicas y commits atómicos
En desarrollo guiado por especificaciones, una tarea atómica es una unidad de implementación pequeña y verificable de forma aislada, descrita con un prompt de cuatro campos (rol, tarea, restricciones y criterios de éxito). Las tareas independientes se ejecutan en oleadas paralelas, y cada tarea cierra con un commit atómico: un commit por tarea, que preserva la cadena requisito → diseño → tarea → commit.
La fase de tareas transforma la complejidad de un cambio grande en una serie de cambios pequeños con fronteras claras. La complejidad no desaparece, pero se convierte en una secuencia manejable.
Anatomía de una tarea atómica
Una tarea bien definida afecta normalmente a entre uno y tres ficheros; si necesita más, probablemente se puede descomponer. Su corazón es un prompt estructurado de cuatro campos:
| Campo | Qué fija |
|---|---|
| Rol | El punto de vista que asume el agente. |
| Tarea | El alcance concreto de lo que hay que hacer. |
| Restricciones | Los boundaries de esa tarea (véase AGENTS.md). |
| Criterios de éxito | Lo que permite comprobar la tarea sin releer todo el código. |
Los cuatro campos no son burocracia: son lo que hace la tarea verificable de forma aislada, porque su resultado puede evaluarse sin haber completado las demás.
Oleadas de tareas paralelas
Las tareas no son necesariamente secuenciales. Las que no dependen entre sí se agrupan en una misma oleada y se ejecutan en paralelo, cada una por un subagente con contexto limpio; las oleadas se ejecutan en secuencia. El modelo aprovecha la capacidad de los agentes para trabajar en paralelo sin que el contexto de una tarea contamine el de otra, y es el patrón de orquestador y trabajadores que describe la guía de Anthropic sobre agentes eficaces.
El orden de las oleadas lo dictan las dependencias del diseño: primero lo que crea las estructuras de las que dependen las demás, después lo que las usa, al final lo que integra. Una tarea que espera a otra de su misma oleada es una señal de que la descomposición no respetó las dependencias.
Commits atómicos y la cadena de trazabilidad
Cada tarea genera un commit independiente, con tres consecuencias: reversibilidad granular (una tarea defectuosa se revierte sin afectar a las demás), bisección eficaz (se identifica con precisión qué tarea introdujo un defecto) y trazabilidad. Esta última es la cadena que recorre todo el método: cada commit se vincula a una tarea, cada tarea a un diseño y cada diseño a unos requisitos. Esa cadena requisito → diseño → tarea → commit es la que resulta aprovechable ante un regulador (véase Trazabilidad y supervisión humana).
Hay un límite. Si el prompt que describe una tarea es más largo que el código que producirá, la descomposición ha ido demasiado lejos. El tamaño correcto es el que permite al agente trabajar con contexto completo y a la persona revisar el resultado de un vistazo, en minutos y no en horas.
Error frecuente
Commits que mezclan varias tareas. Pierden la reversibilidad granular y la trazabilidad, y hacen inútil la bisección. En el otro extremo está la descomposición excesiva: si el prompt es más largo que el código que produce, el coste supera al beneficio. El tamaño correcto es el que cabe en un vistazo y en un solo commit vinculado a una tarea, un diseño y unos requisitos.
Recursos
📊 Guía didáctica SDDRecursos · Scrum Manager
🏦 SDD en equipos ágilesSkill Arena · Scrum Manager
Referencias
- Anthropic. (2024). «Building effective agents».
- GitHub. (2026). Spec Kit (documentación del proyecto).
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.