Você não está mais codificando sozinho(a): O desenvolvimento na era dos code agents

Você se senta na frente do computador, café na mão. Não abre o IDE. Só digita: "MCP, me de três opções de arquitetura pro novo sistema de billing." Cinco minutos depois, você está analisando os trade-offs entre microservices, event-driven e um monólito com filas — com configs de CI e planos de testes inclusos. Bem-vindo à sua nova rotina matinal.. Hoje em dia, todo mundo parece ter um agente de codificação (code agent) (que não é não o James Bond). Se você rolar o feed do Twitter ou abrir o GitHub, vai ver vários devs usando agentes pra corrigir bugs, abrir PRs, escrever testes e até fazer deploy — com pouquíssima intervenção humana. A frase "é só rodar o prompt" virou uma estratégia real de desenvolvimento (quase um mantra). Mas no meio de toda essa empolgação, vale parar pra pensar: o que isso muda, de fato, no nosso dia a dia como desenvolvedores? A indústria de tech vive nos bombardeando com buzzwords que prometem revoluções — e quase nunca entregam. Dessa vez, no entanto, a chegada de ferramentas como o GitHub Copilot marca uma mudança real na forma como desenvolvemos software. Estamos saindo do modelo de dev “linha por linha” pra um novo fluxo mais colaborativo, onde criamos em parceria com a máquina. Não é hype: é transformação de verdade. Do que estamos falando, afinal? (LLMs, MCPs e Code Agents) Antes de ir mais fundo, vale alinhar alguns termos. LLMs (Modelos de Linguagem de Grande Escala) são o ponto de partida. Modelos como o GPT-4, Claude e Gemini foram treinados em quantidades absurdas de texto e código. Eles conseguem explicar, raciocinar e dar respostas técnicas muito boas — até para perguntas mais "cabeludas". Mas aqui vai um ponto-chave: LLMs sozinhos não constroem software. Eles não entendem seu código. Não mantêm contexto a longo prazo. Não testam, refatoram ou fazem deploy. Eles só preveem o próximo token com base em probabilidade. E só. Claro, eles podem gerar uma função ou um arquivo de config aqui e outro ali. Mas sem memória, integração com ferramentas e noção do que fizeram minutos atrás, eles não dão conta de tarefas reais de desenvolvimento. Pra construir software de verdade, é necessário estrutura, objetivos claros, ferramentas que executem em conjunto, coordenação entre tarefas, memória pra acompanhar o progresso e mecanismos de feedback pra saber se algo funcionou — basicamente o que todo dev precisa no dia a dia. LLMs são o cérebro. Mas cérebro sozinho não constrói app — precisa de mãos, ferramentas e um plano. MCPs – Plataformas de Código com Múltiplos Agentes - é aqui onde a coisa começa a ficar interessante. Em vez de depender de um único LLM pra fazer tudo, você monta um time de agentes especializados. Um é bom em debugar, outro em testar, outro em planejar arquitetura — e talvez um que só escreve documentação (o verdadeiro herói, sejamos sinceros). É como ter seu squad de devs incansáveis, ultra rápidos e que já leram todo repositório do GitHub, todas as threads do StackOverflow e todas as RFCs que você ignorou nos últimos anos — e que nunca cansam, se distraem ou pedem café. A Anthropic foi uma das primeiras a formalizar esse padrão/protocolo, mostrando como múltiplos agentes podem colaborar um objetivo em comum. Hoje, ferramentas como AutoDev, Devika, e DSPy estão colocando essa ideia em prática. LLMs são o cérebro. Mas para construir software de verdade, você precisa de mais: ferramentas, coordenação e orientação humana. Quer criar um CRUD do zero? Você descreve o que quer, o agente que planeja quebra isso em tarefas, o executor escreve o código, o testador valida tudo e o revisor te dá feedback — em questão de minutos. Não é só sobre automação. É sobre coordenação — e é isso que torna os LLMs realmente úteis em fluxos de trabalho mais complexos. E aí entram os Code Agents — ferramentas autônomas baseadas em LLMs que executam tarefas completas. Você dá uma missão tipo “adicione autenticação nessa API” e eles planejam, codam, testam e às vezes até abrem o pull request por você. Já estamos vendo isso acontecer em ferramentas como: Claude’s Code Interpreter que consegue raciocinar sobre tarefas complexas, editar múltiplos arquivos e ainda explicar tudo passo a passo. GitHub Copilot que começou como autocomplete esperto e agora tem o Copilot Workspace — um assistente de planejamento e codificação completo, que te guia por problemas e soluções. Cursor a IDE com IA integrada, onde você conversa com seu repositório e pede pra ele refatorar, gerar código ou debugar — com contexto. Esses agentes não entregam só snippets — eles ajudam a construir. Você para de escrever tudo na unha. Em vez disso, descreve o objetivo, orienta o processo e revisa o resultado. Você não está mais só programando. Você tá liderando um time (pequeno e incansável). A Nova Manhã do Dev Você não começa mais o dia abrindo o seu IDE — você pede pro seu MCP explorar algumas opções de arquitetura pra aquela nova feature. Ele gera o código, roda os testes e

