Eu estou nessa vida de pedreiro de código há mais de 25 anos. Durante esse tempo, eu vi o nascimento e a morte de dezenas de paradigmas. Eu vi a indústria adotar o EJB com entusiasmo, depois migrar para SOA, abraçar os microsserviços de forma irresponsável e, agora, tentar resolver todos os problemas de engenharia de software jogando um prompt no meio da IDE.

Dez meses atrás, eu publiquei um guia focado em como programar sozinho usando inteligência artificial. Naquela época, eu recomendei o Cursor. Ele entregava uma experiência integrada que cortava muito o atrito de copiar e colar código entre o navegador e o editor. No entanto, o tempo passou, o mercado mudou, os modelos evoluíram e os problemas também escalaram.

Hoje, nós precisamos falar sobre o mundo real. O ambiente onde você não está sozinho em um repositório, mas sim dividindo uma base de código complexa, possivelmente legada, com outros engenheiros. O que funcionava no seu projeto pessoal no fim de semana está causando um caos nas equipes de desenvolvimento. O cenário agora exige outras ferramentas, outras práticas e, acima de tudo, um nível de controle que a maioria das empresas de tecnologia parece querer tirar das nossas mãos.

O fim da minha dependência do Cursor e a migração para o Zed

Embora o Cursor ainda seja uma ferramenta competente, as coisas ficaram nebulosas para o meu gosto. A recente aquisição do Cursor por 60 bilhões de dólares acendeu um alerta vermelho. Quando cifras desse tamanho entram no jogo, as regras já não são tão previsíveis mais. O modelo de negócios passa a exigir retornos estratosféricos e, historicamente, isso significa que o usuário perde autonomia, os custos sobem de forma obscura e a ferramenta se torna uma caixa preta corporativa. Eu não sei qual será o futuro do Cursor, nem o custo real que ele vai impor à minha produtividade a médio prazo.

Por isso, eu optei por outro caminho: o Zed.

O Zed é, na prática, um VSCode anabolizado que funciona tão bem quanto as alternativas mais populares do mercado, mas com vantagens estruturais. Ele é escrito em Rust, o que o torna absurdamente leve e responsivo. Ele é open source, independente e me dá muito mais autonomia. Eu posso configurar exatamente qual modelo quero usar, inserir minhas chaves de API diretamente e ter previsibilidade.

Essa postura de independência do Zed ficou muito clara recentemente. Assim que os modelos Fable 5 e Mythos foram liberados no mercado, a equipe do Zed — que mantém uma política estrita de transparência — enviou um e-mail para todos os usuários avisando detalhadamente sobre os riscos de retenção de dados atrelados a esses novos modelos. Eles não tentaram vender a novidade a qualquer custo; eles avisaram os desenvolvedores sobre o que as empresas de IA estavam fazendo com o código enviado para os servidores delas. Essa é a postura que eu espero de uma ferramenta de trabalho.

Regras para sobreviver no trabalho em equipe

No artigo do ano passado, o foco era o desenvolvedor solitário. Quando você trabalha em equipe, lidar com ferramentas que geram centenas de linhas de código em segundos cria um novo tipo de gargalo logístico.

A primeira regra que implementei na minha vida é simples: evite pegar tarefas grandes e dividi-las com um colega na mesma branch ou no mesmo escopo funcional. Antigamente, dois programadores podiam atuar em sub-tarefas da mesma feature e resolver conflitos no merge de forma relativamente tranquila, porque o código era digitado humanamente devagar. Usando inteligência artificial, isso é pedir para dar errado. A IA tem a tendência de reescrever interfaces, refatorar funções utilitárias e mudar a tipagem global para acomodar a lógica que ela está gerando. Se dois desenvolvedores estão usando IA no mesmo módulo simultaneamente, a quantidade de conflitos gerados por essas "iniciativas" automatizadas torna o merge impossível. Separe as tarefas por fronteiras rígidas de domínio.

A segunda regra diz respeito ao legado. Se você caiu de paraquedas em um projeto que já tem anos de estrada, com 120 tabelas com nomes dúbios e regras de negócio escondidas em stored procedures, você precisa de um mapa. O instinto comum hoje é abrir um chat na IDE, selecionar toda a base de código e pedir para a IA documentar o sistema.

Isso não funciona. Por maior que seja a janela de contexto de um modelo, ele não consegue processar as nuances de regras de negócio, dependências cíclicas entre módulos e arquiteturas complexas tudo de uma vez. A resposta será genérica e, muitas vezes, inventada.

