Agora são os agentes que escrevem o código. Veja no que virou o trabalho do desenvolvedor.

A pergunta aparece em toda mesa de jantar onde alguém tem um desenvolvedor na família: se a máquina escreve o código, o que sobra?

A resposta honesta é que a pergunta mira a parte errada do trabalho. Escrever código nunca foi o trabalho inteiro. Era a parte visível, a que parecia trabalho para quem passava atrás da mesa. E era também, na maioria das semanas, a menor.

O que foi automatizado nunca foi o trabalho inteiro

Tudo o que entra no ar passa por seis elos:

1. Alguém quer alguma coisa, e explica mal.
2. Alguém decide que vale a pena, e quando.
3. Alguém transforma isso numa descrição precisa o bastante para ser executada.
4. Alguém constrói.
5. Alguém verifica que nada mais quebrou.
6. Alguém entrega e avisa quem pediu.

Os agentes ficaram com o elo quatro. Ficaram de forma convincente, e vão continuar melhorando nele. O que quase ninguém diz em voz alta é o efeito disso sobre os outros cinco: eles ficam mais pesados, não mais leves.

O motivo é o throughput. Quando construir levava duas semanas, os cinco elos ao redor tinham duas semanas para acontecer. Eram lentos porque o meio era lento, e ninguém percebia que eram lentos. Quando construir leva uma tarde, todo o resto vira o gargalo, de uma vez só.

Um elo desabou. Os outros cinco carregam agora o peso que ele escondia.

Essa é a história inteira, e o resto deste artigo é como cada um dos cinco fica quando você precisa mesmo cuidar dele todo dia.

Elo 1: ouvir o que construir, sem perder metade no caminho

O novo modo de falha é específico e caro: você consegue construir qualquer coisa, então você constrói a coisa errada mais rápido.

Os pedidos chegam de todo lado. Uma mensagem numa thread de suporte. Uma frase no fim de uma call. Uma reclamação numa rede social. Um relato de bug que na verdade é um pedido de funcionalidade disfarçado. Historicamente isso não fazia muita diferença, porque você só conseguia construir uma coisa a cada duas semanas mesmo, e a opção óbvia costumava ser a certa. Agora que dá para construir cinco coisas por semana, a diferença entre as cinco certas e as cinco erradas é a maior parte do seu ano.

Duas coisas precisam acontecer, e são coisas diferentes.

Primeiro, registrar um pedido tem que ser barato para quem pede. Se o usuário precisa criar uma conta, achar um formulário e descrever o problema duas vezes, a maioria não vai se dar ao trabalho, e quem se dá não é uma amostra representativa. Um quadro de feedback público onde qualquer pessoa abre um pedido, anexa uma captura de tela e acompanha o que acontece com ele elimina esse atrito. Quem usa o produto escreve os pedidos com as próprias palavras, com o contexto junto.

Segundo, a triagem tem que ser automática, porque feedback cru não fica útil por muito tempo. Vinte mensagens dizendo mais ou menos a mesma coisa parecem vinte problemas até alguém ler as vinte e perceber que é uma só. É exatamente o trabalho para o qual ninguém tem tempo. O Idea Radar é a nossa resposta a isso: os sinais crus chegam intactos, se agrupam em temas, as duplicatas são casadas antes de virarem duas construções, e cada ideia carrega o número de pessoas distintas que pediram aquilo. O texto original nunca é reescrito, porque as palavras exatas que a pessoa usou são o dado.

O que sai deste elo não é um backlog. É um corpus que dá para ler.

Elo 2: decidir, que virou o recurso escasso

Um quadro de ideias não é um plano. Transformar um no outro é o julgamento que antes ficava diluído num trimestre inteiro e agora precisa acontecer toda semana.

Dois movimentos importam aqui.

A promoção é deliberada. Uma ideia vira um ticket do backlog quando alguém decide que vale a pena construir, não quando ela é registrada. Todo o resto continua visível no radar com a contagem de quem pediu, que é o retrato honesto da situação: ouvido, não agendado. Backlogs em que oitenta por cento das linhas nunca serão construídas não são planos, são acervos com uma diagramação enganosa.

A delimitação acontece antes da construção, não durante. Um feedback vago vira um mockup validado que a pessoa que pediu consegue olhar e confirmar. Cinco minutos de confirmação valem mais do que uma tarde construindo a tela errada, e essa troca ficou muito melhor no dia em que a tarde de construção virou uma tarde de tempo de agente que você poderia ter gasto em outra coisa.

Elo 3: dar o briefing, o ofício que substituiu a digitação

É aqui que foi parar a habilidade de verdade.

Um agente não contesta uma instrução ambígua como um colega faria. Ele não vai dizer "espera, qual dos dois fluxos de pagamento?". Ele preenche o buraco com um palpite plausível e te devolve uma coisa coerente e errada. O custo da ambiguidade antes era uma conversa. Agora é um diff.

O que separa quem obtém bons resultados de quem briga com os agentes o dia inteiro não é esperteza de prompt. É contexto reutilizável. Quatro tipos, em ordem decrescente de retorno.

