El manifiesto SliceOps
El framework decision-first y plano de auditoría para la ingeniería de software AI-first. Los equipos multi-agente envían software auditable, no código improvisado.
El problema que estamos nombrando
La industria pasó dos años debatiendo si la IA reemplaza a los developers. Es la pregunta equivocada. La correcta es estructural: ¿cómo se ve la ingeniería de software cuando la mayoría del typing lo hacen agentes y la mayoría del juicio lo hacen humanos?
Los sprints asumen humanos atados a standups y compromisos de dos semanas. Los agentes no tienen esas ataduras: un slice toma cinco millones de tokens y diez minutos, el siguiente toma sesenta millones y un día. Encajar esa velocidad en rituales diseñados para oficinistas es, en silencio, un anti-patrón.
El paralelismo multi-agente rompe una segunda suposición: que un developer toca una rama a la vez. Corre una docena de agentes contra un repositorio y, sin dependencias explícitas ni contadores de decisión atómicos, el paralelismo que debería componer se vuelve el paralelismo que conflictúa.
Tienes git history y tienes esperanza. Eso no es un rastro de auditoría.
La tesis
SliceOps es el framework abierto y plano de auditoría para la ingeniería de software AI-first. No es un editor de código. No es un agente autónomo. No es una herramienta de calidad de código ni una plataforma de compliance post-hoc. Es la capa que se sitúa por encima de todas ellas.
Si Cursor, Claude Code, Devin y Copilot son los runtimes de los agentes, SliceOps es lo que corre encima: el ledger de decisiones, la unidad de atomicidad, el grafo de dependencias y el plano de auditoría que hace todo el stack legible para un revisor humano, un auditor regulatorio o el próximo agente que entra fresco.
Es abierto por diseño. El framework vive en markdown, las herramientas en Python y TypeScript, las reglas en CI. Sin vendor lock-in. Cualquiera puede adoptarlo. Cualquiera puede forkearlo.
Cuatro piedras angulares
Las decisiones son flat-numbered, inmutables, machine-readable
Cada decisión arquitectónica es un Decision Record con un contador plano que incrementa atómicamente en todo el repositorio. Cada uno carga frontmatter que mapea a un modelo de entidades cognitivas que los agentes pueden razonar, y CI rechaza cualquier PR que viole el schema. ADRs, con la disciplina que sobrevive a las colisiones multi-agente.
Stage > Sprint
Un Stage es una vista temporal derivada del grafo de dependencias del trabajo que está listo para correr ahora. No es time-boxed ni se compromete en una ceremonia. Cuando el slice más largo del Stage termina, el Stage se cierra y abre el siguiente. La diferencia entre un calendario y un camino crítico.
El slice es atómico, un chat, un PR
Un slice es la unidad mínima ejecutable: independiente, testeable, útil. Un slice equivale a un chat equivale a un pull request. El rastro de auditoría es el chat, más el diff, más la aprobación del merge. Si no está en el slice, no pasó. Los slices se dimensionan en tokens, no en story points: determinístico y cross-model.
Los postmortems y los insights son training data
Cada incidente se vuelve un postmortem; cada patrón recurrente se vuelve un insight record. Cuando un nuevo agente entra al repositorio, esos artefactos le impiden repetir errores conocidos. La memoria es durable, inspectable y compartida entre agentes y humanos, no encerrada dentro de un modelo.
El plano de auditoría
Aquí es donde SliceOps más difiere de todo lo demás. SonarQube audita código. Las herramientas de runtime auditan la ejecución. Vanta y Drata auditan a la empresa, después del hecho. Credo AI audita modelos. Todo necesario. Ninguno audita el plano por encima del código.
Ese plano es la integridad de decisión arquitectónica: ¿el slice fue consistente con la spec de la sección? ¿La spec fue consistente con el plan? ¿Las decisiones citadas son las que efectivamente gobiernan el cambio? ¿Surgió una contradicción cross-slice que haya que resolver?
Es el plano que decide si el software producido por agentes a escala es un sistema mantenible o una bomba de deuda. Es el plano que nadie más está mirando, y el que SliceOps pone en el editor del developer en vez de en un dashboard de compliance.
Por qué esto funciona con agentes sin memoria
La ingeniería de software clásica guardaba el contexto en la cabeza de las personas. Los agentes de IA no tienen memoria, cada sesión arranca en frío. Así que SliceOps trata el corpus mismo como su contexto compartido: fundamentos, decisiones, arquitectura y especificaciones se vuelven una única fuente de verdad gobernada, enrutada a cada agente según la necesita y coherente entre todos ellos.
SliceOps llama a esto Disciplina de contexto, y es la parte que ningún SDLC clásico necesitó: los humanos cargaban el contexto en su cabeza; los agentes sin memoria no pueden. Sin ella, los slices atómicos, el plano de auditoría y el aprendizaje recursivo se fracturan, porque cada agente trabajaría desde una imagen distinta y a la deriva del sistema.
Compliance-ready por construcción
Hay una frase que vale la pena retirar (compliance theater) y una que vale la pena instalar en su lugar: compliance-ready por construcción.
Cuando adoptas SliceOps, cada decisión arquitectónica es un registro que mapea a un control ISO 42001, un criterio SOC 2 o un requerimiento de documentación de la EU AI Act. No escribes estos documentos porque viene el auditor. Los escribes porque son el framework. Cuando viene el auditor, exportas el ledger y listo.
El Artículo 50 de la EU AI Act entra en vigor el 2 de agosto de 2026. ISO 42001 ya es un gate de procurement. El roadmap de cumplimiento no es un workstream aparte: es lo que pasa cuando envías slices.
La prueba
SliceOps no se diseñó en una sesión de whiteboard. Se extrajo de la realidad de producción de construir Datta (un producto cross-industry para mercados regulados) con un equipo pequeño y una flota de agentes Claude Code, medido por tiempo de ejecución, no por calendario.
Más de 800 Decision Records, flat-numbered y lifecycle-tracked. Un bloque enviado en cuatro días calendario a través de nueve slices atómicos, bajo su forecast de tokens, con 41 decisiones arquitectónicas capturadas. Hasta trece agentes corriendo en paralelo contra un repositorio. Un multiplicador de eficiencia de 2.5×, medido contra el consumo equivalente de tokens vía API.
Esto es dogfooding. SliceOps es el sistema en el que confío lo suficiente para apostar un spin-off de banking regulado.
Lo que esto significa para ti
Si eres founder enviando con un equipo pequeño y herramientas de IA
Esta es la pieza faltante entre “Cursor escribió mi CRUD” y “tenemos un sistema que podemos auditar”. La credibilidad descansa en los artefactos, no en las credenciales.
Si eres CTO en una industria regulada
Esto es lo que convierte tu inversión en IA de pasivo en evidencia: el rastro que la EU AI Act e ISO 42001 exigen, producido como subproducto de enviar software.
Si eres tech lead orquestando varios agentes
Esta es la disciplina que convierte N agentes en N veces la velocidad en vez de N veces los conflictos. El DAG, los contadores atómicos, la atomicidad del slice. Nada de eso es opcional. Todo compone.
La invitación
Prueba el framework en un solo slice de tu próximo sprint. Declara un decision record para una decisión que hubieras tomado informalmente. Corre un forecast al inicio de tu próximo bloque y un retrospective al cierre. Mira cómo se sienten los artefactos, y lo que tus agentes hacen con ellos cuando los leen.
Construye con disciplina. Audita tus decisiones. Trata a tus agentes como los ingenieros industriales tratan a sus máquinas: con telemetría, retrospect y la suposición de que lo que no se mide eventualmente se rompe.
Envía con agentes. Audita por construcción.