Mar 30, 2025 - 10:28
 0
Você não está mais codificando sozinho(a): O desenvolvimento na era dos code agents

Você se senta na frente do computador, café na mão. Não abre o IDE. Só digita:
"MCP, me de três opções de arquitetura pro novo sistema de billing."

Cinco minutos depois, você está analisando os trade-offs entre microservices, event-driven e um monólito com filas — com configs de CI e planos de testes inclusos.

Bem-vindo à sua nova rotina matinal..

Hoje em dia, todo mundo parece ter um agente de codificação (code agent) (que não é não o James Bond). Se você rolar o feed do Twitter ou abrir o GitHub, vai ver vários devs usando agentes pra corrigir bugs, abrir PRs, escrever testes e até fazer deploy — com pouquíssima intervenção humana. A frase "é só rodar o prompt" virou uma estratégia real de desenvolvimento (quase um mantra).

Mas no meio de toda essa empolgação, vale parar pra pensar: o que isso muda, de fato, no nosso dia a dia como desenvolvedores? A indústria de tech vive nos bombardeando com buzzwords que prometem revoluções — e quase nunca entregam. Dessa vez, no entanto, a chegada de ferramentas como o GitHub Copilot marca uma mudança real na forma como desenvolvemos software. Estamos saindo do modelo de dev “linha por linha” pra um novo fluxo mais colaborativo, onde criamos em parceria com a máquina. Não é hype: é transformação de verdade.

Do que estamos falando, afinal? (LLMs, MCPs e Code Agents)

Antes de ir mais fundo, vale alinhar alguns termos.

LLMs (Modelos de Linguagem de Grande Escala) são o ponto de partida. Modelos como o GPT-4, Claude e Gemini foram treinados em quantidades absurdas de texto e código. Eles conseguem explicar, raciocinar e dar respostas técnicas muito boas — até para perguntas mais "cabeludas".

Mas aqui vai um ponto-chave: LLMs sozinhos não constroem software.

Eles não entendem seu código. Não mantêm contexto a longo prazo. Não testam, refatoram ou fazem deploy. Eles só preveem o próximo token com base em probabilidade. E só.

Claro, eles podem gerar uma função ou um arquivo de config aqui e outro ali. Mas sem memória, integração com ferramentas e noção do que fizeram minutos atrás, eles não dão conta de tarefas reais de desenvolvimento.

Pra construir software de verdade, é necessário estrutura, objetivos claros, ferramentas que executem em conjunto, coordenação entre tarefas, memória pra acompanhar o progresso e mecanismos de feedback pra saber se algo funcionou — basicamente o que todo dev precisa no dia a dia.

LLMs são o cérebro. Mas cérebro sozinho não constrói app — precisa de mãos, ferramentas e um plano.

