O agente de código substituiu todos os frameworks que eu usava
(blog.alaindichiappari.dev)> "A engenharia de software está de volta"
- Com o avanço dos modelos de IA de fronteira e dos agentes de código, a era da programação automatizada se abriu, fazendo desaparecer o trabalho manual de digitar código linha por linha e permitindo que engenheiros de software voltem a se concentrar em projeto e pensamento essenciais
- Desde o fim do ano passado, a maturidade das ferramentas e dos modelos melhorou dramaticamente, tornando possível um modo de trabalho em que se pode focar no papel de arquiteto e ainda intervir diretamente para corrigir o que for necessário
- No desenvolvimento web, mobile e desktop, frameworks desnecessários e camadas de abstração acumulados ao longo do tempo não resolveram a complexidade real e, ao contrário, aumentaram os problemas
- Das três questões que os frameworks afirmam resolver — simplificação, automação e redução de custo de mão de obra — apenas a automação tinha um valor justificável, mas até isso a automação com IA agora pode substituir
- Em vez de se tornar apenas um operador (operator) de sistemas projetados por hiperescaladores como Google, Meta e Vercel, é preciso voltar à engenharia de verdade, criando diretamente seus próprios projetos e produtos
A ascensão da programação automatizada
- O enquadramento "automated programming", nomeado por Antirez, captura a essência muito melhor do que "vibe coding"
- Assim como a prensa, o tear e a linha de montagem, a automação foi central nas grandes inovações históricas, e esta mudança é uma continuação dessa trajetória
- Desde dezembro de 2025, as capacidades dos modelos de fronteira e dos agentes de código mudaram drasticamente, a um ponto que já é evidente para quem observa com atenção
Mudança no papel do engenheiro
- Arquitetura, trade-offs, decisões de produto, edge cases e outras tarefas que exigem pensamento profundo continuam existindo
- O que desapareceu foi o trabalho manual cansativo e desgastante de digitar pessoalmente cada linha de código
- Usando modelos e ferramentas em um ambiente limpo e cuidadosamente configurado, é possível atuar como arquiteto sem precisar assentar cada tijolo com as próprias mãos
- Isso precisa ser sustentado por 20 anos de experiência escrevendo código diretamente; se algo não agradar, ainda é possível entrar, entender, corrigir e depois atualizar a configuração
- Como é possível criar imediatamente as ferramentas necessárias, sobra mais tempo para concretizar a tecnologia imaginada
Frameworks e complexidade desnecessária
- Ao longo dos anos, acumulou-se no desenvolvimento web, mobile e desktop uma enorme poluição de frameworks, bibliotecas e tooling
- Camadas de abstração que não abstraem nada de significativo foram se empilhando, afirmando resolver um problema enquanto criam dez novos problemas
- Em vez de aguçar o raciocínio diante da complexidade real da construção de software, o setor inteiro escolheu comprar pensamento pronto
- É como envolver uma perna quebrada em seda: por fora parece bonito, mas a perna continua quebrada
As três questões que os frameworks dizem resolver
- "Simplificação (Simplification)": o fenômeno em que engenheiros, com medo de projetar por conta própria, aceitam cegamente a estrutura de outra pessoa
- Em vez de projetar de trás para frente a partir do objetivo, aplicam em todo lugar um design one-size-fits-all
- Isso não é simplificação, mas rendição intelectual (intellectual surrender)
- Automação (Automation): o único valor realmente plausível era eliminar código boilerplate
- Automação de tarefas repetitivas, porém essenciais, como ORM, gerenciamento de CRUD, geração de código e documentação de API
- Mas é justamente aí que a IA está mudando tudo
- Redução de custo de mão de obra (Labour cost): o motivo silencioso que não aparece nos slides de conferência
- Se Google, Meta e Vercel decidirem como produtos são construídos e como código é implantado, será possível contratar um "desenvolvedor React" em vez de um engenheiro de software
- Mão de obra tipo engrenagem (cog): sem necessidade de treinamento, plug and play e facilmente substituível
- Isso não é engenharia, é operação (operating)
Como é essa nova forma de trabalhar na prática
- Há mais de 2 anos esse modo vem sendo usado para desenvolver quase sem falhas, e a verdadeira revolução começou em dezembro do ano passado
- Abriu-se a oportunidade de remover complexidade desnecessária e focar na complexidade centrada em ideias
- O custo de remover boilerplate converge para praticamente zero, e não há mais necessidade de escrever o mesmo código duas vezes
- É possível construir imediatamente pequenas ferramentas especializadas para um objetivo, ajustadas com precisão ao problema
- Sem um gerenciador de monorepo espalhafatoso, um Makefile simples atende 99% dos casos de uso
- Quando o problema ficar realmente muito complexo, pensa-se nisso então; antes disso, nunca se deve resolver antecipadamente — isso é engenharia
- É preciso resolver o problema que existe agora, não um problema que alguém disse num palco de conferência que talvez um dia apareça
Redescobrindo o Bash e as ferramentas básicas
- Os agentes são muito competentes com ferramentas básicas (basic tools) que existem há décadas
- O Bash nasceu em 1989, e hoje até o modelo mais comum conhece Bash melhor do que qualquer pessoa no mundo
- Há uma tendência de os agentes de código migrarem de configurações MCP complexas e caras para loops de agente simples baseados em Bash
- A ferramenta mais antiga é a mais preparada para o futuro (most future proof)
O custo da dependência de frameworks
- Na maioria dos casos de uso, não há necessidade de frameworks caros e falhos e de bibliotecas associadas das quais apenas 10% das funcionalidades são usadas
- Os custos invisíveis são altos — manutenção, atualizações de segurança, restrições de design — e isso limita a liberdade do desenvolvedor
- Continuar aceitando esse trade-off significa perder a maior oportunidade em décadas
- É preciso ter cautela com estruturas subordinadas à filosofia de design de grandes empresas como Google, Meta e Vercel
- Desenvolvedores devem confiar no próprio pensamento e senso estético e construir suas próprias ferramentas e produtos
> “Não envolva uma perna quebrada em seda; crie algo que seja realmente seu”
- Desenvolvedores devem confiar no próprio pensamento e senso estético e construir suas próprias ferramentas e produtos
5 comentários
Isso sim é uma metodologia de desenvolvimento para tornar a manutenção realmente difícil. É alguém que, adaptando-se à era da IA, está colocando em prática uma nova forma de garantir seu lugar para o resto da vida.
Não consigo me identificar nem um pouco com essa ideia de que, “na maioria dos casos de uso, frameworks caros e defeituosos e bibliotecas auxiliares dos quais só usamos 10% das funcionalidades”... Não era uma virtude escolher bem um ambiente do tamanho certo para o projeto? Se parece que você não vai criar muita coisa, basta usar algo leve como o express. Será que realmente é preciso criar desde o início algo para substituir o express?..
Se for para falar de algo que tem muitas funcionalidades mas do qual usamos pouca coisa, web servers como Apache ou nginx se encaixariam até melhor nisso; mas, por serem pesados, alguém passa a criar um web server do zero? Não, a gente simplesmente configura e usa.
Existem frameworks bem organizados, com muito material em que a IA já foi treinada; será que realmente faz sentido eu criar algo novo só meu? Pelo contrário, isso me parece algo que reduz a produtividade.
Acho que não há necessidade de jogar fora algo que foi feito justamente para reduzir o custo de desenhar a arquitetura e permitir focar no essencial (o serviço).
Hum... essa prática não seria da época em que o Cursor oferecia uso ilimitado? Em vez disso, a direção daqui para frente, pelo menos por um tempo, parece ser mais algo como: como economizar tokens e dar um bom suporte à IA?
Mesmo sem preços de tokens caros dá para eliminar duplicação, então por que não usar frameworks?
Opiniões do Hacker News
Parece que, em um futuro próximo, muitos desenvolvedores e empresas vão levar um grande choque por causa da ostentação com IA
Hoje dá para construir coisas com IA, mas o problema real está nas partes que você só conhece quando bate de frente com elas
No fim, quem só faz “vibe coding” vai esbarrar em limites reais, e só vai sobreviver quem entende como o sistema realmente funciona
Foi possível corrigir e fazer merge de um bug em 2 minutos, e “entender o sistema” e “não escrever código manualmente” são coisas compatíveis
A AWS está fazendo uma aposta enorme nessa direção, e, à medida que ferramentas não determinísticas ficam mais estáveis, há uma grande chance de superarem a qualidade humana
Se você delega sem entender, não dá para garantir exatidão, manutenibilidade nem escalabilidade do resultado
Mas, se eu fosse trabalhar com esse tipo de gente, eu me perguntaria por que pagar centenas de milhares de dólares para elas e ainda arcar com a assinatura do LLM
Claro, vão surgir casos de apps feitos com “vibe coding” quebrando, mas equipes que combinam isso com testes, controle de versão e documentação tendem, na verdade, a prosperar ainda mais
No fim, o importante é ter uma abordagem equilibrada
Talvez um dia apareça um “bot de de-slopping”
A razão para usar frameworks é que seus criadores já enfrentaram mais problemas e questões de escala do que eu
No começo do projeto tudo parece fácil, mas, quando ele cresce, redesenhar vira um sofrimento
Quando leio textos assim, muitas vezes parece que o próprio texto foi escrito por um LLM
A metáfora de “cortar e costurar tijolos” acaba mostrando essa contradição
Construir toda a stack por conta própria continua sendo ineficiente e tem alto custo de manutenção
A diferença agora é que ficou mais fácil criar componentes sob medida para o problema
Não preciso aprender algo novo; frameworks familiares já bastam
meu problema, o problema da plataforma e o problema de contornar o framework
Acho estranho um texto falar do sofrimento de escrever código. Programar é, na verdade, a parte fácil
Se Tolkien tivesse usado IA, provavelmente teria desperdiçado tempo refinando prompts
Principalmente nas partes difíceis, a ajuda da IA acaba atrapalhando
em textos sobre IA dizem “a IA escreve o código por mim e assim posso focar no pensamento”
Se forem as mesmas pessoas, é contraditório
Hoje em dia, se eu deixar com o Claude Code, na maioria das vezes ele resolve em poucos minutos
Mas eu confio mais no código que eu mesmo escrevi. No fim, mais importante que velocidade é a profundidade do entendimento
Se alguém usa bem novas ferramentas, como Warhol, isso também é arte
LLM é só uma ferramenta que ajuda nas etapas iniciais da criação; a genialidade continua vindo do humano
Tratar patches de segurança do Node.js como incômodo é um equívoco
Isso é um privilégio. Uma solução feita do zero não tem comunidade de segurança e tende a ter mais vulnerabilidades
É fácil encontrar desenvolvedores React, mas não existem desenvolvedores de um “framework próprio criado por IA”
Não é nada tão grandioso
Existe um meio-termo entre agentes de coding e frameworks
Eu continuo usando as mesmas ferramentas, mas deixo o agente fazer o trabalho repetitivo
E eu foco em arquitetura e edge cases
Tanto ignorar agentes quanto confiar cegamente neles são extremos
A habilidade real está em saber quando assumir o volante
O problema deste texto é colocar frameworks e “engenharia de verdade” em oposição
Plataformas como Vercel, Next.js e Firebase permitem deploy imediato e CI/CD
Pensando na época em que fazíamos tudo manualmente com Jenkins, isso é revolucionário
Engenharia de verdade não é “reinventar”, e sim entregar rapidamente ao cliente
É ineficiente a IA reimplementar frameworks existentes sem validação em produção
Sem ecossistema e padrões compartilhados, colaborar fica difícil
Desenvolvedores sem experiência usando IA do jeito errado não são novidade
Se você fizer tudo por conta própria, perde documentação, middleware e manutenção
Estão basicamente percebendo de novo que “dá para conectar APIs”
Mas esse tipo de descoberta não vem acompanhado de entendimento dos trade-offs
Nos últimos 6 meses tenho feito desenvolvimento embarcado com Cursor + Opus 4.x
LLM ajuda não só com software, mas também com projeto de circuitos, CAD e CNC
Por exemplo, concluí uma função wrapper para um display baseado em ST7789 com três prompts
Hoje quase não uso bibliotecas, exceto LVGL, TinyUSB, compressão e criptografia
As funções orientadas a propósito criadas por LLM são pequenas, rápidas e não têm abstrações desnecessárias
Acho que chegou a hora de muitas bibliotecas saírem de cena
Algo como .NET é insubstituível, mas conjuntos de funções genéricas podem perfeitamente ser trocados
incluindo até double frame buffer
A parte pesada da programação não é digitar, e sim colaborar com pessoas, testar e pensar o design
A coisa mais difícil em que trabalhei recentemente foi projetar uma estrutura de dados lock-free
Na era dos LLMs, o valor dos frameworks fica ainda maior
Por causa dos dados de treinamento, LLMs são fortes em padrões familiares como React
Também é importante que humanos possam intervir para depurar
Mesmo que a AGI chegue, não há motivo para não reaprender frameworks eficientes
Esse tipo de conversa em si já é um experimento interessante