Abra um repositório seis meses depois de uma funcionalidade ter sido lançada e conseguirá reconstruir muita coisa. Pode seguir a arquitetura, inspecionar o esquema, ler os testes e ver exatamente que linhas foram alteradas.
O que normalmente não consegue reconstruir é a conversa que tornou essas linhas necessárias.
O código não lhe dirá que existe uma regra de validação porque um cliente envia exportações malformadas. Não explicará que uma política de repetição estranha evita transações duplicadas num sistema a jusante. Não mostrará que a interface mais limpa foi rejeitada após um teste de acessibilidade, nem que uma fronteira entre serviços reflete uma restrição contratual e não uma preferência de engenharia.
O Git é excelente a preservar o histórico do código. Só preserva a intenção quando uma equipa a regista deliberadamente por escrito e a mantém ligada à implementação.
Essa lacuna sempre fez parte da engenharia de software. As ferramentas de programação com IA tornam-na mais visível. Um sistema pode ler todos os ficheiros de um repositório, seguir todos os símbolos e gerar um patch tecnicamente convincente, continuando ainda assim a resolver o problema errado.
O problema não é o código ser enganador. O código está a responder a uma pergunta mais estreita.
Cinco camadas da verdade da engenharia
A maioria das alterações de software com significado depende de cinco camadas diferentes de evidência.
- Intenção — Que resultado está o utilizador, cliente ou negócio a pedir? Isto pode estar numa especificação, num ticket, numa conversa de suporte ou numa nota de reunião.
- Restrições — O que não pode falhar? Promessas de compatibilidade, limites de segurança, regulamentos, contratos, orçamentos e prazos estão muitas vezes fora do repositório.
- Implementação — Como funciona hoje o sistema? O código, os testes, os esquemas, as dependências e a configuração de deployment fornecem esta camada.
- Evidência em runtime — O que está a acontecer no sistema real? Logs, traces, métricas, dados de produção e relatórios de incidentes podem contradizer pressupostos que parecem razoáveis no código.
- Histórico de decisões — Porque foi escolhida a abordagem atual? Pull requests, discussões de design, alternativas rejeitadas e incidentes anteriores contêm a resposta.
O repositório é mais forte na terceira camada. Contém partes das outras, mas raramente o suficiente para as representar por completo.
Isto importa porque as falhas de software surgem muitas vezes nas fronteiras entre camadas. A implementação corresponde a uma especificação desatualizada. A correção satisfaz o ticket, mas viola uma restrição operacional. Os testes passam porque codificam os pressupostos de ontem. O código é internamente consistente, enquanto os dados de produção seguem um padrão que ninguém documentou.
Um patch localmente correto pode, ainda assim, ser a alteração errada.
O que o repositório não consegue responder, por si só
Considere um utilizador que edita um documento e depois procura a frase atualizada, apenas para ver a versão antiga nos resultados. “Fazer com que a pesquisa atualize imediatamente” parece um pedido claro. O repositório revela vários pontos possíveis por onde começar, mas não consegue determinar, por si só, qual é a correção certa.
| Pergunta | Fonte provável |
|---|---|
| Que versão do documento é a autoritativa? | Documento de origem e histórico de revisões |
| Onde permanece o texto antigo? | Registos de sincronização, saída da extração, índice de pesquisa ou cache |
| O que significa “imediatamente” para este produto? | Promessa do produto ou objetivo de serviço |
| As permissões do documento mudaram juntamente com o conteúdo? | Permissões de origem e histórico de auditoria |
| O resultado desatualizado está limitado a um utilizador, origem ou região? | Rastos de pedidos e métricas de produção |
O código da pesquisa pode explicar como os resultados são devolvidos. Não lhe consegue dizer se o defeito real é um atraso de sincronização, extração desatualizada, invalidação de cache, propagação de permissões ou uma expectativa que o produto nunca definiu.
Esta distinção torna-se ainda mais importante em sistemas maduros. Um campo que parece obsoleto pode ainda dar suporte a um cliente legado. Um serviço que parece duplicado pode separar dados com requisitos de permissões diferentes. Uma verificação aparentemente excessiva pode ser o único vestígio, ao nível do código, de um incidente em produção que a equipa atual nunca viu.
Eliminar complexidade é valioso. Eliminar história disfarçada de complexidade sai caro.
Mais contexto também pode produzir a resposta errada
A solução óbvia é dar mais material à IA: o repositório inteiro, todos os tickets, todos os documentos, todas as mensagens e todos os registos.
Isso cria acesso, não compreensão.
As fontes podem estar desatualizadas, ser contraditórias, especulativas ou escritas para públicos diferentes. Uma sessão de brainstorming não deve sobrepor-se a uma especificação aprovada. Um requisito com seis meses não deve substituir silenciosamente a decisão de produto de ontem. Um registo de produção deve estar ligado à release, ao ambiente e ao caminho de código que o produziu. Um pedido de cliente não deve ser tratado como um requisito universal sem verificar o âmbito.
Por isso, um sistema de contexto sério precisa de mais do que recuperação. Precisa de uma forma de raciocinar sobre:
- Autoridade: Que fonte pode definir o requisito?
- Atualidade: Que informação está em vigor e o que foi substituído?
- Proveniência: De onde veio cada afirmação, restrição ou conclusão?
- Relações: Que issue, release, cliente, conjunto de dados e caminho de código pertencem ao mesmo contexto?
- Permissões: Que fontes podem ser usadas para esta tarefa e mostradas a esta pessoa?
O contexto não é um monte de tokens. É um grafo com tempo, autoridade e fronteiras.
Mais contexto deve produzir mais evidência, não mais confiança sem evidência.
A verdadeira unidade de trabalho é a mudança
Os editores e as ferramentas de programação organizam-se em torno de ficheiros porque são os ficheiros que modificamos. As equipas de engenharia organizam-se em torno de mudanças.
Uma mudança começa com uma razão. Torna-se um requisito, toca em código e dados, passa por revisão, chega à produção e cria nova evidência. Se essas etapas permanecerem desligadas, cada tarefa futura começa com mais uma ronda de arqueologia.
Um sistema de IA que trabalha sobre software real deve seguir esse ciclo de vida.
Antes da implementação, deve identificar o pedido, as restrições relevantes e quaisquer fontes em conflito. Deve saber se está a corrigir um defeito, a alterar o comportamento esperado ou a introduzir um novo contrato.
Durante a implementação, deve ligar cada escolha relevante à evidência. Porque este módulo? Porque esta estratégia de migração? Porque preservar este ramo? A explicação deve sobreviver para além da conversa que produziu o código.
Após a implementação, deve anexar à alteração os resultados da verificação, as decisões de revisão e as novas restrições descobertas. Caso contrário, a pessoa seguinte — ou a próxima sessão de IA — terá de as redescobrir.
Esta é a diferença entre uma ferramenta que consegue editar um repositório e um sistema que consegue participar no trabalho de engenharia.
A IA deve reduzir a reconstrução, não eliminar o discernimento
Por vezes, um melhor contexto é apresentado como um caminho para o desenvolvimento autónomo de software. O valor imediato é menos dramático e mais útil: reduzir o custo de reconstruir a realidade antes de fazer uma alteração.
A IA pode colocar o requisito original ao lado do código relevante. Pode trazer à superfície o incidente que explica uma salvaguarda invulgar. Pode ligar uma métrica em falha à release que a alterou. Pode mostrar que duas fontes autorizadas estão em desacordo antes de a implementação começar.
Essas capacidades não eliminam o discernimento de engenharia. Tornam-no mais bem informado.
Continua a ser necessário que uma pessoa decida que compromisso é aceitável, se um requisito está completo e quanto risco uma release pode comportar. O sistema deve tornar a evidência visível e o raciocínio inspecionável. Não deve esconder a incerteza por detrás de um patch polido.
O critério não é “consegue gerar código?”
O critério é “consegue explicar por que razão esta é a alteração certa neste momento?”
De consciente do repositório a consciente do trabalho
Os assistentes de programação começaram por se tornar úteis ao compreender o ficheiro à frente do programador. A consciência do repositório foi o passo importante seguinte: encontrar código relacionado, seguir símbolos e aplicar alterações em todo um projeto.
O passo seguinte é ter consciência do trabalho em torno do repositório.
Isso significa ligar o código à especificação que o pediu, à conversa que o clarificou, à evidência de produção que o pôs em causa e à decisão que deve ser recordada depois. Significa também excluir contexto que seja irrelevante, desatualizado ou fora das permissões do utilizador.
Ao construir a Dvina, esta é uma das ideias a que voltamos repetidamente. O trabalho não acontece dentro de um único ficheiro, aplicação ou conversa. O significado vive nas ligações entre eles e na forma como essas ligações mudam ao longo do tempo.
O repositório continua a ser essencial. É a fonte de verdade executável para o comportamento do sistema. Simplesmente não é a fonte de verdade completa para a intenção do produto, a realidade operacional ou a memória organizacional.
A história completa muda aquilo que é construído
Quando se tem apenas o código, a pergunta natural é:
Que alteração se adequa a este sistema?
Com o contexto mais amplo, a pergunta passa a ser:
Que alteração se adequa a este sistema, a este requisito, a este historial e a este momento?
Essa segunda pergunta deteta restrições antes de se transformarem em regressões. Dá aos revisores o raciocínio por detrás da implementação. Ajuda os novos membros da equipa a compreender porque é que o sistema é como é. Dá à IA um papel assente em bases sólidas: não o de um oráculo dentro do editor, mas o de um participante capaz de reunir evidências de todo o trabalho.
O teu repositório nunca foi a história toda.
A oportunidade está em construir sistemas capazes de ler o resto dessa história — e mostrar o seu trabalho.
