Codecon 2026: IA, SDD, arquitetura e agentes de código

Participar da Codecon 2026 trouxe uma constatação importante: o impacto da inteligência artificial no desenvolvimento de software vai muito além da capacidade de gerar código mais rápido.

Estamos entrando em uma fase em que escrever código deixa de ser o principal gargalo. O desafio passa a ser estruturar corretamente o problema, fornecer contexto de qualidade, projetar a arquitetura, controlar a execução dos agentes, validar o resultado e manter o sistema compreensível ao longo do tempo.

Durante o evento acompanhei palestras sobre bancos de dados, arquitetura para aplicações com IA generativa, Spec Driven Development, qualidade estrutural de software, observabilidade e desenvolvimento assistido por agentes.

Algumas ideias confirmaram práticas que eu já vinha utilizando em projetos da Ad Rock Digital Mkt. Outras mostraram pontos claros de evolução.

O resultado foi uma visão mais estruturada sobre como pretendo trabalhar com desenvolvimento assistido por IA daqui para frente.

IA não elimina engenharia de software

Uma das ideias que mais apareceram durante o evento foi que integrar um Large Language Model não transforma automaticamente uma aplicação em um sistema de IA bem projetado.

Na palestra "Você Não Precisa de um Time de IA: Padrões de Arquitetura para Devs Construindo com GenAI", apresentada por Victor Shinga, um dos pontos centrais foi exatamente a arquitetura existente ao redor do modelo.

Uma aplicação com IA pode envolver:

• APIs;

• bancos de dados;

• filas;

• autenticação;

• regras de negócio;

• sistemas de cache;

• RAG;

• embeddings;

• ferramentas externas;

• observabilidade;

• políticas de segurança;

• gerenciamento de contexto;

• controle de custos;

• mecanismos de fallback.

Nesse cenário, o LLM é apenas um componente.

Essa visão é especialmente importante porque muitos projetos começam com uma abordagem muito simplificada:

"Vamos adicionar IA."

Na prática, a pergunta deveria ser:

"Qual problema estamos tentando resolver e qual arquitetura precisamos construir para que a IA participe desse processo de forma confiável?"

Essa diferença muda completamente a maneira de projetar o sistema.

O código está ficando mais barato. A arquitetura não.

Com ferramentas como Codex, Claude Code, Cursor e outros agentes, gerar dezenas ou centenas de linhas de código tornou-se relativamente fácil.

Isso cria um risco novo.

É possível produzir rapidamente uma aplicação que funciona, mas cuja estrutura se deteriora a cada nova feature.

A palestra "A Segunda Coisa Mais Importante do Universo", de Klaus Wuestefeld, trouxe uma reflexão importante sobre estrutura, complexidade e manutenção de software.

Um agente pode implementar corretamente uma funcionalidade e, ainda assim, piorar a arquitetura.

Por isso, uma regra que pretendo reforçar nos projetos é:

não basta o código funcionar. Ele precisa continuar fazendo sentido dentro da arquitetura do sistema.

Isso significa prestar atenção a aspectos como:

• separação de responsabilidades;

• acoplamento;

• duplicação;

• limites entre componentes;

• estrutura de diretórios;

• contratos entre módulos;

• complexidade crescente;

• dívida técnica.

Com agentes escrevendo cada vez mais código, revisar a estrutura pode se tornar mais importante do que revisar cada linha individualmente.

SDD: especificação antes da implementação

Outro tema muito relevante foi Spec Driven Development, ou SDD.

Na palestra "Desafios e aprendizados do SDD", apresentada por Kenzo Yuri, Staff Engineer no Mercado Eletrônico, ficou clara a importância de tornar a especificação uma parte efetiva do processo de desenvolvimento.

Essa abordagem conversa diretamente com algo que já venho utilizando em projetos através do Spec Kit.

Em vez de começar uma implementação com um prompt genérico como:

"Crie essa funcionalidade."

o fluxo passa a ser algo mais próximo de:

Problema → Especificação → Plano → Tarefas → Implementação → Validação

