Como melhorar a capacidade de programação usando IA

• Quero usar ferramentas de IA para código para reduzir tarefas de conversão que levariam 1 a 2 horas para uma revisão de 15 a 20 minutos
• Mas, no momento, a qualidade do código gerado pela IA não chega nem a 90% da qualidade do código que eu mesmo escrevo, então parece que isso não ajuda de forma prática
• Por isso, quero entender como usar IA para aumentar ao mesmo tempo a produtividade e a qualidade do código

Coletânea de dicas práticas para aumentar a eficiência e a qualidade da programação com IA

1. Concentrar a IA apenas em tarefas repetíveis

• A IA gera o maior efeito quando executa várias vezes trabalhos de formato semelhante
• Na primeira vez, a pessoa implementa diretamente com a melhor qualidade possível e usa isso como exemplo de referência
• Depois, delega à IA as tarefas com o mesmo padrão para processamento em massa
• Em tarefas que exigem raciocínio e julgamento, a eficiência esperada cai rapidamente

2. Sempre criar um plano antes de codar

• Em vez de gerar código de imediato, escreva primeiro o plano de solução
• Na etapa de planejamento, faça com que todas as partes ambíguas e perguntas apareçam
• Se o plano não estiver satisfatório, não passe para a etapa de execução
• A qualidade do resultado depende mais da clareza do documento de planejamento do que do prompt

3. Dividir a unidade de trabalho em partes extremamente pequenas

• Faça pedidos por arquivo, por componente ou por algumas funções
• Solicitações como “refatoração completa” ou “melhorar de forma idiomática” têm alta chance de falhar
• A pessoa faz o desenho da estrutura, e a IA cuida apenas da implementação repetitiva

4. Não acumular contexto; reinicializar com frequência

• Quanto mais longa a conversa, mais o cumprimento de regras e a qualidade caem rapidamente
• Cada sessão deve tratar apenas de uma tarefa
• Se a direção mudar, recomece em uma nova sessão
• Em trabalhos longos, preserve o estado em documentos (plan.md etc.) e reinsira esse contexto

5. Fazer documentos de regras curtos e mecânicos

• Mantenha CLAUDE.md / AGENTS.md entre 500 e 1000 tokens
• Em vez de instruções declaratórias, escreva principalmente regras concretas e verificáveis
• Registre ao mínimo apenas o que costuma dar erro com frequência
• O restante deve ser forçado por código e verificações automáticas

6. Usar testes, linter e build como loop de feedback

• Em vez de “faça bem feito”, apresente claramente as condições de aprovação
• Defina como meta passar nos testes, build bem-sucedida e 0 erros de linter
• Só com um loop de feedback a IA consegue convergir sozinha
• Testes que validam o comportamento existente reduzem bastante a dificuldade de refatoração

7. Não corrigir durante a execução; ajustar o plano e executar de novo

• Se o resultado não agradar, não fique repetindo pedidos de correção de código
• Ajuste o documento de planejamento e execute de novo em uma nova sessão
• Se mudar a direção durante a fase de execução, a qualidade se deteriora rapidamente

8. Ensinar estilo com base em exemplos

• Instruções abstratas como “código bom” quase não têm efeito
• Forneça exemplos Before / After junto
• Apresente de forma clara bons e maus exemplos
• Expanda as regras com base nos exemplos

9. Não abrir mão da compreensão e definir claramente os limites de responsabilidade

• Todo código gerado pela IA deve ser compreendido e revisado por uma pessoa
• Fora protótipos e código de baixo risco, é proibido usar sem revisão
• Em código de segurança, operação e manutenção de longo prazo, a compreensão é pré-requisito de qualidade

10. Verificar primeiro se a tarefa é adequada para IA

• Trabalhos sem resposta certa e com forte componente estético ou estrutural são desfavoráveis para IA
• Refatoração de UI, em que é difícil validar automaticamente o resultado visual, é especialmente complicada
• Se necessário:
  • Etapa 1: transformação mecânica com o objetivo de preservar o comportamento
  • Etapa 2: a pessoa realiza a refatoração de qualidade

11. Começar com a expectativa de uma “melhoria de 10%”

