Hace unos meses que no escribo código yo mismo. Ni una línea. Ni scripts, ni parches, ni refactorizaciones hechas a mano.
En su lugar, escribo tickets. Objetivos, resultados esperados, criterios de aceptación. Como un Product Owner en Jira, salvo que quien recoge el ticket no es una persona. Es una IA. Reformula lo que ha entendido, abre una rama, entrega el trabajo y presenta los resultados. Iteramos hasta completar correctamente la tarea.
Y no avanzamos de un ticket en uno. Avanzamos con cinco, diez, quince y, a veces, veinte en paralelo.
¿Qué es un Agentic Development Environment?
Un Agentic Development Environment (ADE) no es un IDE al que se ha añadido IA. Es un entorno diseñado para que los agentes de IA hagan el trabajo por ti, contigo como árbitro en lugar de ejecutor.
En un IDE clásico ocupas el centro: editas, pruebas y creas commits. La IA sugiere. En un ADE describes la intención, la IA hace el resto y tú validas el resultado. La unidad de trabajo cambia radicalmente: ya no es el archivo, sino el ticket.
¿Por qué un kanban y no un chat?
La mayoría de los productos de IA para desarrolladores son chats. Funcionan bien para un uso individual, pero se quedan cortos en cuanto intentas ejecutar varias tareas en paralelo:
- Un chat es lineal; un proyecto tiene estructura de árbol.
- Un chat olvida el contexto entre sesiones; un ticket lo conserva.
- Un chat no puede decir «esta tarea está bloqueada por aquella»; un kanban sí.
- Un chat no se relee a sí mismo; un ticket sirve como especificación, registro de ejecución y memoria a largo plazo del proyecto.
El kanban es el formato natural de esta forma de trabajar. Una tarjeta = una intención. Un estado = una situación del trabajo (Por hacer, En curso, Pendiente de revisión, Fallido, Completado). Una columna «En curso» con quince tarjetas ya no es un modo degradado: es el modo normal.
Cómo pueden avanzar quince tickets en paralelo
La pieza que lo hace técnicamente posible son los worktrees de Git. Cada ticket se ejecuta en su propio worktree: una copia aislada del repositorio, en su propia rama, sin interferir con las demás. Quince tickets, quince worktrees, quince ramas. Sin conflictos de estado durante la ejecución.
Al finalizar, cada ticket se integra mediante rebase sobre la rama base antes de reintegrarse. Si la base ha avanzado mientras trabajaba un agente, repetimos las pruebas sobre la versión tras el rebase: es la única forma de evitar que dos tickets que pasan por separado produzcan una integración rota.
Los hooks de Git como red de seguridad
Cuando la IA produce código a gran escala, necesitas redes de seguridad automatizadas . Los hooks de Git se vuelven esenciales: lint, formato, comprobación de tipos, pruebas unitarias; todo se ejecuta en pre-commit. Si falla un hook, falla el commit y el agente diagnostica, corrige y vuelve a intentarlo.
Nada de --no-verify. Nunca. El hook no es una sugerencia: es el contrato con la rama.
¿Qué ocurre si algo se rompe de todos modos?
Ningún sistema es infalible. Cuando un agente se equivoca, cuando una prueba pasa en local pero falla en CI, cuando un despliegue se tuerce, no lo corregimos a mano. Abrimos un ticket. Un ticket que pide a otro agente buscar la causa raíz a lo largo del pipeline. El ADE se convierte en su propia red de seguridad: puede diagnosticarse a sí mismo.
Parece contraintuitivo, pero eso es lo que hace sostenible la orquestación. Sin ese ciclo, vuelves a la trampa clásica de «lo arreglo rápidamente a mano» y pierdes el beneficio de la orquestación en quince minutos.
Dos meses en producción
Este sistema lleva dos meses funcionando. Dos meses en los que construyo Singularity con Singularity. El producto se utiliza a sí mismo a diario, en producción, en un proyecto real con usuarios reales.
La aceleración real ronda las 50× en el trabajo que antes hacía a mano. Y sé que todavía estoy muy por debajo del límite. El límite ya no es mi velocidad al teclear ni mi capacidad para mantener cinco temas en la cabeza a la vez: es la calidad de mis especificaciones. Eso es lo único que sigue siendo 100 % humano.
Preguntas frecuentes
¿Un ADE sustituye por completo a un IDE?
No. Singularity incluye un terminal y un editor de código nativos: puedes intervenir a mano en cualquier momento. El objetivo no es prohibir el código humano, sino hacerlo opcional. La mayor parte del tiempo ya no necesitas hacerlo.
¿Cómo gestiona la IA un ticket mal redactado?
Mal. Precisamente por eso importa la calidad del ticket. Un agente de IA bien orquestado reformula lo que ha entendido antes de ponerse a programar, y tú validas el contrato. Si la reformulación no encaja, la corriges antes de iniciar la ejecución.
¿Qué ocurre cuando dos tickets modifican los mismos archivos?
Cada ticket se ejecuta en su propio worktree, así que la ejecución en sí no produce conflictos. Al reintegrarse, el segundo ticket hace rebase sobre el resultado del primero. Si surge un conflicto, la IA propone una resolución razonada y tú decides.
¿Hasta qué punto puedes confiar en el código generado?
Tanto como confíes en tus hooks y tus pruebas. El código no recibe un pase libre porque lo haya escrito una IA: pasa por las mismas redes de seguridad que cualquier otro código. Si tu conjunto de pruebas es débil, la orquestación lo pondrá de manifiesto rápidamente.
¿Funciona en cualquier proyecto?
Cuanto mejor probado esté el proyecto, más eficaz será la orquestación. En un proyecto sin pruebas, la IA entregará rápido, pero tendrás que revisar más. En un proyecto bien equipado (hooks, CI, pruebas), la relación entre intervención humana e IA favorece la velocidad muy pronto.
Singularity estará disponible pronto
Singularity es la aplicación que construimos para utilizar este ADE a diario. Un cliente nativo para macOS, Windows y Linux.
Para entender la filosofía del producto detrás de todo esto, lee el manifiesto.