A principal evolução que pretendo fazer está na granularidade dessas especificações.

Specs excessivamente grandes podem acabar criando outro problema: contexto demais.

Por isso, uma alternativa melhor é trabalhar com unidades menores e independentes.

Por exemplo, em vez de uma única especificação enorme para um sistema:

• Spec 001: autenticação;

• Spec 002: camada de persistência;

• Spec 003: API;

• Spec 004: integração externa;

• Spec 005: observabilidade.

Cada uma deve possuir objetivo claro, critérios de aceite e limites de implementação.

Checkpoints commitáveis e reversíveis

Uma anotação específica da palestra sobre SDD provavelmente será incorporada diretamente à minha metodologia de trabalho:

trabalhar com checkpoints commitáveis e reversíveis.

A ideia é simples.

Uma tarefa executada por um agente não deveria produzir um enorme bloco de modificações difíceis de revisar.

Ela deveria resultar em um estado consistente do projeto.

Esse estado precisa ser:

• verificável;

• testável;

• commitável;

• compreensível;

• reversível.

Se algo der errado posteriormente, deve ser possível identificar claramente qual alteração introduziu o problema e voltar ao estado anterior sem destruir outras partes do trabalho.

Git deixa de ser apenas controle de versão e passa a funcionar também como mecanismo de controle da execução dos agentes.

Esse modelo reduz significativamente o risco de permitir que uma IA faça alterações extensas em um projeto sem checkpoints intermediários.

A janela de contexto também precisa ser gerenciada

Outro aprendizado muito prático envolve algo que nem sempre recebe atenção suficiente: a janela de contexto dos agentes.

Durante projetos longos, é fácil manter uma única conversa com Codex ou outro agente durante tempo demais.

O problema é que a sessão começa a acumular:

• decisões antigas;

• tentativas descartadas;

• logs;

• arquivos analisados;

• código;

• erros;

• correções;

• instruções;

• mudanças de arquitetura.

Mesmo com mecanismos automáticos de compactação de contexto, existe o risco de informações importantes perderem prioridade ou serem resumidas excessivamente.

Uma prática que pretendo adotar é evitar trabalhar constantemente próximo do limite da janela.

Como referência operacional, faz sentido tentar manter a sessão abaixo de aproximadamente 70% da capacidade de contexto.

Antes de ultrapassar esse ponto, o agente deve produzir um arquivo de handoff.

Por exemplo:

HANDOFF.md

Esse documento pode registrar:

• objetivo do projeto;

• estado atual;

• arquitetura;

• decisões tomadas;

• tarefas concluídas;

• commits relevantes;

• tarefa atual;

• pendências;

• próximos passos;

• riscos conhecidos;

• arquivos importantes;

• testes executados.

Depois disso, uma nova sessão pode ser iniciada utilizando esse documento como contexto inicial.

Em vez de manter uma conversa infinita, o projeto passa por ciclos controlados de contexto.

Contexto passa a ser infraestrutura

Isso leva a uma conclusão maior.

Em desenvolvimento assistido por IA, contexto não é apenas uma conversa.

Contexto passa a fazer parte da infraestrutura do projeto.

Arquivos como estes começam a assumir funções importantes:

AGENTS.md

CLAUDE.md

HANDOFF.md

SPEC.md

ADR.md

README.md

documentação de arquitetura e decisões técnicas.

Eles ajudam diferentes agentes e diferentes sessões a reconstruir rapidamente o estado mental necessário para trabalhar no projeto.

O código continua sendo importante, mas a documentação passa também a servir diretamente como memória operacional para máquinas.

Spec Kit e Superpowers não precisam competir

Durante a Codecon também conheci melhor o Superpowers, projeto open source que implementa uma metodologia baseada em skills para agentes de código.

Inicialmente, ele parece semelhante ao Spec Kit.

Depois de analisar melhor, percebi que eles podem ocupar camadas diferentes.

O Spec Kit está mais relacionado a o que deve ser construído.

Ele ajuda a estruturar:

Spec → Plan → Tasks → Implement

O Superpowers atua mais sobre como o agente deve trabalhar.

