Ir para o conteúdo principal
AI-Native Software Engineering

Agentes já escrevem código.O desafio agora é fazer engenharia.

Quando a IA participa da implementação, escrever deixa de ser o centro do trabalho. Intenção, contexto, decisões, limites e evidência passam a determinar se o software pode ser confiado e se continua confiável quando o projeto muda.

DOCOD é um método para organizar esse trabalho e um runtime open source para torná-lo executável.

Um desafio prático de engenharia AI-native por dia, direto no seu e-mail.

Raposa cibernética Docod — esquema técnico
FIG. 01 — AGENT FOXAI-NATIVE
2026
O código não é mais o centro

A execução ficou mais barata. A responsabilidade não.

Agentes conseguem implementar, testar, refatorar e revisar partes cada vez maiores de um sistema.

Isso não elimina o trabalho de engenharia. Muda onde ele acontece.

Antes

Você transformava requisitos em código e carregava boa parte do contexto necessário para mantê-lo correto.

Agora

Você precisa tornar intenção, contexto, restrições e critérios explícitos o bastante para que agentes possam executar e produzir evidência suficiente para que o resultado possa ser aceito.

A IA assume mais execução. A engenharia assume mais controle.

Velocidade não é controle

Produzir mais código não resolve o que se perde entre uma decisão e a próxima execução.

  1. Uma especificação muda.
  2. Uma decisão de arquitetura muda.
  3. Um agente entra no projeto. Outro continua o trabalho.
  4. O código muda de novo.

Se intenção, decisões, dependências e evidências não permanecem conectadas, cada nova execução depende de um humano ou de um agente reconstruir o contexto e interpretar novamente o que deveria ser verdade.

É aí que velocidade vira drift.

DOCOD existe para preservar continuidade entre o que foi decidido, o que foi executado e o que foi confirmado.

Um ciclo de engenharia para trabalhar com agentes

Cinco movimentos. Uma responsabilidade que nunca é delegada.

  1. 01

    Definir

    O que precisa ser verdade?

    Transforme intenção em requisitos, decisões, design, contratos, riscos e trabalho que possa ser executado sem depender de contexto implícito.

  2. 02

    Orquestrar

    Quem executa o quê e sob quais condições?

    Coordene agentes, ferramentas, contexto, ambientes e regras para realizar o trabalho decidido.

  3. 03

    Confirmar

    Que evidência prova que o resultado está correto?

    Teste comportamento, revise resultados, confronte critérios e mantenha decisões humanas onde aprovação realmente significa responsabilidade.

  4. 04

    Observar

    O que acontece quando o software encontra a realidade?

    Acompanhe comportamento, falhas, custos, drift e resultados que só aparecem depois da execução.

  5. 05

    [Re]definir

    O que o que aprendemos muda no que havíamos decidido?

    Leve evidência de volta às decisões. Analise impacto, revise o que mudou e inicie o próximo ciclo com um estado melhor que o anterior.

Do princípio à execução

O método diz como o trabalho deve funcionar.O runtime faz o processo deixar rastros.

O DOCOD Method não depende de um modelo, uma IDE ou um agente específico.

Método

O modelo de engenharia por trás dos cinco movimentos.

O DOCOD Runtime é a implementação open source de referência: transforma documentos, decisões, aprovações, tarefas e verificações em um fluxo que pode ser inspecionado pelo projeto, não lembrado por uma conversa.

Runtime

A implementação executável para aplicar o método em projetos reais.

Não confie no processo. Inspecione-o.

Se uma máquina pode verificar, a confiança não precisa depender da palavra de um agente.

No runtime, confiança deixa evidência.

Aprovação pertence ao que foi aprovado
Uma aprovação está ligada ao conteúdo daquela versão. O artefato mudou, a aprovação anterior não finge continuar válida.
Verificação precisa mostrar de onde veio
Não basta declarar que passou. Evidência aponta para o comando, o resultado ou o artefato usado para sustentar a conclusão.
Quem produz não é quem encerra a discussão
Execução e verificação têm responsabilidades diferentes. Produzir uma mudança não concede autoridade para aprová-la.
Mudança upstream tem consequência
Alterar uma decisão anterior exige entender o impacto no que depende dela, ou registrar explicitamente por que esse impacto foi dispensado.

O runtime é open source. Você pode verificar essas regras no código.

Capa do livro AI-Native Software Engineering, de Fabio Valencio

Leia antes de comprar

Receba gratuitamente um capítulo e decida por conta própria se esta abordagem é útil para o seu trabalho.

O livro

AI-Native Software Engineering

Um manual operacional para quem precisa construir software com agentes sem terceirizar a engenharia para eles.

O livro desenvolve a disciplina por trás do DOCOD: como sair de uma intenção ainda ambígua, tomar decisões, organizar execução com agentes, confirmar resultados e aprender com o que acontece depois que o software encontra a realidade.

  • Não é um livro de prompts.
  • Não depende de uma ferramenta específica.
  • É sobre o trabalho de engenharia que permanece quando escrever código deixa de ser a parte difícil.
Edições em português e inglês.Autor Fabio Valencio
R$ 89 / e-book
Daily engineering challenge

Você não consegue confirmar bem aquilo que não sabe avaliar.

Agentes aumentam a quantidade de código que um engenheiro consegue colocar em movimento. Isso torna os fundamentos ainda mais valiosos, e com eles a capacidade de reconhecer quando uma implementação está errada.

O Daily Challenge transforma isso em prática diária.

Um problema por dia. Executável. Com entrada, saída e casos de teste.

Você treina desde fundamentos clássicos até problemas que aparecem quando IA entra no produto, agentes entram no processo e código gerado precisa ser supervisionado.

  • Fundamentos

    Estruturas de dados, algoritmos, estado, concorrência, invariantes e casos de borda.

  • IA no produto

    RAG, busca, evals, observabilidade, custos, guardrails e componentes determinísticos ao redor de modelos.

  • Construir com IA

    Context engineering, agentes, handoffs, decomposição, verificação e coordenação.

  • Onde a IA costuma errar

    Problemas construídos em torno de padrões de erro que parecem corretos até alguém saber exatamente onde olhar.

em-breve.md
Aguardando

Próximo desafio em breve

Estamos preparando o próximo desafio. Ative o loop diário para recebê-lo em primeira mão.

Grátis

Receba o desafio do dia por e-mail. Enunciado, contexto e casos de teste.

O formulário está indisponível no momento. Tente novamente em instantes.

Premium

Vá além de descobrir se sua resposta funciona: solução completa, explicação do raciocínio, alternativas, trade-offs e a análise de onde código gerado por IA costuma falhar naquele problema.

Uma disciplina. Diferentes formas de praticá-la.

Entenda. Treine. Aplique.

Continue acompanhando o que está mudando

Engenharia com agentes ainda está sendo descoberta enquanto é praticada.

Receba novos artigos, decisões, experimentos e atualizações do DOCOD diretamente no seu e-mail.

Sem promessa de mágica. O que aprendermos construindo, testando e colocando o método diante da realidade.

O formulário está indisponível no momento. Tente novamente em instantes.