AI ENGINEERING TRANSFORMATION FRAMEWORK
Quatro pilares, na ordem em que sustentam um ao outro
O framework organiza a transformação em quatro camadas. Cada uma resolve um problema distinto, e nenhuma funciona sozinha: workflow sem contexto gera código rápido e incoerente; conhecimento sem workflow vira documentação que ninguém lê.
atualizado em
Por que quatro e não um
A tentação é começar pelo workflow, porque é onde o ganho aparece primeiro. O problema é que um workflow com IA sobre um repositório que a IA não entende produz volume, não capacidade: mais código gerado, mais revisão humana, mais decisão contraditória entre squads.
Por isso a arquitetura do repositório vem antes. Ela é o que dá ao workflow um contrato para respeitar, ao AI DevOps um critério para avaliar, e à camada de conhecimento um lugar para existir. A ordem abaixo é a ordem de instalação — e é a mesma que a instalação em um repositório segue.
AI-Native Repository Architecture
01O repositório é reorganizado para que humanos e agentes compreendam o sistema — e não apenas arquivos isolados.
O que passa a existir
- contexto central do projeto
- descrição dos domínios
- regras arquiteturais versionadas
- padrões de engenharia reutilizáveis
- decisões técnicas registradas
- agentes especializados
- skills de desenvolvimento
- regras por linguagem e tecnologia
- documentação integrada ao repositório
- instruções sobre testes, segurança e deploy
Resultado esperado
- maior consistência nas implementações
- redução de decisões contraditórias
- onboarding mais rápido
- menos dependência de conhecimento individual
- geração de código mais alinhada com a arquitetura
AI Engineering Workflow
02A IA deixa de ser ferramenta usada ocasionalmente e passa a ocupar um lugar definido no ciclo de desenvolvimento.
O que passa a existir
- análise de requisitos
- planejamento de implementação
- decomposição de tarefas
- geração assistida de código
- criação de testes
- revisão automática de pull requests
- análise arquitetural e de impacto
- investigação de regressões
- geração e atualização de documentação
- preparação de releases
Resultado esperado
- aumento da capacidade de entrega
- redução de retrabalho
- maior cobertura de testes
- melhoria na qualidade das revisões
- ciclos de desenvolvimento mais previsíveis
AI DevOps
03A mesma camada se estende para entrega, operação e confiabilidade — onde o custo de um erro é maior e o tempo de investigação, mais caro.
O que passa a existir
- validação automática de código
- análise de segurança e de qualidade
- pipelines de CI/CD instrumentados
- análise de logs e investigação de incidentes
- identificação de padrões de falha
- verificação de configurações
- geração de runbooks
- apoio em rollback e recuperação
- análise de custos de infraestrutura e de modelos
Resultado esperado
- redução de falhas operacionais
- menor tempo de investigação
- maior observabilidade
- deploys mais consistentes
- redução do tempo médio de recuperação
AI Knowledge Layer
04O conhecimento da organização vira camada estruturada e acessível — para as pessoas e para os agentes, com o mesmo ciclo de revisão do código.
O que passa a existir
- documentação arquitetural
- decisões técnicas versionadas
- glossário do domínio
- mapas de sistemas
- runbooks operacionais
- guias de desenvolvimento
- históricos de incidentes
- políticas de segurança
- documentação de APIs e integrações
Resultado esperado
- redução da dependência de pessoas específicas
- preservação do conhecimento
- onboarding mais rápido
- continuidade operacional
- decisões mais consistentes entre times
Do que o harness é feito
O modelo de linguagem é uma parte pequena da solução. O que faz diferença é o que está ao redor dele — o conjunto que chamamos de harness. São cinco tipos de artefato, todos em texto, todos versionados junto ao código que descrevem.
- Agents
- Subagentes com responsabilidade delimitada: arquitetura, planejamento, segurança, testes, revisão, documentação, banco de dados, infraestrutura.
- Skills
- Fluxos estruturados que descrevem como executar uma atividade — planejar uma funcionalidade, implementar com TDD, revisar um pull request, investigar uma vulnerabilidade.
- Rules
- Diretrizes permanentes que orientam o comportamento dos agentes: padrões de código, convenções, restrições arquiteturais, políticas de segurança.
- Hooks
- Automações disparadas por evento — antes ou depois de editar arquivos, executar comandos, finalizar tarefas, iniciar sessões, commitar ou rodar testes.
- MCP
- Integrações que permitem aos agentes consultar e operar ferramentas externas: repositórios, issues, bancos de dados, observabilidade, APIs internas.
Independência de fornecedor
Contexto, regras, padrões e decisões são arquivos de texto versionados no seu repositório. Trocar de assistente de código não obriga a refazer o trabalho — o que muda é quem lê os arquivos, não os arquivos. Não temos relação comercial com nenhum fornecedor de modelo ou de ferramenta.
O catálogo é público
Os artefatos que instalamos — agentes, skills, rules e hooks — estão em repositório público sob licença MIT. Dá para ler tudo antes de conversar com a gente, e dá para instalar por conta própria.
O que a AIUBY faz não é entregar os arquivos: é fazer com que eles descrevam a sua arquitetura. O catálogo, as contagens atuais e o caminho de instalação estão em Aiuby Engineering Framework.
O que este framework não é
Não é um produto que você instala e liga. O catálogo aberto é genérico por construção — ele descreve como um agente de revisão deve trabalhar, não como o seu agente deve tratar a sua fronteira de domínio. Sem esse segundo passo, é configuração, não transformação.
A leitura da categoria está em Sistema Operacional de Engenharia, o vocabulário completo no glossário, e a forma de contratar em serviços.