Quando o software cresce mais rápido que a nossa compreensão

Você passa uma tarefa a um agente de programação. Pouco depois, a funcionalidade está funcionando e os testes passam. As alterações abrangem dezenas de arquivos, introduzem novas estruturas e resolvem algumas coisas que você nunca pediu explicitamente.

O resultado parece bom. Algumas rodadas de uso não revelam problemas evidentes, então você passa para a próxima tarefa.

Mas algumas perguntas continuam sem resposta. Por que essa implementação? Quais comportamentos decorrem dos seus requisitos e quais refletem escolhas feitas pelo agente? Quando você mudar essa parte do sistema novamente, o que precisa ser preservado?

O software avançou. Sua compreensão continua no ponto de partida.

1. Preservar nossa compreensão enquanto o software muda

O software existe como código e processos em execução, mas também na compreensão das pessoas que lhe dão forma. Para que ele serve? Por que funciona desse jeito? Quais escolhas precisam continuar valendo e quais podem mudar? É essa compreensão que nos permite continuar moldando nosso software ao longo do tempo.

Ela não precisa abranger cada detalhe da implementação. Você pode não conhecer funções específicas e ainda assim saber o que o software deve se tornar, avaliar se uma mudança atende à sua intenção e intervir quando isso não acontece.

No desenvolvimento convencional, a complexidade e as mudanças na equipe podem afastar a compreensão da implementação. Ainda assim, projetar, programar, depurar e revisar também nos dão oportunidades constantes de construir e corrigir nossa compreensão enquanto trabalhamos.

Os agentes de programação mudam o ritmo. Eles podem pular muitas das etapas que antes exigiam nossa participação direta e produzir implementações substanciais por conta própria. O software continua mudando. Nossa compreensão pode não acompanhar essas mudanças.

A funcionalidade vem primeiro; compreendê-la vira uma tarefa posterior. Ler as alterações. Perguntar por quê. Descobrir o que mais elas afetam. Essas tarefas ocupam parte do tempo economizado na programação. O agente pode continuar gerando, e as coisas que ainda precisamos entender podem continuar se acumulando.

Há também uma adaptação mais difícil: o software pode avançar exatamente como você pediu e, ao mesmo tempo, se tornar cada vez menos familiar. Você passa o dia distribuindo tarefas, respondendo a perguntas e conferindo resultados. Todos os agentes estão avançando, mas você ainda precisa entender como essas mudanças se encaixam. A percepção que você desenvolve ao construir algo por conta própria — saber em que ponto está e como alterá-lo depois — não surge automaticamente quando as tarefas terminam.

Sua própria obra vai se tornando desconhecida. Você lembra o que pediu, mas fica mais difícil explicar por que o resultado é como é, se decisões anteriores continuam valendo ou o que a próxima mudança vai afetar. A continuidade de saber o que você construiu, por que funciona desse jeito e como alterá-lo começa a se romper. Continuar moldando a obra fica mais difícil.

2. Uma IA melhor não elimina o direito de decidir

Uma resposta natural é tornar os modelos mais confiáveis: código melhor, melhor detecção de erros e verificação mais completa. Se um modelo se tornar bom o suficiente, as pessoas ainda precisam entender e decidir o que sua obra deve se tornar?

Nosso direito de dirigir nosso próprio trabalho não depende de a IA continuar cometendo erros.

“A IA pode escrever o código, mas as pessoas ainda terão que projetar a arquitetura.” Essa resposta vincula nosso papel a uma capacidade em que hoje temos vantagem. E se os modelos também se tornarem excelentes arquitetos? Recuar para a verificação ou para a compreensão do sistema leva à mesma pergunta: quando um modelo também for bom nisso, perderemos nossa razão para participar?

Levemos o argumento ao limite. Suponha que a IA alcance inteligência geral. Ela entende sistemas complexos, faz excelentes escolhas técnicas e verifica implementações com mais rigor do que nós. Deveríamos então entregar a ela todas as decisões sobre o que criamos?