• Não espere 10x logo de início
• Uma estratégia de acumular pequenas melhorias é mais eficaz no longo prazo
• O essencial é não abrir mão do design e dos padrões de qualidade

[GN⁺]

Opiniões do Hacker News

• Sou Boris, da equipe do Claude Code. Compartilhando algumas dicas

  1. É bom anotar no CLAUDE.md as partes em que o Claude frequentemente erra ou não entende. O Claude lê esse arquivo automaticamente
  2. Use ativamente o modo Plan (Shift+Tab duas vezes): fazer um plano primeiro e depois executar pode gerar resultados 2 a 3 vezes melhores em tarefas difíceis
  3. É bom fornecer uma forma de validar o trabalho. Por exemplo, no Svelte dá para usar o servidor MCP do Puppeteer para conferir o resultado no navegador
  4. Recomendo o modelo Opus 4.5. Parece claramente um upgrade em relação ao Sonnet 4.5
     Espero que ajude
  • Eu também tive um grande ganho de produtividade graças ao modo Plan. Mas nas versões recentes surgiu um bug em que o modo Plan continua se referindo apenas ao primeiro plano da sessão, e isso quebrou meu fluxo de trabalho. Fico em dúvida se estou usando de um jeito fora do normal
  • Depois de corrigir o Claude durante o trabalho, é bom executar um prompt de self-reflection. Esse processo reflete automaticamente no CLAUDE.md o que foi ajustado manualmente
  • Concordo com os conselhos acima. Especialmente o loop de feedback do item (3) é o ponto-chave. É preciso permitir que o modelo corrija por conta própria e confira o resultado. Fazer com que ele deixe arquivos de log ou monte um plano em pseudocode também ajuda a resolver problemas complexos rapidamente
  • O Opus 4.5 é realmente um divisor de águas. Foi de grande ajuda ao refatorar um projeto React antigo. Se você escrever prompts com precisão e configurar bem o CLAUDE.md, o efeito é grande
  • O CLAUDE.md funciona bem só até umas 4 ou 5 vezes, e depois esquece as instruções. Por exemplo, mesmo mandando me chamar de “Mr. bcherny”, ele logo esquece
  • Em comparação com o Google Jules, o Claude Code pareceu muito mais como um desenvolvedor profissional. Porém, no Claude Code Web não existe recurso de projeto, então recebi a resposta de usar um arquivo .clinerules; queria entender a diferença em relação ao CLAUDE.md
  • Um recurso útil do CLAUDE.md é o @import. Se você colocar @ antes do nome do arquivo, pode forçar sua inclusão no contexto. Mas, se usar demais, fica ineficiente

• Ao usar entrada por voz, o modelo entende a intenção com mais precisão. Eu dito prompts de cerca de 500 palavras. Ao falar, o pensamento flui de forma mais natural do que digitando.
  Se você disser “faça um plano e pergunte se tiver dúvidas”, o Claude realmente faz perguntas. Também é eficaz instruí-lo a imitar o estilo de código anterior

  • Eu também fiz quase todo o laboratory.love por voz. Uso bastante um atalho com a frase “antes de escrever código, analise o problema e os requisitos e pergunte o que estiver ambíguo”
  • Falar rápido não significa falar sem pensar. Na verdade, o problema pode ser justamente falar pensando menos
  • Falar com a IA quando alguém está ouvindo é meio estranho, mas frases longas eu também costumo inserir por voz
  • Fiquei curioso sobre qual serviço de reconhecimento de voz você usa

• É preciso incluir uma condição de loop (loop condition) no prompt. Ex.: “repita até que yarn test passe”.
  No fim das contas, um LLM é um agente que executa ferramentas repetidamente, então deve ser tratado assim
  Referência: Prompting the Agent Loop

• Recomendo a configuração nori-profiles que eu criei.
  Após 4 meses de experimentos, o desempenho do Claude Code melhorou visivelmente.
  Texto relacionado: Averaging 10 PRs a Day with Claude

  • Fiquei curioso sobre qual é a diferença em comparação com as skills do Claude Code

