O manifesto SliceOps
O framework decision-first e plano de auditoria para engenharia de software AI-first. Equipas multiagente entregam software auditável, não código improvisado.
O problema que estamos a nomear
A indústria passou dois anos a debater se a IA substitui os programadores. É a pergunta errada. A certa é estrutural: como é a engenharia de software quando a maior parte da escrita é feita por agentes e a maior parte do julgamento é feita por humanos?
Os sprints pressupõem humanos presos a standups e compromissos de duas semanas. Os agentes não têm essas amarras: um slice consome cinco milhões de tokens e dez minutos, o seguinte consome sessenta milhões e um dia. Enquadrar essa velocidade em rituais desenhados para trabalhadores de escritório é, em silêncio, um anti-padrão.
O paralelismo multiagente quebra um segundo pressuposto: que um programador mexe numa branch de cada vez. Corra uma dúzia de agentes contra um repositório e, sem dependências explícitas e contadores de decisão atómicos, o paralelismo que devia compor torna-se o paralelismo que entra em conflito.
Tem o git history e tem esperança. Isso não é um rasto de auditoria.
A tese
O SliceOps é o framework aberto e plano de auditoria para engenharia de software AI-first. Não é um editor de código. Não é um agente autónomo. Não é uma ferramenta de qualidade de código nem uma plataforma de compliance post-hoc. É a camada que se situa acima de todas elas.
Se o Cursor, o Claude Code, o Devin e o Copilot são os runtimes dos agentes, o SliceOps é o que corre por cima: o ledger de decisões, a unidade de atomicidade, o grafo de dependências e o plano de auditoria que tornam toda a stack legível para um revisor humano, um auditor regulatório ou o próximo agente que entra de novo.
É aberto por design. O framework vive em markdown, as ferramentas vivem em Python e TypeScript, as regras vivem em CI. Sem vendor lock-in. Qualquer um o pode adotar. Qualquer um pode fazer fork.
Quatro pedras angulares
As decisões são flat-numbered, imutáveis, machine-readable
Cada decisão arquitetónica é um Decision Record com um contador plano que incrementa atomicamente em todo o repositório. Cada um carrega frontmatter que mapeia para um modelo de entidades cognitivas sobre o qual os agentes conseguem raciocinar, e o CI rejeita qualquer PR que viole o schema. ADRs, com a disciplina que sobrevive às colisões multiagente.
Stage > Sprint
Um Stage é uma vista temporal derivada do grafo de dependências do trabalho que está pronto para correr agora. Não é time-boxed nem se compromete numa cerimónia. Quando o slice mais longo do Stage termina, o Stage fecha e abre o seguinte. A diferença entre um calendário e um caminho crítico.
O slice é atómico, um chat, um PR
Um slice é a menor unidade executável: independente, testável, útil. Um slice equivale a um chat equivale a um pull request. O rasto de auditoria é o chat, mais o diff, mais a aprovação do merge. Se não está no slice, não aconteceu. Os slices dimensionam-se em tokens, não em story points: determinístico e cross-model.
Os postmortems e os insights são training data
Cada incidente torna-se um postmortem; cada padrão recorrente torna-se um insight record. Quando um novo agente entra no repositório, esses artefactos impedem-no de repetir erros conhecidos. A memória é durável, inspecionável e partilhada entre agentes e humanos, não trancada dentro de um modelo.
O plano de auditoria
É aqui que o SliceOps mais difere de tudo o resto. O SonarQube audita o código. As ferramentas de runtime auditam a execução. O Vanta e o Drata auditam a empresa, depois do facto. O Credo AI audita modelos. Tudo necessário. Nenhum deles audita o plano acima do código.
Esse plano é a integridade da decisão arquitetónica: o slice foi consistente com a spec da secção? A spec foi consistente com o plano? As decisões citadas são as que de facto governam a alteração? Surgiu uma contradição cross-slice que tenha de se resolver?
É o plano que decide se o software produzido por agentes em escala é um sistema mantível ou uma bomba de dívida. É o plano que mais ninguém está a observar, e o que o SliceOps coloca no editor do programador em vez de num dashboard de compliance.
Porque é que isto funciona mesmo com agentes sem memória
A engenharia de software clássica guardava o contexto na cabeça das pessoas. Os agentes de IA não têm memória, cada sessão arranca a frio. Por isso o SliceOps trata o próprio corpus como o seu contexto partilhado: fundamentos, decisões, arquitetura e especificações tornam-se uma única fonte de verdade governada, encaminhada a cada agente conforme a necessita e coerente entre todos eles.
O SliceOps chama a isto Disciplina de contexto, e é a parte que nenhum SDLC clássico precisou: os humanos carregavam o contexto na cabeça; os agentes sem memória não podem. Sem ela, os slices atómicos, o plano de auditoria e a aprendizagem recursiva fraturam-se, porque cada agente estaria a trabalhar a partir de uma imagem diferente e à deriva do sistema.
Compliance-ready por construção
Há uma expressão que vale a pena reformar (compliance theater) e uma que vale a pena instalar no seu lugar: compliance-ready por construção.
Quando adota o SliceOps, cada decisão arquitetónica é um registo que mapeia para um controlo da ISO 42001, um critério SOC 2 ou um requisito de documentação da EU AI Act. Não escreve estes documentos porque vem aí um auditor. Escreve-os porque são o framework. Quando o auditor chega, exporta o ledger e está feito.
O Artigo 50 da EU AI Act entra em vigor a 2 de agosto de 2026. A ISO 42001 já é um gate de procurement. O roadmap de conformidade não é um workstream à parte: é o que acontece quando entrega slices.
A prova
O SliceOps não foi desenhado numa sessão de whiteboard. Foi extraído da realidade de produção de construir a Datta (um produto cross-industry para mercados regulados) com uma equipa pequena e uma frota de agentes Claude Code, medido por tempo de execução, não por calendário.
Mais de 800 Decision Records, flat-numbered e lifecycle-tracked. Um bloco entregue em quatro dias de calendário ao longo de nove slices atómicos, abaixo do seu forecast de tokens, com 41 decisões arquitetónicas capturadas. Até treze agentes a correr em paralelo contra um repositório. Um multiplicador de eficiência de 2.5×, medido contra o consumo equivalente de tokens via API.
Isto é dogfooding. O SliceOps é o sistema em que confio o suficiente para apostar nele um spin-off de banca regulada.
O que isto significa para si
Se é founder a entregar com uma equipa pequena e ferramentas de IA
Esta é a peça em falta entre “o Cursor escreveu o meu CRUD” e “temos um sistema que conseguimos auditar”. A credibilidade assenta nos artefactos, não nas credenciais.
Se é CTO numa indústria regulada
Isto é o que transforma o seu investimento em IA de passivo em evidência: o rasto que a EU AI Act e a ISO 42001 exigem, produzido como subproduto de entregar software.
Se é tech lead a orquestrar vários agentes
Esta é a disciplina que transforma N agentes em N vezes a velocidade em vez de N vezes os conflitos. O DAG, os contadores atómicos, a atomicidade do slice. Nada disto é opcional. Tudo compõe.
O convite
Experimente o framework num único slice do seu próximo sprint. Declare um decision record para uma decisão que teria tomado informalmente. Corra um forecast no início do seu próximo bloco e um retrospective no fecho. Veja como se sentem os artefactos, e o que os seus agentes fazem com eles quando os leem.
Construa com disciplina. Audite as suas decisões. Trate os seus agentes como os engenheiros industriais tratam as suas máquinas: com telemetria, retrospetiva e o pressuposto de que aquilo que não se mede acaba por partir.
Entregue com agentes. Audite por construção.