Contexto que os agentes leem antes de explorar. Arquivos de convenção versionados no Git (CLAUDE.md, AGENTS.md) e uma memória de projeto que guarda as decisões de arquitetura, as armadilhas do passado e o motivo de as coisas serem como são. Escrito uma vez, lido por todo agente em toda máquina, para sempre. É a escrita de maior alavancagem que um desenvolvedor produz hoje, e quase ninguém reserva tempo para ela.

Procedimentos, salvos como procedimentos. Na décima vez que você explica o seu checklist de release, você não está dando um briefing, está redigitando. Uma biblioteca de skills transforma um procedimento recorrente em algo que o agente carrega quando a tarefa combina, e uma biblioteca de prompts faz o mesmo pelos briefings em si.

Mostrar em vez de descrever. Um parágrafo descrevendo um botão desalinhado vale menos do que uma imagem do botão desalinhado. Mande uma região da tela direto, ou desenhe em cima dela para apontar exatamente a coisa de que você está falando. Numa página web, entregar o DOM ao vivo para o agente ganha de descrevê-lo, sempre.

Falar em vez de digitar. Um briefing falado de três frases carrega mais nuance do que a única frase que você teria paciência de digitar. Ditado por voz para uma instrução rápida, modo voz quando você quer o vai e volta sem encostar no teclado. Parece funcionalidade de conforto. Na prática é funcionalidade de banda: as pessoas falam mais do que escrevem, e um agente é limitado pelo que você conta para ele.

As três primeiras se pagam a cada tarefa. A quarta se paga uma vez e se colhe para sempre.

Elo 4: conduzir o trabalho, na máquina certa

Um agente é uma ferramenta. Vários agentes são um sistema, e sistema precisa de operador.

As perguntas práticas não são glamourosas, e são o trabalho. O que pode rodar em paralelo sem dois agentes editando o mesmo módulo? Qual tarefa merece a sua atenção enquanto roda e qual não merece? O que deveria estar rodando enquanto você dorme?

Essa última decide onde o trabalho executa. Tudo o que você talvez precise interromper, corrigir ou redirecionar no meio do caminho fica na máquina à sua frente. Trabalho longo, bem especificado, sem zona cinzenta vai para outro lugar: outro computador seu ou um servidor por SSH, para que um serviço de duas horas não deixe o seu notebook de refém. Trabalho recorrente vai para uma agenda. A pergunta que decide nunca é potência bruta, é a probabilidade de você precisar intervir.

Quando um trabalho tem etapas genuinamente diferentes, um agente sozinho é a forma errada para ele. Uma construção que precisa ser testada e depois revisada são três serviços com três conjuntos de habilidades, e as equipes de agentes deixam você desenhar essa passagem de bastão de forma explícita em vez de reexplicar o contexto a cada etapa.

E como nada disso exige que você esteja sentado ali, conduzir pelo celular deixa de ser novidade. Ler a pergunta de um agente e responder em vinte segundos dentro de um ônibus é a diferença entre uma tarefa que terminou e uma tarefa que esperou quatro horas por você.

Elo 5: revisar, onde mora a responsabilidade

Este é o elo que não dá para delegar, e o motivo não é técnico.

Os agentes já substituíram a maior parte da leitura linha a linha. O que eles não conseguem assumir é a assinatura. Responsabilidade não se transfere para um modelo. Quando uma migração derruba uma coluna em produção, "foi o agente que escreveu" não é uma frase que alguém aceite, e nem deveria ser.

O que muda é o formato da revisão, não a existência dela. Ler cada linha não sobrevive ao contato com cinco agentes rodando em paralelo, e um humano passando o olho num diff de novecentas linhas às seis da tarde produz uma assinatura sem produzir conhecimento. A política que se sustenta é revisar em proporção ao raio de explosão: texto e estilo levam uma passada de olho, enquanto autenticação, pagamentos, permissões, dados pessoais e migrações são lidos linha a linha, toda vez, por alguém que saberia tê-los escrito.

Duas coisas tornam isso praticável. Poder ver um diff por agente em vez de uma pilha só te diz quem mudou o quê quando três deles trabalharam no mesmo repositório. E anexar a conversa ao commit responde à pergunta que realmente custa tempo seis meses depois, que nunca é "o que mudou" e sim "por quê".

Para qualquer coisa com interface, a verificação não para no diff. Um agente dirigindo um navegador de verdade consegue percorrer o fluxo que acabou de construir e relatar o que viu, o que pega a classe de bug que se lê perfeitamente bem no código-fonte.

Escrevemos um artigo inteiro sobre onde gastar essa atenção: você ainda deve revisar o código do seu agente de IA.

Elo 6: entregar, e fechar o ciclo

Entregar é a metade fácil deste elo. A metade que se pula é avisar quem pediu.

É também a metade de maior retorno. Um usuário que reporta alguma coisa e depois fica sabendo que ela entrou no ar reporta a próxima. Um usuário que reporta no silêncio para de reportar, e você perde a matéria-prima que alimentava o elo um. Quando um ticket nascido de um pedido público é fechado, quem o abriu deveria ficar sabendo sem que ninguém precise lembrar de mandar um e-mail.