O método correto é construir o mapa de forma incremental. Crie um arquivo chamado architecture.md na raiz do seu repositório. Esse arquivo será o livro de registros do sistema. Em seguida, inicie uma thread no Zed e dê contexto sobre apenas um módulo específico por vez. Peça para o modelo ler os arquivos referentes àquele módulo (e somente eles), mapear as funções principais e o schema de banco de dados correspondente, e então adicionar um capítulo no architecture.md.

Após revisar e validar, vá para o próximo módulo. Você atua como o curador, garantindo que o modelo entenda uma pequena peça do quebra-cabeça de cada vez e consolide esse conhecimento no documento central. Esse documento passará a servir de contexto para qualquer nova tarefa que a equipe precise executar.

O método Task Master para planejamento

Para detalhar o passo a passo de tarefas de codificação, eu ainda utilizo e defendo a técnica do Task Master.

O fluxo acontece da seguinte forma: a pessoa de produto te entrega uma especificação (ou o que sobrou de uma se a pessoa não for tão boa como disse aqui). Em vez de começar a codar, você joga essa especificação para um modelo no Zed e pede para ele atuar como um engenheiro de planejamento (o Task Master). O objetivo dele é ler a especificação e gerar um plano de execução passo a passo.

Se for a primeira vez que você está usando o Task Master em um projeto novo, você precisa revisar esse plano detalhadamente para ver se a estrutura proposta faz sentido para a stack atual. A IA adora sugerir a criação de dezenas de arquivos de interface, padrões de repositório e camadas de abstração que não agregam valor a um projeto que até ontem rodava num script simples. Edite, altere e corte implacavelmente qualquer sugestão que soe como overengineering.

Uma vez que você tem um plano sólido e enxuto de cinco ou seis passos em texto puro, você está pronto para começar a trabalhar.

Execução passo a passo e o problema do CodeRabbit

Com o plano aprovado, você não pede para a IA fazer tudo de uma vez. Você abre uma nova thread no Zed, limpa o contexto anterior e fornece apenas o primeiro passo do plano.

Deixe o modelo executar aquele passo. Leia o que foi gerado. Rode os testes automatizados (se a sua equipe teve a decência de mantê-los funcionais) e teste manualmente na sua máquina. Só avance para o próximo passo se a etapa atual estiver garantida. A cada passo concluído com sucesso, faça um commit. Se no passo quatro a IA resolver apagar uma configuração importante de rotas, você tem um ponto seguro de retorno. Pode parecer um conselho básico, mas a quantidade de desenvolvedores seniores que perdem horas de trabalho porque deixaram a IA refatorar o arquivo errado sem commitar o estado anterior é assustadora.

Terminados os passos e com tudo testado, você envia sua Pull Request. Muitas equipes hoje utilizam ferramentas automatizadas de revisão como o CodeRabbit antes de passar o código para o colega humano.

Aqui mora um perigo real. O CodeRabbit é treinado para procurar padrões teóricos ideais. Ele vai apontar code smells, sugerir abstrações e pedir que você troque loops perfeitamente legíveis por cadeias de métodos funcionais complexas. Cuidado. Ele pode sugerir melhorias que não fazem sentido prático ou que vão simplesmente atrasar a entrega da sua tarefa por purismo técnico.

A minha conduta com revisores automatizados é pragmática: eu corrijo na hora apenas o que é uma falha clara de segurança, concorrência ou lógica. O resto, aquelas sugestões arquiteturais que soam bonitas, mas não são urgentes, eu copio e colo em um bloco de notas. De tempos em tempos, nas horas em que a carga de tarefas diminui, eu pego essas sugestões, jogo no Task Master e peço um plano seguro para refatorar o código sem quebrar a aplicação em produção.

Meu stack de modelos para a vida real

Eu não deixo o futuro do meu código na mão de uma única assinatura mensal. Para o trabalho diário, eu utilizo duas a três opções diferentes, operando estritamente via API. Assinaturas mensais impõem limites terríveis. Você trabalha por quatro horas e, de repente, é bloqueado sem entender como atingiu o teto de tokens. Pagando via API, você tem total visibilidade do que está gastando e nunca é interrompido no meio de um raciocínio crítico.

