Como construí um sistema corporativo auditável em 7 dias com IA (sem vibe coding)

Por André Souza | AI Engineer · Engenheiro de Software Sênior

Existe uma ilusão confortável rondando o mercado de desenvolvimento de software: a ideia de que qualquer pessoa, munida de um modelo de linguagem e de um assistente moderno de código, consegue colocar sistemas corporativos de pé em questão de horas.

Você abre o Claude Code ou o Antigravity, descreve a ideia com entusiasmo, aceita as sugestões automáticas e, no fim do dia, tem telas coloridas funcionando na máquina local.

Só que tela bonita não sustenta operação de negócio.

Quando o sistema precisa conciliar saldo financeiro, manter linha de auditoria forense, impor travas estritas de tolerância contratual e garantir que nenhum dado seja alterado fora de ciclos atômicos, o entusiasmo do vibe coding desmorona no primeiro caso de borda.

Recentemente, enfrentei exatamente esse desafio. Construí o Support Hours Manager (SHM), um sistema corporativo completo para Gestão de Contratos de Suporte e Manutenção de Software. Fiz isso em 7 dias, utilizando agentes de IA para implementar tanto o backend em Django 5.2 quanto o frontend em React 19 com TypeScript.

O SHM não é um gerenciador de chamados simplório. Ele cobre o ciclo operacional de ponta a ponta:

• Gestão de Clientes, Contratos e Pedidos: controle unificado desde a entrada da demanda até a vinculação contratual formal.
• Orçamento, Ciclos de Manutenção e Tarefas: decomposição de pedidos em ciclos atômicos com estimativa de horas e execução detalhada.
• Workflow de Aprovações e Aceites: máquina de estados estrita com Magic Link para aprovações pelo cliente sem atrito.
• Gestão de Horas e Linha de Auditoria Forense: rastreamento imutável de cada apontamento e evento do ciclo.
• Gestão de Saldos Remanescentes ou Déficit: extrato detalhado de controle de horas e conciliação de saldo financeiro do contrato.
• Comunicação e Notificações Configuráveis: mensagens entre usuários no contexto do chamado, com avisos em tempo real no app e por e-mail.
• Pesquisa de Satisfação e Cronjobs de Vistoria: avaliação de entrega pelo cliente e rotinas automáticas de verificação da vigência e consumo contratual.

O resultado não foi um protótipo descartável. Foi uma aplicação consistente em arquitetura desacoplada, com 79 testes automatizados cobrindo cada regra crítica de negócio.

A diferença entre o código que quebra em produção e o software construído para durar dez anos não está na ferramenta de IA. Está no método de engenharia que governa o agente.

O problema real: a sangria invisível dos contratos de suporte

Quem já gerenciou contratos de sustentação de software conhece a dor.

Uma empresa contrata um pacote mensal de 40 horas técnicas. Os chamados chegam por canais diversos: e-mail, mensagens de chat, reuniões de alinhamento. Os técnicos começam a trabalhar, lançam apontamentos soltos e, quando o mês vira, a contabilidade não fecha.

De um lado, o cliente reclama que as horas foram consumidas sem autorização prévia. Do outro, a prestadora descobre que gastou 60 horas em atendimentos emergenciais que nunca foram faturados.

Estudos de governança de serviços apontam que empresas de suporte perdem até 30% da margem líquida por falta de conciliação atômica entre o pedido, o orçamento e a execução das tarefas.

Para resolver isso, o sistema não pode ser um simples gerenciador de chamados. Ele precisa operar como um razão contábil, com regras inegociáveis:

1. Rastreabilidade total: nenhum minuto é debitado sem um ciclo atômico formalmente aprovado pelo cliente.
2. Máquina de estados estrita: um ciclo de trabalho passa por etapas claras: orçado, aguardando aprovação, aprovado, em execução, aguardando aceite e aceito.
3. Trava de tolerância (+30%): o sistema impede apontamentos abusivos acima da estimativa aprovada, bloqueando estouros orçamentários na raiz.
4. Ledger imutável de saldo: o saldo de horas do contrato não é apenas um campo numérico editável no banco de dados. Cada lançamento gera uma entrada histórica vinculada a um pedido, impedindo inconsistências e fraudes operacionais.

Tentar construir regras desse calibre via prompts soltos é receita para o fracasso. Se você pedir a um agente “faça um sistema de gestão de horas com aprovação”, ele vai gerar tabelas genéricas e esquecer as restrições que mantêm o negócio de pé.

O método: SDD e TDD como DNA do Framework Reversa (Prof. Sandeco Macedo)

Para construir o SHM com agentes sem acumular débito técnico, apoiei-me nos fundamentos clássicos de Engenharia de Software consolidados no Framework Reversa, criado pelo professor Sandeco Macedo.

No Reversa, Spec-Driven Development (SDD) e Test-Driven Development (TDD) não são etapas adicionadas por conveniência: são o próprio DNA do framework. Ele opera através de uma esteira orquestrada de agentes especializados, divididos em papéis estritos para transformar regras de negócio em contratos executáveis e código testado:

• Scout (Reconhecimento): mapeia a superfície do sistema, dependências e módulos sem intervenção invasiva.
• Arqueólogo (Escavação): analisa módulo a módulo, catalogando algoritmos, fluxos e dicionário de dados sem emitir julgamentos prematuros.
• Detetive e Arquiteto (Interpretação): o Detetive atua como um investigador forense que desvenda regras de negócio implícitas, matrizes de permissão e máquinas de estado; o Arquiteto sintetiza esses achados em diagramas C4, modelos de entidade-relacionamento (ERD) e decisões de arquitetura.
• Redator (Geração SDD): atua como tabelião do sistema, gerando as especificações formais de SDD por componente e contratos OpenAPI com rastreabilidade total.
• Revisor (Auditoria e Validação): tenta quebrar as especificações, identificando contradições, ambiguidades e lacunas de teste antes que qualquer linha de código definitiva seja consolidada.

