O desenvolvedor não virou passageiro; virou revisor de checkpoints

Quando aparece um app de IA para programar pelo celular, a reação mais fácil é fazer piada: "agora vou codar no ônibus", "adeus notebook", "mais uma tela para fingir produtividade".

Mas eu acho que essa leitura perde o ponto.

O que está mudando não é o lugar onde a gente digita código. É a forma como o trabalho com código é quebrado, executado e revisado.

Codex no mobile, app do Copilot, agentes abrindo sessão, rodando comando, mostrando diff, preparando PR. Tudo isso aponta para a mesma direção: o desenvolvimento com IA está saindo do autocomplete e entrando em um fluxo de checkpoints.

O dev não some desse processo. Pelo contrário. O dev vira a pessoa que define o escopo, escolhe a fronteira, revisa o diff, pede correção, roda validação e decide quando aquela parte pode entrar no repositório.

Isso é menos mágico do que "a IA programa sozinha". Também é bem mais útil.

O gargalo saiu da digitação

Durante muito tempo, a conversa sobre IA para dev ficou presa na sugestão de linha.

O modelo completa uma função. Sugere um teste. Escreve um componente. Explica um erro. Tudo isso ajuda, claro. Só que, em projetos reais, escrever a próxima linha raramente é o único gargalo.

O gargalo costuma estar em coisas mais chatas:

• recortar a tarefa certa;
• evitar que uma mudança pequena vire refatoração geral;
• entender o impacto do diff;
• rodar o teste que importa;
• perceber quando o agente mexeu onde não devia;
• revisar código gerado sem entrar no modo "aceitar tudo".

Quando uma ferramenta começa a funcionar em sessões assíncronas, com diff, teste, preview e aprovação, ela está admitindo uma coisa importante: gerar código ficou barato. Confiar no código continua caro.

É por isso que a interface de revisão está ficando tão importante.

Não basta o agente escrever. Ele precisa produzir uma unidade de trabalho revisável.

Checkpoint bom é pequeno

Um checkpoint bom não é "implemente o sistema de pagamentos".

Isso é uma bomba disfarçada de tarefa.

Um checkpoint bom parece mais com:

Ajuste a validação do formulário de checkout para impedir CPF inválido antes do submit. Edite apenas os arquivos do módulo de checkout. Rode os testes desse módulo. Se precisar mudar contrato de API, pare e explique.

Repara no que mudou. A tarefa tem fronteira, critério de pronto e permissão para parar.

Esse tipo de pedido ajuda o agente, mas ajuda principalmente você. O diff fica menor. A revisão fica possível. O teste fica mais claro. A chance de aceitar uma mudança lateral cai bastante.

O erro de muita gente com agentes é pedir trabalho grande demais e depois reclamar que a revisão ficou impossível. Só que revisão impossível não é detalhe. É falha de desenho do fluxo.

Se o agente entrega 1.500 linhas tocando frontend, backend, schema, workflow e configuração de build, talvez o problema não seja só a qualidade do modelo. Talvez o pedido tenha sido grande demais para virar um checkpoint decente.

O novo code review é mais operacional

Revisar código humano já exige atenção. Revisar código gerado por agente exige um tipo de atenção um pouco diferente.

Você não está avaliando apenas se a função parece bonita. Está avaliando se a execução respeitou a tarefa.

Eu gosto de olhar para quatro perguntas:

1. O agente mexeu só onde deveria?
2. O comportamento mudou do jeito esperado?
3. Os testes certos foram rodados?
4. O diff criou alguma obrigação escondida para depois?

Essa última é traiçoeira.

Às vezes o código compila, o teste passa, o PR parece limpo, mas o agente introduziu uma abstração que ninguém pediu, duplicou uma regra de negócio, relaxou uma validação ou empurrou complexidade para outro ponto do sistema.

Não é um erro escandaloso. É pior: parece aceitável.

Por isso, o review com IA precisa ficar menos estético e mais operacional. Menos "o código está elegante?" e mais "isso fecha o problema sem abrir outro?".

Confiança no modelo não substitui fronteira

Tem outro ponto que não dá para ignorar: agente de código não é só uma ferramenta de texto. Ele lê arquivo, edita projeto, roda comando e, dependendo do ambiente, enxerga coisa sensível.

Então a pergunta "o modelo é bom?" é insuficiente.

