O Fosso Invisível

A maioria dos devs já usa ou planejam usar IA.

Mas quase nenhum confia no que ela produz.

Quanto mais adotamos, menos confiamos. Isso não é ironia. É um diagnóstico.

Tem uma percepção comum de que os melhores builders de IA são os que sabem escrever os melhores prompts.

Ou os que usam o modelo mais avançado.

Ou os que adotaram a ferramenta mais nova antes de todo mundo.

Essa percepção está errada.

Os dados do CircleCI 2026 State of Software Delivery contam uma história diferente. Workflows diários subiram 59%.

Atividade em feature branches subiu 59%. Parece ótimo, né?

Mas a atividade na main branch caiu 7%. A taxa de sucesso da main branch despencou para 70,8% — o pior nível em 5 anos.

O benchmark saudável é 90%. O tempo médio de recuperação quando algo quebra subiu 13%, para 72 minutos.

Traduzindo: os times estão produzindo mais. Integrando menos. Quebrando mais. Recuperando mais devagar.

Engenheiros com IA terminam 21% mais tarefas. Criam 98% mais PRs. Mas o código gerado por IA tem 1,7x mais bugs por PR do que código humano.

A velocidade chegou. A qualidade ficou para trás.

2025 foi o ano da velocidade. 2026 será o ano da qualidade. Mas qualidade não vem de um modelo melhor. Vem dos sistemas ao redor dele.

Isso é o que separa quem constrói de quem apenas usa. E esse fosso é invisível até você cair nele.

1️⃣ Software é Argila — Mas Argila Sem Estrutura Desmorona

Existe um argumento legítimo e sedutor que circula hoje: software virou argila. Você molda, lança, remodela. A versão imperfeita que chega ao usuário hoje bate a versão perfeita que nunca sai do Notion.

Eu concordo. Parcialmente.

A parte verdadeira: o ciclo de iteração comprimiu de forma dramática.

A parte perigosa: argila sem estrutura desmorona. Você pode moldar rápido, mas se não tiver uma base sólida, cada nova moldagem enfraquece a anterior.

Velocidade sem sistema não é velocidade. É apenas pressa com consequências atrasadas.

A argila pode ser moldada rápido. Mas o forno — os testes, os evals, os linters, os type checks — é o que transforma argila em cerâmica. Algo estável e pronto para produção.

2️⃣ O Fosso Está no Workflow, Não no Modelo

"Os modelos não criam valor. Os sistemas criam."

Todo mundo tem acesso ao GPT-4o. Todo mundo tem acesso ao Claude. Todo mundo tem acesso ao Gemini. O modelo, sozinho, virou commodity.

O que não dá para copiar é o que está ao redor do modelo.

Pensa assim: dois times têm acesso ao mesmo modelo. Um time usa o modelo como uma caixa preta — entra prompt, sai resposta, vai pra produção. O outro time construiu:

• Um pipeline de dados que alimenta o modelo com contexto cirúrgico

• Um framework de avaliação que mede qualidade antes de mergear

• Feedback loops que aprendem com erros em produção

• Domain expertise destilado em prompts e tooling específico do negócio

Qual dos dois tem vantagem competitiva sustentável?

A Foundation Capital colocou assim: "2026 é o ano onde o gap entre demo e deployment fica dolorosamente claro." 

Demos rodando num modelo com prompt genérico parecem iguais. Mas deployments em produção, com usuários reais, em escala? Aí o sistema aparece.

O Superhuman descreve isso como "integration depth beats feature count" — você pode copiar features, mas não dá para copiar um workflow profundamente integrado no processo de trabalho do usuário.

Seu fosso não é o modelo que você usa. É o sistema que você construiu ao redor dele.

3️⃣ Backpressure: O Sistema Que Salva Você de Você Mesmo

Agentes cometem erros. Isso não é defeito — é característica.

A questão não é se o agente vai errar. É quem detecta o erro e quando.

Existe um espectro aqui:

• Nenhuma verificação: O erro vai pra produção. Usuário detecta. Você passa vergonha.

• Review humano em tudo: O agente não tem autonomia real. Você criou um glorificado autocomplete.

• Backpressure automatizada: Types, testes, linters, evals detectam o erro antes do humano precisar olhar.

O terceiro caminho é o que os melhores times estão construindo agora. O conceito técnico é "eval-to-guardrail lifecycle" — os evals que você roda antes de ir pra produção se tornam automaticamente as regras de governança em produção.

Na prática: você define o que "bom" significa em código. O sistema verifica automaticamente se cada output do agente atende essa definição. Se não atende, o agente não passa. Sem intervenção humana necessária.

Cada missão de resgate que você elimina é capacidade recuperada.

Pensa no custo real de um agente que quebra algo em produção:

1. Alguém detecta (usuário, monitoramento, colega)

