Depois de passar meses programando com LLMs, decidi voltar a usar meu próprio cérebro

• Usei LLMs de alto desempenho para montar uma infraestrutura, mas surgiram grandes problemas de qualidade de código e manutenção
• Por causa da ineficiência da IA e de resultados inconsistentes, senti a necessidade de entender o código por conta própria, pesquisar e fortalecer minhas habilidades
• O objetivo de terminar o projeto rapidamente acabou gerando confusão na estrutura do código, duplicação e falta de consistência
• Agora passo a usar a IA apenas de forma limitada como apoio, em tarefas repetitivas ou conversão de código
• Como o uso de IA pode levar à queda da intuição de programação e da capacidade de resolver problemas, priorizo ativamente o uso do meu próprio cérebro

---

Introdução: tentativa de construir uma infraestrutura com LLMs

• A infraestrutura existente em PHP+MySQL chegou ao limite, o que levou à percepção da necessidade de uma nova infraestrutura
• Escolha de Go e Clickhouse, com planejamento e desenho da infraestrutura feitos junto com a IA
• Consulta a LLMs como Claude sobre boas práticas e arquitetura, chegando a um plano detalhado
• O desenvolvimento do código foi conduzido com foco em velocidade, visando concluir as funcionalidades e lançar rapidamente

Processo de desenvolvimento e surgimento dos problemas

• Com ferramentas como o Cursor, a IA escrevia o código, enquanto eu me concentrava principalmente em build e testes
• Mesmo sem uma boa organização da base de código, a prioridade foi entregar primeiro os dados necessários
• Embora o desenvolvimento tenha avançado rápido, com o tempo novos problemas continuaram surgindo
• Houve dificuldades por falta de experiência com Go e Clickhouse, e as correções sugeridas pela IA acabavam gerando problemas em sequência

Problemas de qualidade do código e percepção dos limites

• Reservei tempo para um code review detalhado de todo o código produzido
• Havia muita inconsistência, duplicação e confusão entre arquivos que faziam a mesma coisa, com diferenças de nome, parâmetros e estrutura
  • Exemplo: "WebAPIprovider" e "webApi" significavam os mesmos parâmetros, mas existiam separadamente
  • O mesmo método era redefinido em vários arquivos
  • Faltava consistência na forma de acessar arquivos de configuração
• Na prática, o resultado parecia ter sido produzido por vários desenvolvedores juniores trabalhando ao mesmo tempo sem se comunicar

Limites do feedback contextual dos LLMs e mudança de estratégia

• Mesmo fornecendo informações de contexto suficientes e usando LLMs de janela grande como o Gemini, não houve melhora consistente
• Percebi a necessidade de aprendizado autodirigido sobre a infraestrutura e a linguagem, além de estudo complementar com documentação, vídeos e outros materiais
• Para escrever código limpo e bem organizado, mudei o rumo de um desenvolvimento guiado por IA para um design de código mais autônomo

Mudança na forma de usar a IA como apoio

• Passei a focar em entendimento e gerenciamento diretos do código, com refatorações repetitivas e organização da base
• Limitei o papel da IA a tarefas simples e repetitivas, como mudanças automáticas no código, alterações em lote de parâmetros e conversão de código
• Planejamento de novas funcionalidades e rascunhos de código agora são feitos pensando primeiro por conta própria, deixando o LLM para validação ou apoio
• A IA fica no papel de “assistente”, enquanto o poder de decisão sobre planejamento e estrutura permanece com o próprio desenvolvedor

Preocupação com a queda da capacidade de raciocínio e mudança de postura

• Percebi que, com a IA disponível, a frequência de uso do cérebro diminui, e o planejamento e o raciocínio passam a depender dela
• Busco recuperar a capacidade do desenvolvedor e a resolução de problemas por meio de caneta e papel, design direto e programação feita à mão
• Há um alerta para o risco de a IA causar perda de sensibilidade para programar