A pergunta melhor é:

mesmo se o modelo errar, até onde ele consegue ir?

É aqui que entram sandbox, permissão, aprovação e log.

Se o agente pode acessar o repositório inteiro, instalar pacote, abrir rede, ler secrets e mexer em workflow, você não tem um assistente. Você tem um processo com permissão ampla rodando em nome de alguém que talvez não esteja olhando com atenção.

Isso não significa travar tudo. Significa criar trilhos.

Para uma tarefa comum, talvez o agente só precise:

• ler uma pasta específica;
• escrever em poucos arquivos;
• rodar um comando de teste;
• acessar dependências já instaladas;
• pedir confirmação antes de instalar pacote;
• registrar o que executou.

Esse setup parece menos empolgante do que um vídeo de "criei um app inteiro em 3 minutos". Mas é o tipo de coisa que permite usar agente em repositório de verdade sem sentir que você deixou a porta aberta.

O celular entra como painel de aprovação

Por isso eu acho interessante olhar para essas interfaces mobile sem cair na caricatura de "programar pelo celular".

O celular não precisa virar IDE. Ele pode virar painel de triagem.

Você pode iniciar uma tarefa pequena, acompanhar o progresso, ver se o teste falhou, revisar um diff simples, pedir ajuste ou deixar para abrir no computador quando o contexto exigir mais cuidado.

Isso combina bem com trabalho assíncrono.

Nem toda decisão de engenharia precisa acontecer em uma sessão profunda de duas horas. Algumas decisões são de checkpoint:

• esse plano faz sentido?
• esse diff está dentro do escopo?
• esse teste é suficiente?
• essa alteração pode virar PR?
• esse agente precisa parar porque tocou em área sensível?

O perigo é transformar isso em aprovação preguiçosa. Se a revisão vira swipe, a qualidade cai rápido.

Mas, usado direito, esse modelo tira atrito de tarefas pequenas. O agente trabalha em blocos. Você aprova ou corrige em blocos. O projeto avança sem depender de uma janela perfeita de foco para cada microtarefa.

Como eu montaria um fluxo simples

Se eu fosse colocar esse modelo em um projeto pequeno hoje, começaria sem glamour:

1. Criaria uma lista de tarefas que cabem em até um diff pequeno.
2. Definiria quais pastas o agente pode editar em cada tarefa.
3. Separaria comandos permitidos por tipo de trabalho.
4. Exigiria resumo de mudanças e testes rodados.
5. Trataria alterações em dependências, secrets, CI e build como área sensível.
6. Revisaria o diff antes de pensar em merge.

O ponto não é burocratizar. É evitar que a produtividade do agente vire dívida de revisão.

Um bom fluxo com IA deveria deixar mais fácil dizer "sim" para mudanças pequenas e "não" para mudanças grandes demais.

Quando tudo vira um pacote enorme, o humano perde o controle. E, quando o humano perde o controle, a promessa de produtividade começa a cobrar juros.

A habilidade principal mudou um pouco

Ainda vale saber programar bem. Isso não virou opcional.

Mas a habilidade que mais cresce nesse tipo de fluxo é outra: saber transformar trabalho em unidades revisáveis.

Isso envolve escrever pedido bom, sim. Só que vai além de prompt.

Envolve entender arquitetura, risco, teste, permissão, CI, produto e manutenção. Envolve saber quando pedir para o agente continuar e quando mandar parar. Envolve desconfiar de um diff bonito que mudou coisa demais.

Talvez essa seja a virada mais honesta da IA para desenvolvimento: ela não elimina o julgamento técnico. Ela aumenta a frequência com que você precisa exercê-lo.

O autocomplete perguntava: "você quer aceitar esta linha?".

O agente pergunta: "você aceita este pedaço de trabalho?".

Essa segunda pergunta é bem mais séria.

Então, se você está usando Codex, Copilot ou qualquer agente parecido, eu não começaria tentando automatizar o projeto inteiro. Começaria treinando o fluxo de checkpoints:

• tarefa pequena;
• ambiente limitado;
• execução observável;
• diff revisável;
• teste claro;
• decisão humana.

Esse é o lugar onde a IA começa a ficar realmente prática para quem constrói software.

Não como piloto automático.

Como um colega muito rápido que precisa de escopo, limite e revisão.