MCPs – Plataformas de Código com Múltiplos Agentes - é aqui onde a coisa começa a ficar interessante. Em vez de depender de um único LLM pra fazer tudo, você monta um time de agentes especializados. Um é bom em debugar, outro em testar, outro em planejar arquitetura — e talvez um que só escreve documentação (o verdadeiro herói, sejamos sinceros).

É como ter seu squad de devs incansáveis, ultra rápidos e que já leram todo repositório do GitHub, todas as threads do StackOverflow e todas as RFCs que você ignorou nos últimos anos — e que nunca cansam, se distraem ou pedem café.

A Anthropic foi uma das primeiras a formalizar esse padrão/protocolo, mostrando como múltiplos agentes podem colaborar um objetivo em comum. Hoje, ferramentas como AutoDev, Devika, e DSPy estão colocando essa ideia em prática.

Uma ilustração digital de estilo plano mostrando um desenvolvedor humano colaborando com vários agentes de IA flutuantes. Cada agente representa uma tarefa — codificação, teste, planejamento — enquanto o desenvolvedor orquestra todo o processo com foco calmo em um espaço de trabalho futurista.
LLMs são o cérebro. Mas para construir software de verdade, você precisa de mais: ferramentas, coordenação e orientação humana.

Quer criar um CRUD do zero? Você descreve o que quer, o agente que planeja quebra isso em tarefas, o executor escreve o código, o testador valida tudo e o revisor te dá feedback — em questão de minutos.

Não é só sobre automação. É sobre coordenação — e é isso que torna os LLMs realmente úteis em fluxos de trabalho mais complexos.

E aí entram os Code Agents — ferramentas autônomas baseadas em LLMs que executam tarefas completas. Você dá uma missão tipo “adicione autenticação nessa API” e eles planejam, codam, testam e às vezes até abrem o pull request por você.

Já estamos vendo isso acontecer em ferramentas como:

Claude’s Code Interpreter que consegue raciocinar sobre tarefas complexas, editar múltiplos arquivos e ainda explicar tudo passo a passo.

GitHub Copilot que começou como autocomplete esperto e agora tem o Copilot Workspace — um assistente de planejamento e codificação completo, que te guia por problemas e soluções.

Cursor a IDE com IA integrada, onde você conversa com seu repositório e pede pra ele refatorar, gerar código ou debugar — com contexto.

Esses agentes não entregam só snippets — eles ajudam a construir. Você para de escrever tudo na unha. Em vez disso, descreve o objetivo, orienta o processo e revisa o resultado.

Você não está mais só programando. Você tá liderando um time (pequeno e incansável).

A Nova Manhã do Dev

Você não começa mais o dia abrindo o seu IDE — você pede pro seu MCP explorar algumas opções de arquitetura pra aquela nova feature. Ele gera o código, roda os testes e apresenta os trade-offs.

Você escolhe a melhor, dá feedback de alto nível, e deixa seus agentes configurarem o projeto, prepararem o CI, escreverem os testes e até esboçarem a documentação.

Seu papel? Guiar, refinar e garantir que tudo faz sentido pro produto e pro domínio — e claro, revisar o código esquisito da IA também (lol).

Ferramentas como AutoDev, GPT Engineer e Claude Code já permitem que você descreva um sistema e veja ele ganhar vida — com código real, testes e configs.

Essa virada muda a forma como a gente trabalha:

  • Menos digitação, mais "promptação"
  • Menos execução linear, mais orquestração
  • Menos apagar incêndio (um caloroso abraço a todos os bombeiros de plantão), mais design
  • Menos trabalho solo, mais colaboração com agentes

Mas esse novo fluxo também exige novas skills:

  1. Prompting: não é só pedir, é saber direcionar
  2. LLMOps: saber debugar, isolar, controlar comportamento
  3. Pensamento sistêmico: menos sintaxe, mais estratégia

A Revolução Que Já Aconteceu

Isso não é só papo de futuro. Já está acontecendo — e rápido.

