A CATEGORIA
Sistema Operacional de Engenharia
A camada que faltava entre a sua arquitetura e as ferramentas de IA que o seu time já usa.
atualizado em
Definição
Um Sistema Operacional de Engenharia é a camada de contexto, regras, agentes e conhecimento versionada dentro do repositório, que permite que humanos e agentes de IA operem sob o mesmo contrato. Sem essa camada, a IA lê arquivos isolados e produz código localmente correto, mas sistemicamente incoerente. Com ela, cada geração de código herda a arquitetura, os padrões e as decisões da empresa.
Por que as ferramentas atuais não entendem a sua engenharia
Um assistente de código lê arquivos. Ele vê a função que você abriu, os imports do arquivo e, no melhor caso, alguns vizinhos recuperados por similaridade. O que ele não vê é o que a sua empresa decidiu: por que o domínio de contas não pode importar o de crédito, qual foi a razão de trocar o gateway em 2024, qual das quatro formas de validar um pedido é a canônica.
Nada disso está no código. Está na cabeça de três pessoas, em atas de reunião e em uma wiki que ninguém abre há dez meses. O modelo não tem acesso — e, por não ter, preenche a lacuna com o padrão estatístico mais provável, que é a média da internet, não a sua arquitetura.
Código localmente correto, sistemicamente incoerente
É por isso que a percepção interna de ganho quase nunca sobrevive à medição. Cada desenvolvedor entrega mais rápido, e o sistema fica menos coerente: mais formas de fazer a mesma coisa, mais defeitos na fronteira entre squads, mais tempo de revisão para reconciliar decisões que ninguém registrou.
O ganho é individual e não compõe. A cada trimestre a organização paga de novo o custo de reconciliação, e ele cresce com o time.
Os componentes
| COMPONENTE | NO REPOSITÓRIO | O QUE RESOLVE |
|---|---|---|
| Contexto | ARCHITECTURE.md · CONTEXT.md · context/ | Domínios, fronteiras, glossário e donos. É o que responde "que sistema é este" antes de qualquer geração. |
| Contrato arquitetural | .rules/ | O que pode e o que não pode: camadas, dependências proibidas, limites de domínio, critérios de aceite. |
| Padrões | patterns/ | A forma canônica de resolver cada problema recorrente, extraída do que o time já faz melhor — não imposta de fora. |
| Decisões | decisions/ | ADRs versionados, em formato que um agente consegue indexar. Contexto histórico deixa de morar em ata de reunião. |
| Agentes | agents/ | Escopo, critério de rejeição e regra de escalonamento para humano, por agente. Um agente sem critério escrito gera ruído. |
| Políticas e fluxos | policies/ · workflows/ | Onde a IA entra no pipeline, com que gate e sob qual política de segurança. |
| Conhecimento operacional | runbooks/ · guides/ | Rotina de incidente por serviço e caminho do zero ao primeiro PR, versionados junto ao código que descrevem. |
Como humanos e agentes passam a operar sob o mesmo contrato
O contrato é o mesmo texto para os dois. Um desenvolvedor lê .rules/ para saber o que pode fazer; o agente de revisão lê o mesmo arquivo para saber o que rejeitar. Quando a regra muda, muda em pull request, com revisão — e vale para ambos no mesmo instante.
É isso que diferencia um sistema de uma pilha de documentação: não há duas fontes de verdade a sincronizar, porque só existe uma.
O que entra no repositório
~/seu-repositorio
- + ARCHITECTURE.mddomínios, fronteiras, glossário e donos
- + CONTEXT.mdo que a IA lê antes de gerar qualquer coisa
- + .rules/o contrato arquitetural: o que pode e o que não pode
- + patterns/padrões reutilizáveis extraídos do seu próprio código
- + agents/escopo, critério de rejeição e escalonamento por agente
- + decisions/ADRs versionados, indexáveis por agente
- + runbooks/rotina de incidente por serviço
- + policies/política de segurança e de uso de IA no pipeline
- + workflows/revisão automatizada com gate de merge
O que não é
- Não é uma plataforma — não há software da AIUBY rodando na sua infraestrutura.
- Não é uma metodologia ágil — não muda cerimônia, papel nem cadência do time.
- Não é documentação — documentação descreve; contrato restringe e é verificado no pipeline.
- Não é treinamento — o ganho não depende de as pessoas lembrarem do que aprenderam.
- Não é revenda de ferramenta — nenhuma licença nova é vendida junto.
Relação com AI-native engineering
AI-native engineering é a prática; o Sistema Operacional de Engenharia é o artefato. Uma empresa pratica engenharia AI-native quando os agentes operam dentro da arquitetura — e a forma concreta de conseguir isso é instalar, no repositório, a camada que dá contexto, contrato e critério. Os termos relacionados estão no glossário.
Como é instalado
Em quatro semanas, com escopo e prazo fixos: kickoff, diagnóstico técnico e organizacional, blueprint com mapa de gargalos e roadmap priorizado. O detalhamento semana a semana está na página do AI-Native Transformation Blueprint, e o cálculo dos indicadores está na metodologia.
Perguntas frequentes
- Isso é uma ferramenta que eu instalo?
- Não. O entregável é um conjunto de arquivos de texto versionados no seu próprio repositório: contexto, regras, padrões, decisões, agentes e políticas. Nada roda em servidor da AIUBY e nenhuma dependência nova entra no seu build.
- Qual a diferença para uma Internal Developer Platform?
- Uma IDP resolve catálogo, self-service e caminho dourado para pessoas. Um Sistema Operacional de Engenharia resolve coerência: garante que qualquer geração de código, humana ou por agente, herde a arquitetura, os padrões e as decisões já tomadas. As duas coisas convivem; nenhuma substitui a outra.
- Substitui o Copilot, o Cursor ou o Claude Code?
- Não. Faz essas ferramentas renderem. A ferramenta continua a mesma; o que muda é o repositório que ela lê e o pipeline em que ela opera.
- Serve para qualquer tamanho de time?
- O método se aplica a times de 20 a 300 desenvolvedores, normalmente com múltiplas squads. Abaixo disso, a coerência costuma ser mantida por convivência; acima, o problema muda de natureza e exige estrutura organizacional além da técnica.
- Por que versionar no repositório e não em uma wiki?
- Porque documentação fora do repositório não é lida pelo agente no momento em que ele gera código, e envelhece sem que ninguém perceba. Dentro do repositório, o contexto entra na revisão de pull request como qualquer outra mudança.