A engenharia muda quando quem executa o trabalho deixa de ser apenas humano.
Agentes conseguem escrever, modificar e revisar software numa escala que muda a economia da implementação.
Mas velocidade não remove responsabilidade. Ela aumenta a importância de tornar intenção, decisões, contexto, limites e evidência explícitos o bastante para sobreviver à próxima execução.
DOCOD existe para investigar e operacionalizar essa mudança.
A execução mudou. A disciplina precisa acompanhar.
Requisitos. Design. ADRs. Testes. Revisões. Runbooks. Postmortems.
Nada disso perdeu valor porque agentes começaram a escrever código. O contrário aconteceu. Quando mais da implementação pode ser delegada, aquilo que orienta e confirma essa implementação precisa se tornar mais explícito.
O futuro da engenharia de software não é produzir código mais rápido. É conseguir delegar mais execução sem delegar junto a responsabilidade pelo sistema.
IA não deveria ser uma camada colocada sobre o processo antigo.
Menos esforço na tradução manual de cada decisão para código.
Mais esforço em:
- definir o que precisa ser verdade
- preservar contexto
- explicitar decisões e restrições
- coordenar execução
- confirmar resultados com evidência
- observar o sistema em operação
- aprender sem perder o histórico que levou até ali
É isso que chamamos de AI-Native Software Engineering. Não é um nome novo para escrever código com ajuda de IA. É uma forma de pensar engenharia quando a IA deixa de ser apenas ferramenta e passa a participar da execução.
DOCOD não é uma única ferramenta.
- O livro
- Desenvolve a disciplina, os princípios e o modelo mental.
- O método
- Organiza o trabalho em cinco movimentos: DEFINIR, ORQUESTRAR, CONFIRMAR, OBSERVAR e [re]DEFINIR.
- O runtime
- Explora o que acontece quando partes dessa disciplina deixam de depender apenas de convenção e passam a ter contratos, estado derivado, portões e verificações executáveis.
- Os desafios
- Transformam os fundamentos e os problemas da engenharia AI-native em prática recorrente.
- Os artigos
- Registram ideias, problemas, decisões e aprendizados que merecem ser desenvolvidos publicamente.
Essas partes não existem para formar um catálogo de produtos. São maneiras diferentes de investigar, ensinar, praticar e aplicar a mesma disciplina.
Uma disciplina sobre verificabilidade também precisa poder ser questionada.
Isso é deliberado. O DOCOD não precisa estar certo porque a documentação dele diz que está. O projeto precisa poder ser lido, testado, criticado e melhorado.
A mesma ideia que aparece no runtime vale para o próprio projeto: afirmações são o começo, e evidência é o que permite confiar nelas.
O DOCOD é criado e desenvolvido pela Codenroll Technologies.
O DOCOD é a expressão pública dessa investigação. Método, livro, runtime e recursos podem evoluir.
Como construímos software com agentes sem abrir mão da disciplina que torna software engenharia?
Modelos mudam. Ferramentas mudam. Harnesses mudam.
- Intenção precisa sobreviver à execução.
- Decisões precisam sobreviver à troca de agente.
- Evidência precisa sobreviver à afirmação de quem produziu o trabalho.
As implementações podem mudar. Essa responsabilidade permanece.