Com essa governança, a inteligência artificial não adivinha arquitetura nem improvisa regras financeiras. O agente atua sob especificações compactas e rigorosas:

• PRD funcional: objetivos de negócio, perfis de acesso (RBAC dividindo administradores, técnicos, gerentes e analistas do cliente) e regras financeiras.
• ARCHITECTURE.md: separação estrita entre o backend RESTful e a Single Page Application, padrões de domínio e integridade transacional.
• BUSINESS_RULES.md: 25 regras invariantes do sistema (como a trava que impede técnicos de executarem ciclos não aprovados ou o isolamento de dados entre clientes).

O agente deixa de ser um gerador aleatório de palpites e passa a operar dentro de limites técnicos estritos. Se tentar propor algo fora da especificação, a violação é barrada imediatamente.

TDD na prática: 79 testes que blindam a evolução

O segundo pilar da construção foi o Test-Driven Development (TDD).

Em uma esteira com agentes de IA, o teste automatizado não é um acessório de luxo entregue no final do projeto. Ele é a própria régua que orienta o agente.

O fluxo de trabalho seguiu uma cadência disciplinada:

1. Definição do contrato de teste: para cada regra de negócio do SHM, foi gerado primeiro o caso de teste no Pytest. Por exemplo: um teste que tenta registrar 15 horas em uma tarefa de um ciclo orçado em 10 horas, verificando se o sistema rejeita a transação ao violar a margem de tolerância.
2. Execução em vermelho (Red): rodar o teste e confirmar que ele falha pela razão correta.
3. Implementação mínima (Green): instruir o agente a escrever estritamente o código necessário na camada de serviço ou no modelo Django para satisfazer aquele teste.
4. Refatoração assistida (Refactor): limpar o código, extrair métodos auxiliares e garantir legibilidade sem quebrar nenhum teste anterior.

Ao final dos 7 dias, a suíte somava 79 testes automatizados passando: testes de endpoints de API, fluxos de autenticação, permissões por papel, validação de ledger de saldo e transições da máquina de estados dos ciclos.

Quando precisei refatorar a estrutura de permissões no quarto dia de desenvolvimento para acomodar analistas de clientes com perfil somente leitura, não houve pânico. Rodamos os testes, identificamos duas quebras imediatas em endpoints secundários, corrigimos a camada de autorização e voltamos ao verde em menos de vinte minutos.

Sem testes, essa alteração teria passado despercebida e virado um chamado crítico semanas depois.

A arquitetura técnica do SHM

Para garantir que o sistema não dependesse de infraestrutura proprietária cara, escolhemos uma stack madura, estável e amplamente documentada:

• Backend: Python com Django 5.2 e Django REST Framework. O Django fornece um ecossistema com ORM maduro, migrações determinísticas e autenticação consolidada. A lógica de negócio pesada (máquina de estados, travas de tolerância e lançamentos no ledger) foi concentrada em serviços de domínio desacoplados das views.
• Frontend: React 19 com TypeScript, Tailwind CSS e Vite. A tipagem estrita no TypeScript garantiu que os contratos da API gerados pelo backend fossem respeitados fielmente nas telas operacionais, sem surpresas de campos nulos em tempo de execução.
• Auditoria e Logs: Cada transição de estado de um pedido ou ciclo gera eventos na linha do tempo do chamado, permitindo rastrear quem solicitou, quem aprovou e quem concluiu cada etapa.

Essa escolha técnica comprova outro ponto: você não precisa reinventar a roda ou adotar stacks experimentais para inovar com IA. A maturidade das ferramentas consolidadas é a maior aliada da estabilidade do software.

O novo papel do engenheiro de software

A experiência de construir o SHM em uma semana com agentes deixa uma lição nítida sobre o rumo da nossa profissão.

A digitação de código, que consumia a maior parte da semana de um desenvolvedor, agora é executada em alta velocidade pelos agentes. No entanto, o julgamento técnico, a capacidade de modelar o domínio do problema, a definição de restrições de arquitetura e a governança do processo continuam sendo responsabilidades exclusivamente humanas.

Se você não sabe como projetar uma máquina de estados consistente, a IA não vai projetar por você. Se você não entende as particularidades de isolamento transacional em um banco de dados, o agente criará condições de corrida silenciosas que só vão estourar com múltiplos usuários simultâneos.

O engenheiro de software moderno não concorre com a IA na quantidade de caracteres por minuto. Ele atua como o arquiteto e auditor da esteira, conferindo se cada linha entregue pelo modelo obedece aos requisitos reais do negócio.

Para fechar

A velocidade trazida pelos assistentes de IA é real e transformadora. Mas velocidade sem direção é apenas a aceleração do colapso da sua base de código.

Sistemas que lidam com contratos, finanças e regras complexas exigem integridade, rastreabilidade e testes contínuos. O SHM é a prova viva de que é perfeitamente viável utilizar agentes autônomos para acelerar o desenvolvimento sem abrir mão de uma vírgula do rigor técnico.

O código e a arquitetura do Support Hours Manager (SHM) estão documentados no meu repositório público do GitHub: github.com/andresouza72br-sketch/SHM-Support-Hours-Manager.

Como sua equipe tem equilibrado a velocidade dos agentes com a governança e os testes no dia a dia? Compartilhe sua experiência nos comentários.

André Souza
Engenheiro de Software Sênior · AI Engineer