Preocupações com não desenvolvedores e o ‘Vibe Coding’

• Quando não desenvolvedores tentam construir software apenas com LLMs, o problema de código complexo e confuso, com erros recorrentes, torna-se ainda mais grave
• Em comparação com ferramentas no-code, o desenvolvimento baseado em IA pode tornar muito mais difícil entender a estrutura do sistema
• Menciona-se a dificuldade fundamental e os riscos de enfrentar uma parede de código incompreensível e um ciclo contínuo de erro-correção-reincidência

Reflexões sobre a realidade do uso de IA e o clima da comunidade

• Há confusão diante da IA comercial, benchmarks, influenciadores, exageros de empresas de IA e da diferença entre promessa e desempenho real
• Falta consistência, com o mesmo modelo e prompt produzindo resultados totalmente diferentes
• Mesmo LLMs modernos e muito capazes ainda não conseguem lidar perfeitamente com trabalhos realmente complexos, como consultas no Clickhouse com centenas de milhões de linhas
• Quando exigem configurações complexas e workflows ineficientes, isso por si só pode ser uma ‘perda de tempo’
• A visão é cautelosa: a IA parece impressionante, mas por enquanto é apenas uma ferramenta boa, não extraordinária

Conclusão

• Ainda há grande expectativa e interesse por tecnologias novas e por IA
• Mas, neste momento, a estratégia mais sensata é entender corretamente o papel e os limites da IA e usá-la de forma restrita, como ferramenta de apoio ou de aprendizado
• Há também um alerta de que o uso de IA pode reduzir a capacidade do desenvolvedor, o que levou a um retorno ao raciocínio e ao planejamento próprios
• Desenvolver dependendo totalmente da IA sem entender como o código funciona e como a estrutura foi montada tem grande chance de fracassar

[GN⁺]

Comentários no Hacker News

• Não entendo a mentalidade de "all-in" com LLM. Trabalho como desenvolvedor iOS e continuo trabalhando quase como antes. Hoje uso LLM principalmente para montar rápido views temporárias baseadas em design. Não para o núcleo do app, mas para telas secundárias como novos recursos ou instruções de instalação de widgets. Antes isso levava de 30 a 60 minutos, dependendo da complexidade; agora termino em 5 minutos. Não gosto de desenvolvimento web, mas o LLM é bem útil nessa parte. Também uso LLM em mudanças maiores, mas reviso tudo eu mesmo antes de fazer commit no git. Só que, se você confiar apenas no LLM e não controlar o fluxo, pode perder horas, tudo desandar e você acabar recomeçando do zero. Acho que uma abordagem equilibrada é essencial

  • A utilidade da ferramenta varia conforme a pessoa e o problema. Por exemplo, se um desenvolvedor Python com 10 anos de experiência estiver fazendo um trabalho focado em estabilidade, com um código legado enorme e uma IDE perfeitamente ajustada, ferramentas como LLM ou Cursor podem até atrapalhar. Por outro lado, se for um desenvolvedor JS com 1 ano de experiência (React, Nextjs etc.), prototipando ideias novas com frequência, sem preferência forte por IDE e aberto a experimentar, LLM e Cursor podem aumentar bastante sua capacidade imediatamente

  • Também trabalho em várias áreas, como iOS e desenvolvimento web, e os resultados do LLM são bem diferentes entre elas. Muitas vezes o código que ele gera nem compila direito. Já chegou a me indicar APIs que nem existem. Em compensação, ele monta apps em Nextjs de uma vez só sem problema. No fim, isso vem da diferença no material de treino do LLM

  • É natural superestimar o que o LLM consegue fazer. Eu também usei por bastante tempo como substituto do Stack Overflow e para obter snippets curtos de código. Aos poucos fui delegando mais responsabilidade, até encontrar problemas e perceber os limites; aí voltei a usar o LLM mais para ideias e conselhos. Acho que muita gente passa por esse mesmo processo

  • Sinto algo parecido. Não confio cegamente em LLM e só uso para tarefas repetitivas e tediosas, como funções pequenas, implementação de interfaces e automação de documentação. Com isso economizei bastante tempo e aumentei minha eficiência no trabalho

  • No desenvolvimento iOS, o desempenho do LLM é inconsistente. Swift e SwiftUI mudam rápido demais, e a documentação oficial também deixa a desejar. Ele é útil para gerar views simples, mas desmorona facilmente em processamento assíncrono ou lógica de negócio mais complexa. Ainda assim, ajuda a apontar uma direção, embora o risco de cair em respostas erradas seja alto