Enquanto alguém quiser criar de acordo com a própria intenção e escolher o rumo de sua obra, essa pergunta continuará valendo.

A capacidade de tomar uma decisão melhor não confere, por si só, o direito de decidir por outra pessoa.

Você pode escolher delegar muitos julgamentos à IA e reservar uma decisão específica para si. Pode aceitar conselhos, mudar de ideia ou reconhecer que uma escolha anterior estava errada. O que importa é fazer uma escolha informada, em vez de descobrir depois que o software já mudou.

O direito de dirigir seu próprio trabalho não depende de você ser mais capaz do que a IA. Também não depende de quantas pessoas ainda querem exercê-lo. Mesmo que quase todo mundo esteja disposto a delegar tudo, quem não está continua tendo o direito de decidir o que seu software deve se tornar.

Enquanto uma única pessoa quiser continuar sendo autora de sua obra, ainda precisaremos responder como sua intenção pode continuar em vigor.

3. O que é preciso para continuar moldando seu software

A autoria continua depois que a primeira ideia se torna um software funcional. Você precisa poder entender escolhas importantes, mudar de rumo, rejeitar resultados que entrem em conflito com sua intenção e continuar revisando a obra. O direito de dirigi-la precisa se traduzir em capacidades práticas.

Se tudo o que você pode fazer é clicar em “Aceitar” quando o agente termina, sem saber quais escolhas importantes o resultado contém, seu controle é limitado. O mesmo vale se você pode rejeitar um resultado, mas não encontra uma forma de alterá-lo, ou se um requisito que deixou explícito ontem deixa de ser cumprido em silêncio na implementação de hoje. Você pode continuar aprovando o trabalho enquanto perde a capacidade de moldá-lo de acordo com sua intenção.

Manter essa capacidade significa poder responder a algumas perguntas concretas:

• Ainda está claro o que o software deve se tornar?
• Você consegue ver como a implementação atual responde aos seus requisitos?
• Você consegue distinguir suas decisões importantes das escolhas feitas pelo agente?
• Ao mudar de rumo, você consegue entender os possíveis efeitos e intervir?
• Depois da próxima mudança na implementação, as decisões que você tomou explicitamente continuarão valendo?

Pense em uma ferramenta pessoal de escrita com um requisito explícito: manter seu conteúdo no dispositivo local. Você deixa a organização dos arquivos, a implementação do armazenamento e muitos detalhes internos para o agente. Mais tarde, para facilitar o uso da ferramenta em vários dispositivos, o agente propõe sincronização com a nuvem.

A possibilidade de o conteúdo sair do dispositivo toca em uma decisão que você já tomou. Essa escolha precisa estar visível, e você precisa entender o que ela muda antes de aceitá-la ou rejeitá-la. Um resultado pode ser mais conveniente e mais confiável e, ainda assim, se afastar do requisito original.

Os testes podem ajudar a demonstrar que o software se comporta de uma determinada maneira. Você ainda precisa avaliar se esse comportamento é aceitável e se respeita as decisões que deseja manter.

O agente pode implementar a sincronização, verificar se os dados são transferidos corretamente e corrigir erros. Mas se o conteúdo deve sair do dispositivo, quais evidências bastam para aceitar essa mudança e quem responde se algo der errado são questões que precisam de respostas explícitas além da própria implementação. Seu julgamento precisa determinar para onde o trabalho vai e quando ele para, em vez de servir apenas como uma assinatura depois que tudo estiver pronto.

4. Ler todo o código pode preservar a autoria?

A revisão de código oferece uma resposta direta. O agente escreve o código; uma pessoa o lê e verifica o que ele faz.

O código pode conter comportamentos que o relatório do modelo nunca menciona, estruturas que afetam a manutenção e problemas que você só consegue avaliar examinando a implementação de perto.