Mais de 1,3 milhão de devs já usam o GitHub Copilot, que ajuda com boilerplate, sugere funções inteiras e economiza horas em tarefas repetitivas. O Copilot Workspace agora vai além: ele planeja, quebra problemas em etapas e orienta a implementação.

O Claude Code lê sua base inteira, explica o que tá acontecendo e ajuda a refatorar — com explicações claras, quase como um pair programming. Já o Devika analisa seu repositório, pensa numa solução, escreve o código e abre um pull request, coordenando múltiplos LLMs no processo.

O Cursor permite conversar direto com seu código dentro do IDE. Enquanto isso, ferramentas como o AutoDev e o DSPy orquestram múltiplos agentes agindo em sincronia: um planeja, outro implementa, outro testa.

Está nascendo um padrão claro aqui. E um paper recente capturou isso bem: a engenharia de software está migrando da geração de código pra coordenação de agentes. Não se trata mais só de digitar menos — mas de usar sistemas autônomos que ajudam a planejar, construir e manter software de verdade.

Essa mudança não é sobre substituir devs. É sobre dar mais alavancagem pra gente.

Não É Mágica. Pelo Menos, Ainda Não.

LLMs não têm memória persistente. Elas alucinam constantemente, perdem o contexto e se atrapalham em bases grandes de código.

Elas são ótimos pra gerar uma função. Mas integrar essa função em um sistema real — com código legado, efeitos colaterais e edge cases — é outro jogo.

Mesmo quando o código parece limpo, é difícil saber se está seguro, correto ou fácil de manter sem revisar tudo a fundo.

E ainda há outros riscos: dependência excessiva, acesso a shell, e aquela preguiça que vai te fazendo esquecer como pensar nos problemas sozinho.

Sim, as ferramentas são poderosas. Mas ainda precisam do nosso julgamento ao usá-las.

Não é sobre tirar a mão do volante — é sobre aprender a dirigir diferente.

Quando o "Vibbing" Substitui o Ententimento

Uma pintura digital em um estilo semi-realista mostra um desenvolvedor focado em um moletom escuro, cercado por energia neon rodopiante. O codificador parece estar transcendendo, imerso em um estado de fluxo profundo enquanto símbolos abstratos e fragmentos de código flutuam ao redor.
Quando o vibe coding domina: o dev entra em transe enquanto a IA carrega o piano (bugs inclusos).

Ou: Por que “só mandar o prompt” nem sempre resolve.

Tá rolando um mindset novo chamado "vibe coding" (ref e ref). A ideia é simples: você descreve o que quer, o LLM cospe um código, e você... faz deploy. Você não entende o que tá acontecendo por baixo dos panos — mas pelo menos roda, né?

E sim, isso é poderoso. Principalmente pra iniciantes, não-devs ou quem tá automatizando rapidinho alguma tarefa.

Mas pra quem trabalha com software profissionalmente? Aí começa a ficar perigoso.

Se você para de entender o código que tá subindo — se não consegue explicar a lógica, resolver um bug ou perceber um erro sutil — você não está mais construindo software. Está só cruzando os dedos esperando que a IA tenha acertado tudo feito mágica.

Vamos dar um exemplo: um dev júnior usou o GPT pra gerar um endpoint de "delete user". Parecia ok. Mas ele deletava todos os usuários do banco — porque não validava o user_id. A IA só fez o que foi pedido. O prompt não cobriu o edge-case.

Outro caso: um dev usou o Copilot pra “proteger” uma API, adicionando checagem de JWT mas esqueceu de verificar a assinatura. Parecia tudo seguro. Ele rodou em staging, mas quando rodou em produção, quebrou e expôs dados sensíveis.

Aqui tá o que o Claude Code gerou quando pediram pra “Adicionar autenticação via JWT nesse endpoint”:

app.post('/login', async (req, res) => {
const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET, { expiresIn: '1h' });
res.json({ token });
});

Não é ruim. Mas ele esqueceu de verificar as assinaturas nos requests recebidos. É aí que você, dev, entra.