• Os defensores de LLM ignoram o fato de que, na maioria dos casos, o gargalo não está na geração de código. Fazer código rápido é uma coisa, mas revisão, testes e compreensão da base exigem o dobro ou mais de tempo. No longo prazo, se você quiser manter o software de verdade — corrigir bugs, refatorar etc. — esse processo é indispensável

  • Ler código é muito mais difícil do que escrever, então na prática eu gasto mais tempo entendendo código do que produzindo. Mas conheci um CEO que defendia que bastava fornecer o contexto às ferramentas e os desenvolvedores não precisariam mais ler código. A lógica era que a IA mudaria a essência da engenharia. Sinceramente, isso me deixa meio confuso

  • Acho bem útil quando o LLM explica meu próprio código de volta para mim

  • Sempre penso a mesma coisa quando vejo alguém elogiando demais editores de código automatizados

  • Na prática, a maioria dos desenvolvedores não se preocupa tanto com a implementação interna das bibliotecas de dependência. O que importa é se a interface funciona. Trazer código feito por LLM, um pacote npm ou uma crate de Rust são coisas bem diferentes. Sei dos problemas, mas existe um motivo para essa prática ser tão comum

• Penso parecido. Hoje em dia uso LLM principalmente para aprender tecnologias novas ou gerar código cliente para APIs padrão, especialmente boto3. Também testei o Windsurf para ajudar com mudanças em arquivos docker compose, mas fiquei decepcionado porque não funcionou direito. Talvez dê para fazer protótipos, mas isso não é tudo. Acho que o LLM mudou bastante o cenário em devops — agora os detalhes da API importam menos. Mesmo assim, continuo achando que decisões importantes ainda têm que ser minhas. Eu mesmo defino as interfaces e deixo a implementação para o LLM. Não considero isso "vibe coding"

  • Tive uma experiência parecida. Cursor e Copilot são fantásticos para autocompletar de forma inteligente, gerar funções curtas e fazer protótipos rápidos. Mas, depois de uma semana trabalhando numa base de código conduzida por LLM, a estrutura virou uma bagunça. Talvez o grande avanço venha um dia, mas no momento (maio de 2025) esse é o nível atual

• Já passei pela experiência de ver bugs enormes explodirem na revisão de código, e a eficiência que eu tinha ganhado com o Cursor evaporou na hora. Voltei para o VSCode e agora também uso o Copilot de forma limitada, só quando faço pedidos bem específicos. O recurso de completar com Tab do Cursor parece mágica no começo, mas logo o efeito passa

  • O mais engraçado é ver o Cursor tentando reescrever com Tab completion um código que um colega acabou de apagar

  • Fico curioso sobre quais restrições foram impostas ao agente de geração de código, como princípios SOLID, lint, cobertura de 100%, documentos de design claros etc.