Ele adiciona práticas como:

• brainstorming antes da implementação;

• planejamento estruturado;

• Git worktrees;

• Test Driven Development;

• debugging sistemático;

• subagentes;

• revisão de código;

• verificação antes da conclusão;

• fechamento controlado de branches.

Isso abre uma possibilidade interessante:

Spec Kit para especificação + Superpowers para disciplina de execução.

Em vez de escolher uma ferramenta ou outra, pretendo testar como elas podem funcionar juntas.

Evidência antes de declarar uma tarefa concluída

Esse é outro princípio que merece ser reforçado.

Modelos generativos frequentemente respondem algo como:

"Implementação concluída com sucesso."

Mas afirmar que algo funciona não significa que aquilo realmente funciona.

Uma metodologia de desenvolvimento com agentes precisa exigir evidências.

Antes de encerrar uma tarefa:

• executar testes;

• executar linters;

• validar build;

• verificar erros;

• analisar mudanças;

• conferir critérios de aceite;

• revisar o diff;

• confirmar comportamento esperado.

O agente precisa demonstrar que a implementação está correta.

Esse conceito aparece fortemente no Superpowers e faz bastante sentido para qualquer fluxo profissional utilizando IA.

Sistemas precisam ser projetados para serem investigados

Outra palestra importante foi "Além do diagrama de caixinhas: Projetando sistemas que você consegue investigar", apresentada por Alex Rios, Principal Engineer na Memed.

Um diagrama arquitetural pode mostrar:

API Gateway → Serviço → Fila → Worker → Banco de Dados

Isso explica estruturalmente o sistema.

Mas existe outra pergunta:

quando algo quebrar, conseguiremos descobrir o que aconteceu?

Essa é uma pergunta completamente diferente.

Sistemas precisam ser projetados não apenas para funcionar, mas também para serem investigados.

Isso envolve:

• logs estruturados;

• métricas;

• traces;

• correlation IDs;

• contexto de requisições;

• monitoramento;

• alertas;

• histórico de processamento.

Observabilidade não deveria ser uma camada adicionada depois que o sistema entra em produção.

Ela deveria fazer parte da arquitetura.

Uma pergunta que pretendo incorporar às revisões arquiteturais é:

quando este fluxo falhar em produção, teremos informação suficiente para descobrir rapidamente o que aconteceu?

Se a resposta for não, existe uma deficiência arquitetural.

Bancos de dados continuam sendo decisões de arquitetura

Uma das palestras que acompanhei também revisitou conceitos fundamentais de sistemas distribuídos: ACID, BASE e CAP.

ACID representa propriedades tradicionalmente associadas a transações confiáveis:

• Atomicidade;

• Consistência;

• Isolamento;

• Durabilidade.

BASE aparece frequentemente associado a sistemas distribuídos que priorizam disponibilidade e aceitam consistência eventual:

• Basically Available;

• Soft State;

• Eventual Consistency.

Já o Teorema CAP ajuda a entender o trade-off existente entre:

• Consistency;

• Availability;

• Partition Tolerance.

A reflexão mais importante não está em escolher "SQL ou NoSQL".

Está em entender quais garantias o sistema realmente precisa.

Uma plataforma financeira possui requisitos diferentes de um sistema de analytics.

Uma ferramenta colaborativa pode aceitar consistência eventual em determinadas operações.

Um pipeline de eventos pode favorecer disponibilidade.

Um sistema crítico de pagamentos provavelmente terá requisitos fortes de consistência em operações específicas.

A tecnologia deveria ser consequência dessas decisões, não o ponto de partida.

RAG não é apenas embeddings

Outra reflexão que surgiu durante o evento foi aplicada diretamente a um projeto que estou desenvolvendo relacionado ao GA4.

Quando construímos sistemas RAG, é comum pensar principalmente em:

documento → chunks → embeddings → banco vetorial

Mas o conteúdo vetorial é apenas uma parte da informação necessária.

Os chunks deveriam carregar metadados úteis.

Por exemplo:

• origem;

• propriedade;

• período;

