Qué es Tasks as Code y por qué importa ahora
Guardar las tareas de desarrollo como archivos Markdown dentro del repositorio de código —en lugar de dejarlas encerradas en Jira o Redmine— es la diferencia entre que un agente de IA entienda el trabajo o lo adivine. Los agentes de código trabajan mejor cuando todo lo que necesitan vive en el repositorio, porque el código es su fuente de verdad. Si los requisitos están en otra herramienta, el agente opera a ciegas.
La idea no nace de la nada: se apoya en un movimiento que ya recorrió ese camino, Docs as Code.
Docs as Code: el ensayo general que ya funcionó
La documentación técnica ya hizo la transición desde software dedicado hacia archivos Markdown en un repositorio Git. Hoy suele vivir en una carpeta /docs dentro del repo del código, una práctica conocida como Docs as Code o Docs Like Code.
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 díasCon agentes de IA el beneficio se multiplica. El agente lee la documentación para entender el sistema, modifica el código y actualiza los docs relevantes dentro del mismo flujo de trabajo. La documentación deja de ser una actividad que se hace después y se convierte en parte integral del desarrollo.
Tasks as Code traslada ese mismo principio a las tareas: cada tarea es un archivo Markdown, y Git mantiene su historial junto al del software y la documentación.
Spec Kit: cómo GitHub convirtió la especificación en el artefacto central
La versión más formal de esta idea es el Spec-Driven Development (SDD), que usa especificaciones en Markdown para definir el comportamiento esperado antes de que un agente lo implemente. GitHub liberó Spec Kit, un proyecto de código abierto bajo licencia MIT que empaqueta plantillas, una CLI y prompts para trabajar con agentes como GitHub Copilot, Claude Code o Gemini CLI, según reportó Visual Studio Magazine.
El diagnóstico que dio origen a la herramienta lo resumió Den Delimarsky, Principal Product Manager de GitHub: el problema no es la capacidad del agente para programar, sino el enfoque, porque se los trata como motores de búsqueda cuando deberían tratarse como pares programadores literales.
Spec Kit organiza el trabajo en cuatro fases con puntos de control explícitos —Specify, Plan, Tasks, Implement— y no avanza hasta que la fase actual se valida. El repositorio lista como prerrequisitos Linux/macOS o WSL2, Python 3.11+, uv y Git. InfoWorld probó la herramienta y describió que se puede pasar de una especificación básica a un prototipo funcional en una tarde; también destacó un detalle útil: cuando una pasada no puede implementar algo, el sistema inserta un marcador [NEEDS CLARIFICATION] en lugar de asumir.
No hace falta adoptar Spec Kit para empezar. El artículo original propone algo más simple: tratar el archivo de tarea como la especificación misma. Eso reduce la barrera a Git y un agente.
El flujo de cinco pasos que puedes copiar hoy
- Describe la tarea. Una descripción corta del cambio o funcionalidad a implementar.
- Analiza los requisitos. El agente lee la tarea y examina el código y la documentación relevantes.
- Crea un plan de implementación. El agente agrega una solución propuesta e identifica los cambios que pretende hacer.
- Revisa y aprueba. Una persona revisa el plan y autoriza la implementación.
- Implementa y reporta. El agente cambia el código, actualiza la documentación donde haga falta y añade un informe de implementación al archivo de la tarea.
El paso de aprobación es el que mantiene el control humano: el agente no salta de la descripción a la implementación, primero se revisa y corrige el plan. Descripción, plan e informe quedan juntos en un mismo archivo, así que revisar los requisitos originales y ver qué cambió el agente es una sola consulta.
La arquitectura: tres repositorios y un .gitignore
El autor del artículo original usa tres repositorios Git separados: código, documentación y tareas. La razón es de acceso: la documentación puede ser pública, mientras que las tareas contienen información sensible sobre correcciones de seguridad sin publicar, planificación interna o funcionalidades no anunciadas. Separarlos permite configurar permisos de forma independiente.
En local, el desarrollador clona los repos de documentación y tareas dentro de carpetas del repo de código, y ambos aparecen en el .gitignore para que el repo padre no rastree su contenido. Cada repo conserva su propio historial y se sincroniza por separado. Referenciar el nombre del archivo de tarea en el commit conecta la implementación con el requisito original.
Cuando las tareas se organizan en carpetas por release, el agente puede usar las tareas completadas y el historial de Git para redactar el changelog y las notas de versión, y para detectar qué documentación quedó desactualizada.
¿Y Jira? Atlassian apuesta a lo contrario
Mientras esta corriente saca las tareas de las herramientas de tickets, Atlassian va en la dirección opuesta. Según SiliconANGLE, la compañía presentó Jira Planner para convertir ideas incompletas en especificaciones técnicas, un Jira Coding Agent y una plantilla de ingeniería agéntica que permite asignar trabajo a agentes como Claude, Codex, Cursor o GitHub Copilot directamente desde Jira. Su argumento: la adopción de agentes ya es amplia, pero las mejoras empiezan a estancarse porque la planificación y la coordinación se volvieron el cuello de botella.
La cobertura de SD Times señala que Jira for Slack, Jira Coding Agent, las automatizaciones de agentes y las sesiones de agentes están disponibles para clientes de pago de Jira Cloud sin costo adicional, mientras que Jira Planner está en acceso anticipado.
Y hay un dato que conviene tener a mano antes de delegar en exceso: SiliconANGLE citó un estudio de investigadores de Queen’s University en Kingston, Canadá, que revisó 61.000 repositorios y 47.000 desarrolladores y concluyó que las contribuciones de agentes de IA se aceptan con menos frecuencia que las humanas y tienden a ser estructuralmente más simples.
Qué significa esto para tu startup
Si tu equipo ya usa agentes de código, el cuello de botella dejó de ser la generación de código y pasó a ser el contexto. Estas son las acciones con mejor relación esfuerzo/impacto:
- Empieza con una carpeta
/tasksy nada más. No necesitas Spec Kit ni un CMS. Crea un archivo Markdown por tarea con descripción, criterios de aceptación y un espacio para el informe de implementación. Si funciona, escalas; si no, borras una carpeta. - Escribe una constitución de proyecto. Spec Kit la usa como conjunto de principios que definen cómo debe construirse el código. Una versión mínima —lenguaje, framework, estándares de testing, qué nunca tocar— reduce las suposiciones del agente más que cualquier prompt largo.
- Separa el repositorio de tareas del de documentación. Los permisos son distintos y el contenido también. Un repo privado de tareas evita filtrar correcciones de seguridad sin publicar.
- Mantén el paso de aprobación. El plan revisable antes de implementar es lo que evita que el agente resuelva el problema equivocado con mucho entusiasmo.
- Elige herramientas por portabilidad, no por features. Los criterios que importan son que sea Git-native, file-based, self-hosted y abierto a distintos proveedores de IA. Si mañana cambias de agente, tus archivos Markdown siguen ahí.
La pregunta abierta que deja este cambio es qué partes del sistema de tickets sobreviven. Asignaciones, comentarios, tableros kanban, sprints: si los agentes hacen buena parte del trabajo, probablemente no todas. Vale la pena revisar cuáles de esas funciones usa realmente tu equipo y cuáles solo existen porque siempre estuvieron.
Fuentes
- Tasks as Code: Move Your Tickets into the Repository (fuente original)
- Spec-driven AI coding with GitHub’s Spec Kit – InfoWorld
- GitHub Open Sources Kit for Spec-Driven AI Development – Visual Studio Magazine
- Atlassian evolves Jira into an orchestration hub for developers and AI agents – SiliconANGLE
- How Atlassian’s New Jira AI Features Give Coding Agents Context to Build Software – SD Times
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