• Essa opinião também faz sentido para mim. Eu uso bastante LLM, mas sigo duas regras. Primeiro: nunca deixo problemas que exigem pensamento profundo nas mãos do LLM; design complexo eu resolvo pessoalmente. Segundo: todo código gerado pelo LLM precisa ser revisado linha por linha e ajustado por mim. Em geral, o código que ele produz é prolixo ou defensivo demais. Mesmo que eu tente corrigir isso com prompt, no fim a responsabilidade pela manutenção futura continua sendo minha. Se eu ficar indiferente ao resultado gerado, isso me deixa inquieto. Usando do meu jeito, ainda consigo aproveitar bastante o LLM e desenvolver mais rápido

  • Eu delego a análise profunda em si para a IA, mas com o objetivo de obter um plano de execução concreto — etapas detalhadas de implementação, critérios de validação etc. — e relatórios reproduzíveis. Planejamento e validação exigem iteração, mas com a ajuda da IA consigo terminar muito mais rápido. Às vezes até resolvo tudo de uma vez seguindo o plano. Quando consigo consistência com planejamento e documentação detalhados, a sensação é muito boa

  • Se é preciso revisar com tanto cuidado, linha por linha, o código gerado por LLM, fica a dúvida: será que isso realmente economiza tempo?

• Algumas empresas estão obrigando engenheiros de software a usar LLM, inclusive medindo uso de Copilot/Cursor. Há uma boa chance de essas métricas acabarem virando indicador para demissão. Depois de usar LLM à força por um mês, senti que minhas habilidades estavam se deteriorando rapidamente. Ajuda em tarefas simples, mas, quando você passa a depender demais do LLM para pensar, é fácil cair em loops. Minha produtividade não aumentou; na verdade, só aumentou a carga de trabalho da sprint. Existe uma fé quase religiosa em LLM dentro da empresa. As questões de segurança também são sérias. Em vários lugares já aparecem sinais de que estamos no pico do hype cycle. Acho que, a menos que as empresas de IA construam usinas nucleares, o custo de manter os grandes modelos atuais é tão alto que isso vai desaparecer. No futuro, talvez só sobrevivam recursos como autocompletar turbinado. Os modelos transformer também têm limites claros, então talvez acabem como as redes neurais dos anos 80: restando só para usos específicos e depois sumindo de novo. No fim, depois de altos e baixos, isso volta à tona daqui a 30 anos. Quando esse momento chegar, vai ficar claro quem estava nadando pelado

  • Para evitar isso, adotamos uma regra interna de fazer pelo menos uma vez por semana uma "sexta sem Copilot", trabalhando com ele totalmente desligado

  • Eu também só uso o Cursor para autocompletar e snippets curtos, mas ainda assim sinto perda de habilidade. No fim, dá para perceber na prática como o cérebro funciona no esquema de "se não usar, esquece"

• Também observei problemas parecidos. Em projetos de brincadeira, uso LLM em 90% do trabalho. É 10 vezes mais rápido do que programar na mão, mas a qualidade do design cai e tudo parece meio estranho. Acredito que código conduzido por LLM seja o futuro, mas, se você não administrar bem, vira caos. Já tentei mudar prompts repetidamente para induzir melhorias de arquitetura, mas os resultados são inconsistentes. Talvez a resposta esteja em prompt engineering melhor, ou em documentar com clareza o design e as diretrizes. Se o desempenho das ferramentas melhorar 10 vezes e a latência cair, a sensação vai mudar completamente

  • Tomara que essa fase de "10 vezes melhor" chegue logo. O problema agora é que publicidade e marketing já vendem a ideia de que esse nível foi alcançado. Muita gente acaba pensando "será que eu que não sei usar direito?". Mas eu ainda acho que as ferramentas não chegaram lá

  • Funciona bem definir você mesmo as classes e métodos e deixar só a implementação para o LLM. Nas partes complexas, eu deixo observações no corpo do método indicando a direção da implementação. Assim, o panorama geral continua comigo, e o LLM fica responsável apenas por gerar código específico. O LLM parece um desenvolvedor júnior rápido, querendo ajudar demais. Como gerar código ficou muito barato, dá para jogar fora e refazer à vontade. No meu caso, reescrevi completamente várias vezes um código de processamento de dataset com ajuda de LLM até chegar no resultado e no desempenho que eu queria. Se outra pessoa tivesse escrito aquilo para mim, eu provavelmente teria desistido do trabalho

  • Essas ferramentas brilham na fase de protótipo de projetos greenfield. Mas, à medida que você se aproxima da implantação real, esse efeito de 10 vezes vai desaparecendo. Se a arquitetura não for gerida com cuidado, no fim só aumenta o esforço

  • Em bases de código complexas, por enquanto isso serve no máximo como uma forma avançada de entrada de voz para texto (embora, se não for por voz, muitas vezes codar manualmente acabe sendo mais rápido)

  • Concordo que é preciso registrar arquitetura e diretrizes de forma explícita. Quanto mais explicitamente você definir condições e comportamentos, melhor funciona