Esse é o risco de priorizar velocidade e "vibbing" acima de entendimento.

No longo prazo, isso pode dar ruim:

  1. Código podre — agentes geram código que ninguém entende ou quer manter
  2. Debugar vira arqueologia — tentando entender decisões bizarras da IA
  3. Riscos de segurança — só porque “funciona” não quer dizer que está seguro
  4. Erosão de habilidade — você vai perdendo o faro técnico por não pensar mais nos problemas

Code agents são úteis, mas precisam ser tratados como devs júnior: rápidos, incansáveis — mas que precisam de acompanhamento.

Se você não sabe programar, não sabe revisar código, e se não consegue revisar o que a máquina entrega, você só está mandando suas esperanças e torcendo pro CI passar.

Mas aqui vai o plot twist: enquanto tem gente preocupada com a IA tirando empregos, eu vejo o surgimento de dois novos nichos de devs.

De um lado, iniciantes e não-devs criando produtos novos com Claude, Copilot, etc.
Do outro, cresce a demanda por devs experientes que entram depois — pra escalar, manter, revisar e dar segurança a esse código gerado dessa forma.

Ao invés de acabar com empregos, a IA tá reformulando o mercado — e criando mais trabalho pra quem sabe ler nas entrelinhas do que ela produz.

Vamos parar de "vibear" código que vai explodir em produção.

Eu mesmo, 2025

Abraçando a Máquina Sem Perder a Nossa Essência

ilustração digital amigável de um desenvolvedor de software sorridente apertando as mãos de dois robôs humanoides alegres, simbolizando a colaboração entre humanos e IA no desenvolvimento de software.
Não é homem contra máquina — é homem com máquina. O novo stack dev se constrói com confiança, ferramentas e parceria.

Num post anterior, escrevi que deveríamos ser amigos das nossas ferramentas. Isso continua valendo mais do que nunca. LLMs são poderosas, mas ainda são só isso: ferramentas.

O melhor dev dessa nova era não vai ser o que escreve mais código. Vai ser o que transforma uma ideia vaga num plano claro, que um agente consegue executar. É quem sabe revisar, adaptar e melhorar o que a máquina devolve.

Quer ficar bom nisso? Começa pequeno (mas começa!).

Teste o Claude Code numa feature que você já conhece bem. Refatore uma função, corrija um bug, escreva testes — depois revise tudo como faria com um dev júnior.

Use o GitHub Copilot como dupla, não como guru. Deixe ele sugerir, mas decida o que faz sentido manter.

Explore seu repo com o Cursor. Faça perguntas, tente uma refatoração, quebre tudo de propósito e veja como ele se vira.

Rode seus LLMs localmente com Ollama e Docker. Este vídeo, feito pelo meu amigo Erick Wendel (com quem já tive o prazer de trabalhar), mostra como rodar modelos; como DeepSeek e Gemma; local ou na nuvem — ótimo pra quem quer entender o que acontece por baixo dos panos.

Esse é nosso novo work: digitar menos, pensar mais. Menos força bruta, mais design. Mais colaboração e delegação pra máquina.

E esse artigo aqui? Foi escrito com ajuda de alguns LLMs. Eles me ajudaram a buscar papers, organizar ideias e ajustar frases ruins. Mas todas as decisões fui eu quem tomou — eles só tornaram o processo mais rápido.

E você?

Tá liderando seus agentes — ou só "vibbing" no meio do caos?

Quero muito saber quais ferramentas você já testou, o que funcionou (ou não) e como você está se adaptando a elas.

Quais ferramentas você está usando? Como você tá evoluindo com elas?

Deixa um comentário, responde aí ou me chama (estou em kaic.me).

Bora continuar construindo — junto — esse novo jeito de desenvolver.

Assine a newsletter pra receber os próximos posts e apoiar meu trabalho — https://kaicbento.substack.com/about.

Recursos & Referências

Quer mergulhar mais fundo? Separei ferramentas, demos e leituras essenciais pra explorar: