22 pontos por GN⁺ 2025-04-23 | 3 comentários | Compartilhar no WhatsApp
  • Ferramentas de LLM não substituem programadores; elas amplificam a capacidade dos desenvolvedores
  • Com a experiência de uso do Claude Code, a velocidade de programação aumentou drasticamente, mas o julgamento arquitetural e a supervisão contínua ainda são indispensáveis
  • Com a adoção de LLMs, definição de problema e design se tornaram tarefas mais importantes do que a programação em si
  • Como a IA também amplifica erros, desenvolvedores inexperientes correm o risco de não perceber falhas da IA
  • No futuro da programação, as competências centrais serão colaborar com a IA, exercer julgamento e ter a coragem de apagar

Programação com LLM é reforço, não substituição humana

  • Ferramentas de programação baseadas em LLM são como um mecha suit que amplifica a capacidade do desenvolvedor
  • O autor desenvolveu recentemente uma plataforma de agentes backend e um app SaaS frontend usando Claude Code
  • Ao escrever mais de 30 mil linhas de código, ele vivenciou na prática o impacto dos LLMs
  • O Claude Code não substitui o usuário; é uma ferramenta que amplia a capacidade do desenvolvedor, como o power loader da Ripley
  • Decisões de arquitetura, controle de qualidade e definição de direção continuam sendo liderados por humanos
  • A IA leva vantagem em velocidade e tarefas repetitivas, mas uma direção errada pode levar a resultados desastrosos

Vigilância: codificação com IA exige atenção constante

  • O Claude Code às vezes toma decisões estranhas e, para fazer os testes passarem, ignora o problema de raiz ou recorre a hardcode
  • Também ocorrem casos de mudança forçada de framework ou adição de dependências desnecessárias
  • Como um piloto, em momentos importantes a intervenção humana é indispensável
  • Em um momento de distração, a IA seguiu na direção errada, e foi preciso reescrever completamente o código backend três vezes
  • LLMs reduzem a carga da codificação, mas aumentam a carga de supervisão e manutenção da arquitetura

Mudança na economia do tempo de programação

  • O tempo de programação tradicionalmente se divide em três áreas: por quê (objetivo), o quê (design) e como (codificação)
  • Após a adoção do Claude Code, o tempo gasto no "como" ficou próximo de zero
  • Porém, pensar sobre o "por quê" e o "o quê" se tornou ainda mais importante
  • Como gerar código ficou fácil, agora é preciso ter coragem para descartar código existente sem apego e escolher uma abordagem melhor
  • Essa capacidade de decisão ainda não é familiar para muitos desenvolvedores, e entramos numa era em que o julgamento de design importa mais do que o tempo de implementação

A diferença que a experiência faz

  • Para usar IA com eficácia, é preciso insight e julgamento de quem tem 30 anos de experiência
  • Mesmo quando o código funciona, é importante detectar antipadrões inadequados para escalabilidade ou manutenção
  • Desenvolvedores inexperientes tendem a deixar passar problemas no código gerado pela IA e correm o risco de se satisfazer apenas com o efeito imediato
  • A IA amplifica não só capacidades, mas também erros, portanto, sem julgamento, o risco também aumenta

Efeito centauro: colaboração entre humano e IA

  • Como no xadrez centauro, vindo do xadrez, a combinação de IA e humano produz resultados melhores do que a IA sozinha
  • O mesmo vale para a colaboração com o Claude Code: o humano fornece a direção estratégica e a IA executa o trabalho tático
  • O método mais eficaz foi escrever a especificação seguindo o fluxo de pensamento e refiná-la junto com o Claude
  • Como o Claude não consegue fazer julgamentos adequados ao contexto, supervisão e decisão humanas são sempre necessárias

Encontrando o equilíbrio: ajustar delegação e controle

  • Quando a IA é deixada solta, ela frequentemente tenta resolver problemas de forma excessivamente complexa
  • Ex.: escrever código duplicado, fazer escolhas tecnológicas equivocadas e outros mau funcionamentos da IA geram problemas reais
  • No frontend também se repetiram situações em que foi preciso induzir correções de implementações irregulares em JavaScript para abordagens de Elixir ou LiveView
  • É preciso estabelecer um ritmo de colaboração em que tarefas simples e repetitivas sejam delegadas, enquanto partes que exigem julgamento complexo recebam intervenção direta
  • Graças à IA, foi possível desenvolver rapidamente, mas sem intervenção humana provavelmente não teria funcionado corretamente

O futuro é aumento, não substituição

  • LLMs não vão substituir completamente os programadores, mas vão mudar profundamente a forma de trabalhar e as competências necessárias
  • Pensamento estrutural, reconhecimento de padrões e julgamento técnico se tornarão mais importantes do que habilidade de codificação pura
  • A própria capacidade de colaborar com IA está surgindo como uma nova competência técnica
  • Os desenvolvedores bem-sucedidos do futuro não terão medo da IA; serão aqueles que entendem e sabem lidar tanto com seus limites quanto com seu potencial
  • A IA não é uma ferramenta para eliminar humanos, mas para expandir as possibilidades humanas

3 comentários

 
bus710 2025-04-23

Eu não sou o Amuro e também não recebi um Gundam...?

 
jsh5782 2025-04-23

Só porque a diferença de desempenho entre mobile suits não é uma diferença decisiva no poder de combate..

 
GN⁺ 2025-04-23
Comentários do Hacker News

Mais importante do que codar é entender o problema e fazer o design

  • Tradicionalmente, programar se divide em três blocos de tempo
    • Por que estamos fazendo isso? Entender o problema de negócio e o valor envolvido
    • O que deve ser feito? Projetar conceitualmente a solução
    • Como fazer? Escrever o código de fato
  • A última etapa consumia muito tempo no passado, mas agora, graças ao Claude, quase não consome mais
    • Se você ainda gasta muito tempo na última etapa, isso pode significar que as duas primeiras foram mal resolvidas ou que você não domina a ferramenta
    • Editar código manualmente traz incômodos, mas em muitas linguagens isso já é automatizado por IDEs e indexadores
    • Em projetos de programação, passei mais tempo entendendo o problema
  • Ou seja, entendimento do problema e design consomem mais tempo
    • Codar está entre as etapas mais fáceis
    • Quando demora muito, pode ser por falta de familiaridade com a ferramenta ou deficiência no design
  • O design de estruturas de dados é fundamental
    • Quando a estrutura está bem definida, codar é só uma implementação simples
    • Nessa parte, humanos são melhores que LLMs

Limites e cuidados com LLMs

  • LLMs frequentemente tomam decisões erradas
    • Ex.: adicionar dependências desnecessárias, gerar código vulnerável
    • Uma pessoa precisa necessariamente revisar e corrigir
  • Não conseguem reconhecer sozinhos problemas de segurança
    • Ex.: injection, configurações incorretas de permissão
  • Perdem desempenho em codebases grandes
    • Por causa da limitação da janela de contexto, falham em entender a estrutura completa

Ganhos de produtividade oferecidos pelos LLMs

  • São muito eficazes em tarefas repetitivas e simples
    • Em boilerplate, código de teste etc., há economia de tempo
  • Usá-los na fase de planejamento é mais eficiente
    • São úteis para rascunhos de system design, decomposição de funcionalidades etc.
  • Excelentes para aprender linguagens ou frameworks desconhecidos
    • Permitem entender o fluxo básico mais rápido do que com a documentação tradicional

A importância da experiência e do julgamento técnico

  • Para usar bem LLMs, experiência se torna ainda mais importante
    • É preciso capacidade de julgar estruturalmente o problema e filtrar o que importa
  • Mesmo que o LLM gere código, revisão e refatoração continuam sendo trabalho humano
    • Algo “funcionar” e algo estar “certo” são coisas diferentes

LLM não substitui o desenvolvedor, é uma ferramenta de apoio

  • LLM está mais para o papel de um desenvolvedor júnior
    • Sem direcionamento claro, produz resultados fora do alvo
  • A combinação humano + LLM é melhor do que um LLM sozinho
    • A estratégia fica com a pessoa; o trabalho repetitivo, com a IA

O resultado muda conforme a forma de uso do LLM

  • Se você depender apenas de geração automática de código, pode até ficar mais lento
    • Principalmente em linguagens com as quais já tem familiaridade, a pessoa costuma ser mais rápida
  • Interfaces baseadas em autocompletar (Copilot etc.) são as mais naturais
    • É fácil receber ajuda sem interromper o fluxo

Mudanças no trabalho e preocupações trazidas pelos LLMs

  • O papel central do desenvolvedor está migrando de escrever código para projetar e revisar
  • Depender apenas de LLMs pode significar perder oportunidades de aprendizado e crescimento
    • Há o risco de não desenvolver base técnica profunda e virar um usuário passivo

O futuro dos LLMs e seu impacto social

  • Em um ambiente em que todos podem usar IA, são as pessoas que fazem a diferença
    • Capacidade de julgamento e habilidade de comunicação determinam a competitividade
  • LLM é uma "ferramenta como um carro"
    • É poderoso, mas a dependência aumenta e fica mais difícil reagir quando surgem problemas