2. Alguém para o que está fazendo para investigar

3. Alguém entende o que o agente fez

4. Alguém corrige

5. Alguém valida a correção

6. Deploy, smoke test, confirmação

Multiplicado por quantas vezes isso acontece por semana. Isso é o custo oculto da velocidade sem backpressure.

O paradoxo elegante: construir os guardrails parece mais lento no começo. Mas é o que permite velocidade sustentável. Investir em backpressure não reduz velocidade — ela remove o teto que impede você de acelerar de verdade.

4️⃣ Humanos Sobre o Loop, Agentes Dentro do Loop

Addy Osmani, ex-Google, descreveu a evolução de papel que está acontecendo:

Implementador → Condutor → Orquestrador

Há dois anos, você escrevia código. No ano passado, você revisava código que a IA escrevia. Hoje, você está definindo a arquitetura, os critérios de qualidade, os feedbacks loops — e deixando agentes executar dentro dessas restrições.

O conceito que importa aqui é Human on the Loop (HOTL) — você não está no loop executando. Você está sobre o loop, monitorando, intervenindo apenas quando algo parece errado.

O Osmani descreve assim: o esforço humano foi deslocado para frente (escrever specs, definir arquitetura, criar critérios) e para trás (revisar, testar, validar). O meio — a implementação — virou território do agente.

Mas "sobre o loop" não significa "fora do loop". Significa responsabilidade de design.

Nenhum modelo tem skin in the game. O agente não sofre as consequências quando o usuário perde dados. O agente não recebe o email furioso às 23h. O agente não precisa explicar para o cliente o que aconteceu.

Você sim.

É por isso que "humanos sobre o loop" não é preguiça disfarçada de delegação. É uma escolha arquitetural consciente: você garante que os sistemas ao redor do agente são robustos o suficiente para que você não precise microgerenciar cada output.

A diferença entre o dev que está sendo substituído e o dev que está prosperando não é conhecimento técnico. É essa capacidade de operar no nível de sistema — desenhando os loops que outros (agentes e humanos) executam dentro.

Quem projeta o loop controla o resultado. Quem executa dentro do loop é substituível.

5️⃣ Contexto é Recurso Escasso — Trate Como Tal

Andrej Karpathy cunhou recentemente o termo "context engineering" e o mundo da IA adotou imediatamente. Com razão.

"Context engineering é a arte e ciência delicadas de preencher o context window com exatamente a informação certa para o próximo passo."

A janela de contexto grande não é permissão para jogar tudo dentro. É uma tela grande que você ainda precisa pintar com precisão.

O erro que vejo constantemente: times que tratam o contexto como depósito. Jogam toda a documentação. Todos os arquivos do projeto. Todo o histórico de conversa. O modelo "vai saber o que é relevante."

Não vai. Não de forma confiável.

Todo token precisa ganhar seu lugar.

A implicação prática: context engineering é uma skill de produto, não só de engenharia. Você precisa entender quais informações o agente realmente precisa em qual momento. Isso exige entender o problema profundamente — mais profundamente do que a maioria dos times que estão "adicionando IA" está disposta a ir.

O Padrão Que Une Tudo

Software é argila. Mas o forno é o sistema.

O fosso está no workflow, não no modelo. Mas workflow sem backpressure é só processo sem confiabilidade.

Humanos sobre o loop. Mas "sobre" exige que o loop seja bem desenhado.

Contexto cirúrgico. Mas cirurgia exige entender onde cortar.

Existe um fio que liga todos esses princípios: o valor está no que é invisível para quem está de fora.

Qualquer um pode ver o modelo que você usa. Qualquer um pode copiar suas features. Qualquer um pode adotar a mesma ferramenta.

Ninguém consegue replicar o seu pipeline de dados, seus evals customizados, seu framework de feedback, a sua compreensão profunda do problema que você resolve.

2025 nivelou o campo em velocidade de implementação. 2026 vai revelar quem construiu sistemas de verdade — e quem apenas acelerou o processo de criar problemas.

O fosso invisível não é sobre o que você usa. É sobre o que você construiu ao redor do que usa.

A boa notícia: ainda dá tempo de construir.

📚 Conteúdos Recomendados

📄 Artigo: Agentic Engineering — Addy Osmani - A evolução de papel do engenheiro de implementador para orquestrador. Leitura obrigatória.

📊 Report: CircleCI 2026 State of Software Delivery - Os dados reais sobre o que está acontecendo com qualidade e velocidade nos times que adotaram IA.

📄 Artigo: 2025 Was the Year of AI Speed. 2026 Will Be the Year of AI Quality — CodeRabbit - O diagnóstico mais preciso do momento.

📄 Artigo: Context Engineering — Simon Willison - Por que "context engineering" é o frame certo para pensar em sistemas de IA.

Forte abraço,

Equipe Olympus