Antes disso, normalmente tem alguém que precisa ver a coisa funcionando e não tem o seu ambiente de desenvolvimento: um cliente, um designer, um colega em outro continente. Uma URL HTTPS pública apontando para a sua máquina local transforma isso de um deploy num link, e o retorno que volta cai direto no elo um.

A cadeia se fecha. É isso que faz disso um trabalho e não uma fila.

O que encolheu de verdade, e o que cresceu de verdade

Leia essa tabela com honestidade e a ansiedade muda de forma. As partes que encolheram são as que eram mais fáceis de contratar. As partes que cresceram são as que exigem alguém que entenda o sistema, os usuários e as consequências. É um trabalho mais difícil, não um trabalho menor, e é bem menos solitário do que a versão em que você digitava o dia inteiro.

Onde o AgentsRoom entra nisso tudo

Nós construímos a ferramenta que segura a cadeia inteira, porque a alternativa são seis ferramentas que não sabem uma da outra.

Na prática: os pedidos caem num quadro, se organizam em ideias, são promovidos a tickets, são delimitados em algo que um agente não consegue ler errado, são executados por um agente ou por uma equipe deles na sua máquina ou numa máquina remota, são revisados por agente com a conversa anexada, e são fechados avisando quem pediu. Uma janela, um único lugar onde o estado do trabalho é verdadeiro.

As peças isoladas existem em outros lugares. As ligações entre elas é que ninguém estava entregando, e é nas ligações que o trabalho vaza.

Perguntas que as pessoas realmente fazem

A IA vai substituir os desenvolvedores?

Ela substituiu a digitação, não o trabalho. Escrever código é um elo de uma cadeia que também contém ouvir o que os usuários precisam, decidir o que vale a pena construir, especificar com precisão, conduzir a execução, verificar e entregar. Os agentes derrubaram o custo de um elo, o que transformou os outros cinco no gargalo. Menos gente vai ser paga para produzir linhas. Mais gente está sendo paga para decidir quais linhas devem existir e para responder por elas depois que entram no ar.

O que um desenvolvedor faz de verdade quando são os agentes que escrevem o código?

Seis coisas, e só uma delas costumava ser visível numa tela cheia de código. Você coleta o que as pessoas estão pedindo, decide o que vale construir e em que ordem, dá o briefing do trabalho com precisão suficiente para um agente não conseguir ler errado, conduz vários trabalhos ao mesmo tempo sem perder o fio, revisa na proporção do que cada mudança pode quebrar, e entrega avisando quem pediu. O ofício saiu da produção da mudança e foi para a especificação dela e para a responsabilidade por ela.

Ainda é preciso saber programar?

Sim, e mais do que antes na hora de ler. Você não precisa mais decorar a sintaxe de uma linguagem que toca duas vezes por ano, porque quem escreve é o agente. Você precisa abrir um diff e saber em poucos segundos se uma migração é reversível, se uma checagem de autenticação mudou de lugar, se uma query aguenta dez vezes o tráfego. Quem não sabe ler código não consegue revisar um agente, e quem não consegue revisar um agente não está conduzindo, só torcendo.

O que quebra primeiro quando você entrega a programação para os agentes?

A priorização. Quando construir leva uma tarde em vez de duas semanas, o custo de construir a coisa errada some do radar, então ela é construída. As equipes acabam com mais funcionalidades entregues e nenhum problema a mais resolvido. A segunda coisa a quebrar é o ciclo de retorno: os pedidos dos usuários chegam mais rápido do que alguém consegue triar, então se acumulam em threads de conversa e se perdem, e o mesmo pedido é construído duas vezes porque ninguém percebeu que era o mesmo.

Qual é a habilidade mais difícil nesse novo fluxo de trabalho?

Escrever um briefing que um agente não consiga ler errado. Um agente não vai contestar uma instrução ambígua como um colega faria: ele preenche os buracos com um palpite plausível e entrega uma coisa coerente e errada. Quem obtém bons resultados não é quem tem prompts espertos, é quem mantém contexto reutilizável de pé: arquivos de convenção versionados no Git, um procedimento salvo por tarefa recorrente, uma memória de projeto que os agentes leem antes de explorar, e capturas de tela ou desenhos em vez de parágrafos descrevendo uma tela.

Os agentes de código devem rodar na sua máquina ou numa máquina remota?

Nos dois, escolhendo caso a caso. Tudo o que você quer acompanhar, interromper ou corrigir no meio do caminho fica na máquina à sua frente. Trabalho longo, bem especificado, sem zona cinzenta vai para outra máquina sua ou para um servidor por SSH, para que um serviço de duas horas não deixe o seu notebook de refém. A pergunta que decide não é potência, é a probabilidade de você precisar intervir.

A versão curta

O trabalho não desapareceu. Ele saiu do editor e foi morar na cadeia em volta dele.

Se você quiser mudar uma única coisa neste mês, escolha o elo um. Tudo o que vem depois dele é esforço desperdiçado quando está apontado para o problema errado, e é o único elo em que uma hora da sua atenção ainda ganha de uma hora de tempo de agente por um fator que ninguém sabe medir.