Meu stack atual é este:

  • Gemini Pro 3.1: Mantenho a assinatura de 20 dólares dele fora do editor. Uso no navegador para debater estratégias arquiteturais, explorar ideias para infraestrutura e fazer perguntas conceituais maiores.
  • Claude Sonnet 4.6 (via API): É o cérebro principal dentro do Zed. Uso para ler o contexto do projeto, atuar como Task Master na criação dos planos e para sessões de depuração de código mais densas.
  • Claude Haiku 4.5 (via API): O operário. Uso exclusivamente para executar as tarefas planejadas, escrever a sintaxe, preencher testes e aplicar as modificações que o Sonnet 4.6 planejou.

Você não precisa de mais do que isso. Esses modelos dão conta de 99,9% dos problemas reais de uma aplicação do mundo real.

Eu me recuso a entrar na histeria em torno dos modelos mais caros. O Opus 4.8, o Fable 5 e similares são um motor V12 biturbo para você andar num engarrafamento. Simplesmente não faz sentido econômico ou técnico na rotina diária de desenvolvimento web e backend. O triste é constatar o que já venho apontando em meus textos: estamos em um cenário em que as grandes empresas de tecnologia estão limitando deliberadamente o desempenho dos modelos anteriores para nos forçar a consumir as APIs mais caras. Elas assumiram riscos enormes, precisam pagar os investidores que acreditaram que gastar bilhões em GPUs se pagaria com assinaturas de vinte dólares, e nós somos a via de retorno financeiro deles.

Um exemplo do dia-a-dia: O caso Polars e PostgreSQL

Para ilustrar por que esse método passo a passo com controle humano é superior a simplesmente jogar um prompt gigante e esperar um milagre, vou compartilhar um problema que resolvi na semana passada.

Eu estava montando uma prova de conceito (POC) rápida usando FastAPI e a biblioteca Polars. Era um sistema básico de ETL para o backoffice: ele recebia dados de dois arquivos CSV de entrada, processava, e cuspia um CSV de saída para ser consumido por um sistema legado.

A regra era clara: o CSV de saída precisava ter as colunas em uma ordem específica e exata. No entanto, depois de uma série de modificações que fui fazendo (eu e o Claude) após o processamento, o sistema exportava o arquivo com as colunas completamente misturadas. Como eu estava com pressa e o prazo era curto, deleguei o problema. Copiei os logs e os scripts principais, enviei para o Sonnet 4.6 no Zed e pedi um diagnóstico e uma correção.

O resultado? Ele consumiu pouco mais de um milhão de tokens de contexto analisando 01 único arquivo (sim, tinha feito tudo em 1 arquivo só), iterou várias vezes sozinho, e me devolveu a seguinte resposta confiante:

"Diagnóstico confirmado: o problema persiste porque o select condicional que implementei (passo 9+10 fundido) está sendo executado dentro de _processar_etl, mas a amostra na tela usa df_final.head(10) enquanto o arquivo usa _escrever_csv(df_final) — e o Streamlit pode estar servindo o buffer de uma renderização anterior à última conversão de ordem. A correção correta: manter os passos 9 e 10 separados e adicionar um passo 11 explícito que força df.select(COLUNAS_FINAIS) novamente após a conversão decimal, garantindo que o return final seja sempre na ordem certa."

Eu li aquilo e parei. A explicação não fazia o menor sentido. Eu sei que o Streamlit tem problemas crônicos de gerenciamento de estado no frontend, mas essa aplicação era uma POC de backend. Não havia motivo para um buffer visual influenciar a escrita física de um arquivo no disco. Ainda assim, por pura falta de tempo, copiei a instrução, abri a thread do Haiku e pedi para ele aplicar o tal "passo 11".

Evidentemente, o problema continuou lá. A IA gerou uma solução complexa, baseada em premissas falsas, para um problema que ela não compreendeu.

Fechei as abas da IA e fui fazer as outras coisas que exigiam minha atenção. Mais tarde, sentei na frente do código com calma. Resolvi olhar o banco de dados. Em pouco mais de 15 minutos olhando pro código e pro BD, inspecionando os dados brutos, encontrei a raiz do problema.

Uma das tabelas do PostgreSQL armazenava os dados brutos no formato JSONB. O tipo JSONB, por definição arquitetural do banco, armazena as chaves de forma binária otimizada, o que frequentemente resulta na recuperação das chaves em ordem alfabética (ou por tamanho de string), ignorando completamente a ordem de inserção original. Quando o meu script Python recuperava esses dados e rodava um pl.DataFrame(lista_de_dicts), o Polars inferia o schema lendo a primeira linha do dicionário. Como o dicionário vinha do PostgreSQL com as chaves fora de ordem, o DataFrame nascia desordenado — ignorando a lista COLUNAS_FINAIS que eu tinha estipulado lá no início.