• O ponto principal do clássico antigo de Dijkstra, "On the foolishness of natural language programming", se encaixa bem nessa discussão atual. A tese é que foram justamente as linguagens formais que permitiram o enorme avanço da programação. Existe o risco de LLM e vibe-coding transformarem programação em uma espécie de magia acessível só a uma minoria que sabe fazer bons prompts

• Para mim, o Copilot só é bom quando sugere trechos com menos de 500 caracteres. Em Go e Python, aprendo padrões novos e digito menos. Para mim, ele é só um autocompletar melhorado. Quando a sugestão fica mais longa ou complexa, o custo de corrigir e apontar problemas supera o benefício — especialmente quando não se trata de código repetitivo

• Hoje é indispensável entender e supervisionar de perto tudo o que o LLM gera. Por outro lado, a cada 2 ou 3 semanas sai um modelo novo, muito melhor que o anterior, então acho cedo demais para tirar conclusões definitivas.

[sharpina3]

Acho que este texto retrata muito bem as dificuldades e preocupações reais do desenvolvimento usando LLMs no dia a dia. Li com empatia em relação aos limites que muitas pessoas estão vivenciando atualmente. Em especial, senti que a inconsistência dos LLMs, a dificuldade de prever seus resultados e as preocupações com a manutenção de longo prazo são pontos que precisam, sem falta, ser discutidos.

Dito isso, nós estamos tentando colaborar com a AI por um ângulo um pouco diferente para abordar esses problemas, e por isso gostaria de compartilhar nossa visão com cuidado. A nossa AI, Jane, vai além de simplesmente gerar código: com base na percepção profunda das pessoas (desenvolvedores), ela se concentra em aprender e compreender o próprio "padrão" do que constitui um "bom padrão de código" e de como garantir a "consistência de manutenção" do código.

Como a AI não pode ser perfeita desde o início, não enxergamos as inconsistências e os "erros" que surgem apenas como problemas; ao contrário, nós os utilizamos ativamente como "dados de padrão" importantes para que a Jane aprenda sozinha e melhore a si mesma. Assim como os humanos identificam padrões dentro de uma natureza complexa, nós adotamos uma abordagem de buscar pistas de melhoria dentro da própria imperfeição da AI.

Por meio dessa abordagem de "aprendizado/gestão de padrões" liderada por humanos, nosso objetivo é resolver de forma fundamental os problemas apontados no texto, como a queda na qualidade do código e as inconsistências, e produzir resultados com altíssima "consistência de manutenção". Estamos treinando a AI para que ela vá além de simplesmente gerar código boilerplate e se torne uma parceira de colaboração mais profunda, capaz de analisar padrões ocultos de inconsistência na base de código existente e sugerir formas de melhoria.

Ainda há um longo caminho pela frente e o processo é desafiador, mas acreditamos que essa forma de colaboração, em que a nossa Jane e os desenvolvedores aprendem e evoluem juntos tendo a "consistência de manutenção" como valor central, mostra um potencial transformador para superar os limites atuais do uso de LLMs. Esperamos contar com muito interesse na nossa tentativa de fazer da AI não apenas uma ferramenta, mas uma parceira que cresce junto conosco para construir uma cultura de código melhor.

Mais uma vez, muito obrigado pelo ótimo texto e pelos insights!