• Na empresa, lidamos com uma grande base de código em Golang. Testei várias ferramentas, como Cursor, Claude Code e Gemini CLI, mas a maioria fica sobrecarregada pela quantidade de código.
  Já o aider foi muito mais fácil de controlar e teve maior precisão. Adicionar arquivos é manual, mas a precisão é quase 100%.
  Com o Claude Sonnet mais recente ou o Gemini 2.5 Pro, ele é o mais preciso

  • O ponto forte do aider é justamente não ser totalmente agentic. Como o contexto é gerenciado manualmente, ele não modifica arquivos errados. Também tem vantagem em economia de tokens e velocidade

• Quando trabalho com o Cursor, primeiro faço com que ele gere um arquivo de regras enquanto refatora uma rota. Depois, nas outras rotas, basta pedir “refactor”

  • Não tenha medo de prompts longos. Isso é exatamente context engineering. O próprio histórico da conversa enriquece o contexto.
    É bom ficar sempre atento à capacidade de contexto restante e, se necessário, fazer context clear cedo

• A perspectiva de tratar o agente como um colega de equipe é importante. É preciso observar os pontos fortes e fracos de cada lado e ajustar a forma de colaboração.
  Eu concentro a força do agente em problemas verificáveis ou em código experimental.
  Não conheço muito Svelte, mas talvez seja uma boa induzir a reescrita com testes descartáveis no estilo TDD.
  Às vezes, o melhor é descartar o contexto anterior incorreto e recomeçar em um novo workspace

  • Seria bom se você pudesse compartilhar um resumo daquele texto sobre “estilo cognitivo e trabalho em equipe”

• Eu vejo os LLMs como buscadores (searchers). Se você faz perguntas pequenas e específicas, a busca fica mais fácil, e quanto mais longe dos dados de treino, maior a probabilidade de erro.

  1. Abro o projeto no Zed
  2. Conecto Gemini CLI, Qwen code ou Claude
  3. Peço para modificar arquivos e testo
  4. Se não funcionar, tento no Grok ou no Gemini 3 Chat
  5. Se ainda assim não der, resolvo manualmente
     Em projetos novos, até um prompt one-shot costuma ser suficiente
  • Mas prompts pequenos demais causam problema de underspecification. Só reduzem o custo computacional; em termos de qualidade, são desvantajosos

• O conjunto de ferramentas do Claude Code que mais gosto é o superpowers

  1. Primeiro faço uma sessão de brainstorming para explicar a funcionalidade
  2. O Claude escreve um documento de design e um plano de implementação e salva no disco
  3. Em uma nova janela do Claude, executo o comando Execute Plan para realizar tudo por etapas e fazer commits
  4. A cada três etapas, faço ele se revisar para elevar a qualidade do código
     Estou usando há duas semanas e quase nunca falhou

• Meus princípios de programação com IA são simples

  1. Concluir tudo de uma vez (one-shot) falha
  2. Divida a tarefa em unidades verificáveis
  3. Organize o plano geral em um arquivo Markdown
  4. Execute cada etapa em uma nova sessão, revise e depois faça commit
     O ponto principal é “Less is more”. Quanto mais nova a janela de contexto, melhor, e algo em torno de 500 a 750 palavras é o ideal. Todas as etapas precisam ser verificáveis

• Em tarefas relacionadas a Java, o Claude muda de direção com frequência ou faz sugestões contraditórias. Sinto que o ChatGPT é muito melhor

  • Isso pode melhorar se você der instruções mais específicas no prompt
  • Fiquei curioso se você já testou a versão Claude Code

• Se você quer código idiomático, primeiro precisa definir em detalhes qual é o estilo que considera adequado. Separe pequenos exemplos de bom e mau código, coloque isso no modo Plan do Opus 4.5 para montar um plano e depois execute. Se não ficar perfeito de primeira, edite o documento de planejamento e tente de novo. Tentar orientar em cada detalhe como se fosse um desenvolvedor júnior acaba sendo ineficiente

  • Outra pessoa compartilhou a experiência de que “os modelos de hoje em dia não exigem necessariamente começar uma nova sessão”, e que até com refatoração inline a estabilidade já é suficiente