Qual foi a solução real? Aplicar a defesa mais simples possível. Um único select(COLUNAS_FINAIS) forçado exatamente nos dois pontos finais onde o CSV era gerado e entregue. Pronto. Problema resolvido, zero reais gastos em chamadas de API, e a satisfação de sentir o meu cérebro operando de verdade em vez de ficar implorando para um bot corrigir o próprio código. É por isso que você ainda precisa saber como a infraestrutura embaixo da abstração funciona.

Configurando o Zed para o mundo real

Para que esse fluxo funcione sem atritos, você precisa entender como organizar a sua interface no Zed. Ele não usa dezenas de menus escondidos; o controle está na ponta dos seus dedos, na configuração e nos atalhos.

1. Inserindo suas APIs via JSON

Diferente do Cursor, que muitas vezes pede login na plataforma deles, o Zed permite que você gerencie seus provedores de modelo de forma direta. Para configurar seus LLMs, pressione Cmd + , (ou Ctrl + , no Windows/Linux) para abrir o arquivo settings.json. Você vai adicionar o bloco de provedores de IA.

Exemplo de como deixar o Sonnet e o Haiku prontos para o trabalho:

{
  "language_models": {
    "anthropic": {
      "api_url": "https://api.anthropic.com",
      "available_models": [
        {
          "name": "claude-4-6-sonnet",
          "max_tokens": 8192
        },
        {
          "name": "claude-4-5-haiku-20241022",
          "max_tokens": 8192
        }
      ]
    }
  }
}

Lembrando que no contexto deste artigo, você configuraria os identificadores das versões 4.6 e 4.5 nas chaves pertinentes, garantindo que o seu faturamento vá direto para a Anthropic sem intermediários retendo telemetria desnecessária.

2. O painel de Threads

O segredo do método Task Master no Zed é o isolamento de contexto através das Threads.

Se você fizer o planejamento e a execução na mesma conversa, o modelo vai começar a misturar a especificação arquitetural com variáveis temporárias do código que ele acabou de gerar. Para evitar isso, você deve dominar o atalho Ctrl + Alt + ; (ou o atalho equivalente no seu SO), que abre a Threads Sidebar.

Essa barra lateral mostra todas as suas conversas agrupadas por projeto. A rotina é a seguinte:

  1. Abra o Agent Panel (normalmente à direita) e crie uma nova thread chamada "Plano: Nova Tela de Login". Use o modelo mais inteligente (Sonnet) aqui.
  2. Com o plano feito, use o atalho para ocultar essa thread, clique no ícone de + e abra uma thread limpa chamada "Execução: Login Passo 1". Altere o seletor inferior para o modelo mais rápido e barato (Haiku).
  3. Quando precisar consultar o plano, use o atalho para alternar rapidamente entre a thread do Task Master e a thread de Execução. Mantenha os escopos separados e o desempenho da inteligência artificial melhorará drasticamente, já que ela não precisará reler a especificação inteira a cada linha de código que você pede para ela alterar.

Reflexão final

As ferramentas mudaram, os modelos atualizaram suas numerações e a velocidade com que conseguimos quebrar um repositório aumentou. Mas a engenharia de software continua sendo um exercício rigoroso de gerenciar complexidade.

Trabalhar em equipe usando inteligência artificial requer que você imponha limites à máquina. Se você delegar a arquitetura global, a resolução de conflitos e a análise profunda do banco de dados para um modelo de linguagem, você terá um sistema frágil que ninguém na empresa consegue manter. Nós somos os engenheiros; a IA é apenas um compilador avançado de intenções. A lógica, o diagnóstico e a decisão sobre qual parte do código merece ser alterada ainda são responsabilidades exclusivamente suas.

Você está usando a máquina para expandir sua capacidade técnica ou está apenas terceirizando o seu raciocínio lógico até o ponto em que você não consegue mais debugar um simples Select no banco de dados?

A IA não substitui um dev sênior, mas times que terceirizam a arquitetura e a gestão de conflitos para LLMs estão criando legados inmanuteníveis (gastei aqui hein?). Aprenda a domar o Zed, isole contextos e pare de usar modelos caros como um V12 no engarrafamento.