Programar não foi resolvido
As alegações de que “programar foi resolvido” pelos grandes modelos de linguagem recebem forte reação de engenheiros que apontam que escrever trechos ou portar código é muito diferente de projetar, verificar e manter sistemas complexos. Os comentaristas descrevem a IA como um acelerador extremamente poderoso para boilerplate, refatoração e busca de bugs, mas dizem que a programação agentic frequentemente produz bases de código frágeis, inchadas ou opacas, que ainda exigem humanos experientes para arquitetura, estratégia de testes e responsabilização. O consenso emergente é que a IA mudou radicalmente a forma como o código é produzido, especialmente para tarefas rotineiras, mas não eliminou as partes difíceis da engenharia de software nem a necessidade de julgamento humano.
“Programar” foi resolvido? Posições divergentes
- Um grupo afirma que “programar hoje está resolvido”: os LLMs de fronteira conseguem escrever, ler, portar e otimizar código na maioria das linguagens em nível igual ou superior ao humano típico, especialmente para CRUD, algoritmos e refatorações.
- Outros argumentam que isso é exagerado: o código gerado por LLM ainda é pior do que o bom código humano, especialmente em arquitetura, manutenção de longo prazo e requisitos não funcionais (NFRs).
- Vários distinguem “programar em pequena escala” (funções, endpoints, ports) como em grande parte resolvido vs. “engenharia de software” (requisitos, design, trade-offs, ciclo de vida) como longe de resolvida.
Capacidades vs. limites dos modelos atuais
- Histórias de sucesso: grandes ports (por exemplo, centenas de milhares de LOC TypeScript→Rust), fluxos de trabalho Agentic intensivos, implementações de jogos de tabuleiro, grandes ganhos de produtividade (10×+ alegados).
- Críticos observam que esses são muitas vezes problemas contidos com oráculos fortes (comportamento existente, suítes de testes) e não provam que o design de sistemas greenfield de ponta a ponta está resolvido.
- Planejamento de longo prazo, arquitetura global e design de API/tipos à prova do futuro são citados repetidamente como pontos fracos.
Qualidade, slop e revisão de código em escala
- Muitos relatam que a IA capacita desenvolvedores fracos a produzir quantidades muito maiores de código mal compreendido, sobrecarregando a revisão humana (de dezenas a centenas de milhares de LOC por semana).
- Revisores de código de IA frequentemente implicam com estilo enquanto deixam passar falhas profundas de design; “IA revisando IA” é visto como perigoso sem forte supervisão humana.
- Algumas organizações já tratam PRs gerados por IA como essencialmente não revisados, levando a regressões, perda de observabilidade e problemas sutis de correção/desempenho.
Testes, determinismo e “compreensão”
- Lado pró-IA: se você tiver especificações fortes e testes automatizados massivos, importa menos quem/o que escreveu o código; testes e fuzzers também podem ser gerados por IA.
- Lado cético: ainda é preciso humanos para definir o que testar, interpretar requisitos e notar comportamentos que não foram especificados; caso contrário, os agentes otimizam apenas o que está nos testes e deixam todo o resto deriva.
- Debate sobre “não determinismo”: alguns dizem que a estocasticidade dos LLMs não é pior do que erro humano; outros enfatizam que geração opaca e não repetível não é análoga a compiladores ou bibliotecas comprovadas.
Responsabilização, risco e domínios
- Há amplo acordo de que a responsabilização continua sendo humana/organizacional; a IA não pode ser punida nem responsabilizada legalmente.
- Alguns argumentam que a maior parte do software empresarial é de baixo risco e o slop de IA é “bom o suficiente”; outros observam que até sistemas mundanos (pagamentos, logística, administração de saúde) podem causar danos no mundo real quando falham.
Impacto sobre papéis e habilidades
- Nova “habilidade”: orquestrar agentes, escrever AGENTS.md e documentos de arquitetura, projetar especificações e testes, e controlar merges em vez de programar manualmente.
- Preocupações com “overdose de IA” e deskilling: juniores talvez nunca desenvolvam capacidade profunda de resolução de problemas; seniores sentem que décadas de experiência em programação estão sendo desvalorizadas.
- Muitos preveem menos funções de “code monkey”, mas demanda contínua por pessoas capazes de raciocinar sobre sistemas, requisitos e trade-offs.