• categoria;

• dimensão;

• métrica;

• versão;

• timestamp de ingestão;

• identificador da fonte.

Esses metadados podem melhorar:

• filtragem;

• retrieval;

• reranking;

• rastreabilidade;

• explicabilidade;

• citações.

Em sistemas que trabalham com dados analíticos, isso é especialmente importante.

Sem contexto suficiente, dois chunks semanticamente semelhantes podem representar propriedades, métricas ou períodos completamente diferentes.

Ferramentas também podem simplificar a infraestrutura

Além das palestras, conheci algumas ferramentas interessantes durante o evento.

Uma delas foi a Resend, plataforma voltada ao envio programático de e-mails.

Ela pode fazer sentido em sistemas que precisam de:

• confirmação de cadastro;

• recuperação de senha;

• notificações;

• alertas;

• e-mails transacionais;

• automações;

• comunicação disparada por agentes.

A ideia aqui não é adicionar mais uma ferramenta à stack indiscriminadamente.

O aprendizado é outro: avaliar serviços especializados que eliminam infraestrutura que não representa diferencial competitivo para o projeto.

Se enviar e-mail não é o problema central do produto, provavelmente não faz sentido construir um sistema inteiro para fazer isso.

O que mudou na minha visão depois da Codecon

O evento não alterou completamente minha forma de trabalhar.

Na verdade, boa parte das palestras validou práticas que já vinha adotando em projetos envolvendo ChatGPT, Codex, Claude e outras ferramentas.

Mas algumas práticas ficaram mais claras e precisam ser formalizadas.

O fluxo que pretendo evoluir se aproxima disto:

Problema → Discovery → Spec → Arquitetura → Plano → Tarefas → Implementação → Testes → Checkpoint → Commit → Observabilidade → Handoff

A IA participa de várias dessas etapas.

Mas ela não deveria controlar sozinha o processo inteiro.

O objetivo é combinar velocidade de agentes com disciplina de engenharia.

Um AI Engineering Workflow para a Ad Rock

Uma das principais conclusões do evento foi a necessidade de transformar essas práticas em uma metodologia reutilizável.

Hoje algumas dessas regras existem em documentos, prompts, instruções e hábitos de trabalho.

A ideia agora é consolidá-las em um projeto específico:

adrockmkt/ai-engineering-playbook

Esse repositório poderá funcionar como fonte de verdade para a metodologia de desenvolvimento assistido por IA da Ad Rock.

Uma possível estrutura seria:

AI_ENGINEERING_WORKFLOW.md

templates/AGENTS.md

templates/CLAUDE.md

templates/HANDOFF.md

templates/SPEC.md

templates/ADR.md

checklists/

A metodologia poderá ser utilizada independentemente do agente.

ChatGPT pode ajudar em discovery, análise e arquitetura.

Spec Kit pode organizar especificações.

Codex ou Claude Code podem executar partes da implementação.

Superpowers pode disciplinar o workflow do agente.

Git fornece checkpoints e reversibilidade.

Testes fornecem evidência.

Observabilidade permite investigar o sistema em produção.

A ferramenta pode mudar.

O processo permanece.

O principal aprendizado

Depois de acompanhar diferentes palestras da Codecon 2026, minha principal conclusão foi esta:

quanto mais fácil fica gerar código, mais importante fica a engenharia ao redor dele.

O diferencial não será simplesmente utilizar IA para programar mais rápido.

Será saber criar um sistema de trabalho em que pessoas e agentes consigam colaborar sem perder:

• arquitetura;

• contexto;

• qualidade;

• rastreabilidade;

• segurança;

• testabilidade;

• capacidade de evolução.

Estamos deixando uma fase em que IA no desenvolvimento significava principalmente autocomplete e geração de código.

A próxima etapa parece muito mais interessante.

É a construção de processos de engenharia em que agentes passam a fazer parte efetiva do ciclo de desenvolvimento.

E, nesse cenário, especificação, arquitetura, contexto, testes, Git e observabilidade não ficaram menos importantes.

Ficaram ainda mais importantes.