Mas, à medida que a geração fica mais rápida, ler cada alteração pode continuar sendo uma forma sustentável de manter o controle?

Mesmo sem ler linha por linha, seu dia pode continuar cheio: esclarecer requisitos vagos, perceber onde um resultado se desviou, decidir quais evidências demonstrariam que ele está correto e orientar o agente de volta. Cada etapa exige experiência e concentração. Ler pouquíssimo código e trabalhar intensamente podem ser duas realidades ao mesmo tempo.

Ler código também é uma oportunidade de construir compreensão. Revisar as alterações de um colega ajuda a equipe a aprender o que o sistema faz agora, por que foi projetado assim e o que observar em mudanças futuras. Se lemos menos código, precisamos de outras formas de desenvolver essa compreensão.

Mas, quando as mudanças se acumulam e as pessoas só conseguem passar os olhos antes de aprová-las, manter o processo de revisão não preserva necessariamente a compreensão. Nossa atenção limitada precisa chegar aos pontos que exigem julgamento: escolhas de projeto com consequências importantes, mudanças de grande alcance e resultados que ainda são incertos.

Quais escolhas precisamos continuar entendendo ao longo do tempo? Quais detalhes de implementação podemos investigar quando necessário? Como evitamos gastar toda a nossa atenção com detalhes e deixar passar as decisões que realmente precisam de nós?

5. E se substituirmos o código por especificações extensas?

Outra resposta é levar nosso trabalho para a linguagem natural. Descrever como o software deve se comportar e depois pedir a um agente que implemente a especificação. Ou pedir ao agente que explique o código, transformando o sistema em documentação mais fácil de ler.

Requisitos claros reduzem mal-entendidos. A documentação preserva o contexto. Uma boa explicação torna o código desconhecido mais acessível. Mas a linguagem natural não faz o custo da leitura desaparecer.

Se o software contém muitos comportamentos e escolhas com vantagens e desvantagens, um documento que descreva todos eles pode crescer junto com a implementação. Podemos passar de código demais para ler a texto demais para ler. Mesmo que cada frase seja mais fácil de entender do que o código correspondente, o conjunto ainda pode exceder nosso tempo e nossa atenção.

E, se o agente continua ampliando a especificação enquanto nós apenas a aprovamos, chamá-la de documento aprovado por uma pessoa não demonstra que essa pessoa entendeu cada decisão contida nele.

O que o software faz, o que o agente diz que ele faz e o que de fato entendemos e escolhemos respaldar são três coisas diferentes.

Mesmo com um registro completo e uma explicação minuciosa, podemos continuar sem saber como seguir moldando o software. Precisamos poder encontrar o que importa, entender como isso se mantém na implementação atual e enxergar as escolhas disponíveis quando ela mudar novamente.

Manter a autoria nas mãos das pessoas

À medida que a implementação fica mais barata, mais pessoas podem transformar suas ideias em software. Elas também devem poder entender e continuar moldando o que criam.

Essa liberdade vai além do software. Em qualquer trabalho criativo, a pessoa que o cria deve poder escolher o que delegar à IA e o que decidir por conta própria.

A missão da Finite Ground é ajudar as pessoas a criar de acordo com a própria intenção e a continuar moldando sua obra enquanto a IA amplia o que é possível.

O Noema leva essa missão ao software, mantendo a intenção das pessoas em vigor enquanto a implementação continua mudando.

Se chegar um dia em que a inteligência artificial geral (AGI) assuma todos os aspectos da vida humana e todos abram mão de sua autonomia, essa pergunta deixará de se aplicar. A Finite Ground deixará de ter uma razão para existir.

Enquanto uma única pessoa não estiver disposta a abrir mão dessa autonomia, haverá uma razão para continuar.

A IA pode trazer mais ideias ao mundo. O direito de decidir em que essas ideias se tornam continua pertencendo às pessoas que escolhem mantê-lo.