Vibe coding e agentic engineering estão ficando mais próximos do que eu gostaria
(simonwillison.net)- vibe coding e agentic engineering eram originalmente diferenciados pelos padrões de revisão de código e de responsabilização, mas, à medida que a confiabilidade dos agentes de programação aumenta, essa fronteira está ficando borrada no trabalho real de produção
- vibe coding é uma abordagem em que quase não se olha o código e, se o resultado desejado aparece, ele é aceito; isso pode ser útil para ferramentas pessoais, mas parece irresponsável em softwares que envolvem dados e experiência de uso de outras pessoas
- agentes como Claude Code lidam repetidamente bem com endpoints de API JSON, consultas SQL, testes e documentação, o que leva a situações em que nem toda linha de código gerada é revisada, criando o risco de confiar em algo sem reputação nem responsabilidade, ao contrário de uma equipe humana
- agora já é possível criar em 30 minutos um repositório com 100 commits, um bom README e testes completos, o que torna mais difícil julgar a qualidade apenas pela aparência; o verdadeiro critério passa a ser se alguém usou aquele software de forma contínua
- ferramentas de IA não substituem a experiência de engenheiros de software; elas a amplificam, e quando a velocidade de produção de código sobe de 200 para 2.000 linhas por dia, o gargalo se desloca para design, validação, operação e uso real
A fronteira entre vibe coding e agentic engineering
- No podcast Heavybit High Leverage Ep. #9, ao falar sobre ferramentas de codificação com IA, surge a percepção de que vibe coding e agentic engineering estão ficando mais próximos entre si no trabalho real
- Antes, em Not all AI-assisted programming is vibe coding (but vibe coding rocks), havia uma distinção clara entre vibe coding e programação assistida por IA feita com responsabilidade; depois, esta última passou a ser chamada de agentic engineering
- vibe coding se caracteriza por quase não olhar o código; alguém que pode nem saber programar pede o resultado desejado, aceita se funcionar e, se não funcionar, pede de novo
- Em casos como ferramentas pessoais, em que bugs só prejudicam o próprio usuário, vibe coding pode ser útil; mas, ao criar software que envolve os dados e a experiência de outras pessoas, isso parece uma abordagem irresponsável
- agentic engineering é a forma de um engenheiro de software profissional usar ferramentas de IA no limite máximo das próprias capacidades, entendendo restrições como segurança, manutenibilidade, operação e performance
- O objetivo não é produzir resultados de qualidade inferior mais rápido, e sim construir sistemas de produção de qualidade superior mais rapidamente
- O problema é que, à medida que os agentes de programação se tornam mais confiáveis, deixa-se de revisar toda linha de código gerada mesmo em tarefas de nível de produção
A confiança que leva a pular a revisão de código
- Ao pedir ao Claude Code que crie um endpoint de API JSON e execute uma consulta SQL para retornar o resultado em JSON, surge a confiança de que ele vai fazer isso direito
- Mesmo ao pedir que adicione testes automatizados e documentação, passa a existir a expectativa de que o resultado será aceitável, e nesse processo às vezes o código em si deixa de ser revisado
- Se o código não foi revisado, fica um sentimento de culpa sobre se é realmente responsável usá-lo em produção
- Isso pode ser visto de forma parecida com como se usa software de outras equipes quando se trabalha como gerente de engenharia em uma grande organização
- Se outra equipe oferece um serviço de redimensionamento de imagens, normalmente não se lê toda linha de código escrita por ela
- Lê-se a documentação, testa-se o redimensionamento de imagens e então se lança a própria funcionalidade
- Só quando aparecem bugs ou problemas de performance é que se pode olhar o repositório Git
- Na maior parte do tempo, esse serviço é tratado como uma caixa-preta parcial
- Os agentes estão passando a ser tratados da mesma forma, mas, ao contrário de uma equipe humana, Claude Code não tem reputação profissional nem responsabilidade(accountability)
- Equipes humanas podem construir reputação ao entregar bom software no passado e sofrem a pressão de que resultados ruins afetam sua reputação profissional
- Claude Code não pode ter esse tipo de reputação, mas vem acumulando confiança ao acertar repetidamente tarefas simples de um jeito alinhado ao estilo que prefere esse tipo de trabalho
- Há aqui um elemento de normalização do desvio
- Cada vez que o modelo escreve código correto sem supervisão próxima, a confiança aumenta
- Junto com isso, cresce também o risco de excesso de confiança no momento errado e do prejuízo que isso pode causar
Fica mais difícil avaliar software
- Antes, se um repositório no GitHub tinha 100 commits, um bom README e testes automatizados, era fácil concluir que o projeto tinha recebido bastante cuidado e atenção
- Agora é possível criar em 30 minutos um repositório Git com 100 commits, um README bonito e testes cobrindo todas as linhas de código
- Um repositório assim pode parecer, por fora, idêntico a um projeto construído com muito cuidado e atenção ao longo do tempo
- Talvez ele seja realmente tão bom quanto, mas é difícil saber só pela aparência, e o mesmo problema também vale para os próprios projetos
- Um critério considerado mais importante do que a qualidade dos testes e da documentação é se alguém realmente usou aquele software
- Mesmo que o resultado tenha sido feito com vibe coding, se a pessoa que o criou o usou todos os dias nas últimas duas semanas, isso é muito mais valioso do que algo gerado e quase nunca executado
O gargalo sai da escrita de código e vai para outras etapas
- Quando se passa de uma situação em que se produziam 200 linhas de código por dia para outra em que se podem produzir 2.000, outras partes do ciclo de vida do desenvolvimento de software começam a quebrar
- O ciclo de vida tradicional do desenvolvimento de software foi projetado assumindo uma velocidade de algumas centenas de linhas de código por dia
- A mudança de gargalo afeta não só as etapas posteriores, mas também as anteriores
- Na apresentação de Jenny Wen, aparece a visão de que o processo tradicional de design parte da premissa de que “é preciso acertar o design”
- Porque, se algo errado for construído por 3 meses depois de ser passado para a engenharia, isso vira um desastre
- Como o design leva a trabalho caro de implementação, cria-se um processo de design extenso
- Mas, se construir algo não leva 3 meses, o custo de errar cai muito, então o processo de design pode assumir bem mais risco
Por que isso ainda não significa o fim da carreira de engenheiro de software
- Conversar com agentes parece, para a maioria das pessoas, uma espécie de “moon language” difícil de entender
- Uma das razões para não ver a carreira de engenheiro de software como acabada só porque computadores agora conseguem escrever código sozinhos é que essas ferramentas amplificam a experiência existente
- Quem sabe o que está fazendo consegue se mover muito mais rápido com ferramentas de IA
- Quanto mais se usam ferramentas de IA, mais se confirma repetidamente como fazer software em si é algo muito difícil
- Mesmo com todas as ferramentas de IA disponíveis, o que se quer alcançar continua sendo difícil
- Matthew Yglesias escreveu em um tweet: “Depois de cinco meses, percebi que não quero fazer vibecode. Quero que empresas de software geridas profissionalmente usem assistência de programação por IA para criar produtos de software mais numerosos, melhores e mais baratos e me vendam isso”, e há concordância com essa visão
- Isso se resume à analogia de que, mesmo vendo vídeos suficientes no YouTube sobre encanamento para talvez consertar a tubulação da própria casa, ainda assim se prefere contratar um encanador
O risco de SaaS versus desenvolvimento interno
- Em relação à ameaça de empresas deixarem de usar SaaS para criar soluções próprias, continua valendo o mesmo critério de preferir software validado pelo uso real
- Em projetos pessoais, há preferência por ferramentas que o próprio criador tenha usado por pelo menos algumas semanas
- Na versão enterprise, o critério vira não querer adotar um CRM a menos que pelo menos duas outras grandes empresas o tenham usado com sucesso por seis meses
- Antes de assumir o risco, quer-se uma solução comprovadamente funcional
5 comentários
Quando você simplesmente coloca em produção o código escrito por um agente, muitas vezes ele passa a exigir um nível absurdo de desempenho do sistema.
Mesmo sendo um código sem nada demais, CPU/memória estouram e, quando você manda analisar, ele conclui rapidinho que é preciso fazer upgrade da instância.
Se você passar um bom tempo pressionando e questionando por falta de dinheiro, dá para contornar bastante coisa,
e aí você acaba vendo que funciona bem até só com o sistema atual.
Seria ótimo se ele já fizesse isso desde o começo, mas parece que, mesmo com modelos melhores, eles não conseguem otimizar bem por conta própria.
Fala-se muito em HITL (human-in-the-loop), mas acho que o importante é se, dentro desse loop, eu realmente consigo fazer questionamentos valiosos.
Acho que vou ter que sempre deixar um prompt dizendo que estou sem dinheiro no
AGENTS.mdComentários no Lobste.rs
No fim das contas, a conclusão de que não há uma grande distinção não é exatamente surpreendente, mas é interessante que o @simonw também tenha chegado a ela
Desde o começo, eu achei que o incentivo sempre puxaria nessa direção. Se existe uma máquina produzindo em massa e o objetivo é fazer um engenheiro experiente revisar o resultado, isso acaba tanto jogando um trabalho desgastante para engenheiros sêniores quanto transformando-os em gargalo
Dito isso, foi o próprio Simon quem levantou essa distinção originalmente, então vale notar que agora nem o Simon parece mais enxergá-la assim
Além disso, é meio estranho escrever aqui algo que pode soar como crítica, já que o @simonw quase certamente vai ler. Na prática, considero o @simonw o melhor autor pró-IA, então leio tudo o que ele publica com muito interesse. Se eu fosse fazer uma crítica, seria que, por ele ser tão ponderado, os textos dele acabam dando bastante legitimidade para vendedores muito menos ponderados do que ele
Entendo o que o autor quer dizer, mas eu veria de um jeito um pouco diferente: vibe coding e engenharia agêntica são dois pontos em um mesmo espectro, e mais gente, no contexto real de implantação, está se movendo para algo mais próximo de vibe coding do que de engenharia agêntica
Quando um eufemismo recém-criado se apoia em neologismos e termos mal definidos, ele acaba sendo usado de forma ambígua. Isso era inesperado? Eu sempre achei que esse fosse justamente o objetivo da expressão
Se você quer que um neologismo seja usado com precisão, provavelmente precisa construí-lo sobre termos já bem compreendidos. Claro, nem isso garante sucesso
Pelo que de fato está sendo promovido como "agentic engineering", eu chamaria de desenvolvimento guiado por bots. "Bot" é um termo relativamente bem compreendido, e há precedentes como "desenvolvimento orientado a testes". Não é uma proposta séria, só um exemplo do tipo de formulação que eu usaria se fosse cunhar uma expressão
Há, porém, a exceção de que, em redes sociais e no discurso político, "bot" acabou virando um xingamento genérico para "alguém na internet que discorda de mim"
Neste caso, o que me agrada na expressão "agentic engineering" é que fica muito difícil alguém digitar um prompt, receber um app sem entender nada de como ele funciona e ainda assim afirmar que fez "agentic engineering". Especialmente quando "vibe coding" já está bem estabelecido logo ao lado
Se você pegar a fala "quero usar apenas um projeto paralelo que já usei por algumas semanas" e converter para a versão corporativa, ela vira algo como "só quero usar um CRM depois que pelo menos duas grandes empresas já o tiverem usado com sucesso por seis meses"
Acho que a direção geral está certa, mas o que acontece na prática é um pouco diferente. Sistemas grandes desse tipo costumam ser extremamente customizados. Salesforce, SAP, Workday normalmente são muito adaptados e caros de manter. Além disso, a própria plataforma pode ser rígida de um jeito bem inconveniente. Ninguém gosta de Workday, mas ele está em toda parte no mundo corporativo
Com certeza existe espaço para abordagens diferentes. Só não sei se a resposta é "algo construído do zero com vibe coding". Talvez seja algo por cima dessas plataformas, mas imagino cada vez mais algo mais próximo de montar produtos/serviços de "nível corporativo" com vibe coding
Outro efeito é que abordagens agênticas acabam esvaziando por dentro esses sistemas. Eles conseguiram resistir por muito tempo a virar apenas um "banco de dados", mas abordagens agênticas acabam empurrando nessa direção
Então não acho que veremos algo como "fizemos vibe coding do Salesforce", mas essas empresas estão lutando em várias frentes
Acho que isso faz bastante sentido para grandes SaaS que já eram fortemente customizados
Não tenho total certeza de como interpretar este texto. Em várias frases, eu teria vontade de reformular o ponto central como: a diferença entre vibe coding e engenharia agêntica não é se você leu o código ou não. Ou seja, talvez importe mais quais práticas estão sendo usadas do que se o código foi lido
Claro, muita gente sonha com um mundo em que realmente não haja diferença: como usuário não programador, você diz o que quer, um agente constrói algo com o nível apropriado de robustez, e o usuário nem precisa especificar práticas para garantir essa robustez
Mas eu não acho que já chegamos lá, e também não acho que este texto esteja dizendo que já chegamos
Ainda assim, não sei se essa interpretação é justa. @simonw, o que você acha?
Pessoalmente, eu ainda não chego nem perto de colocar algo em produção sem ler o código. No meu contexto, pela minha experiência, esse processo ainda não é confiável o suficiente. Mas estou tentando entender o ponto de vista deste texto
Eu ainda acredito que existe uma diferença enorme entre um engenheiro de software profissional usando IA para ampliar e acelerar seu trabalho e um não programador usando vibe coding para construir um sistema que resolve seu problema sem entender profundamente como ele funciona
O que mudou é que percebi que comecei a implantar código em que confio e sob o qual coloco meu nome, mas que eu não revisei linha por linha. Isso parece mais próximo da definição original de vibe coding do que eu gostaria
Ainda estou tentando entender o que isso significa e como falar sobre isso
Comentários do Hacker News
Vibe coding e LLMs não criaram organizações ou engenheiros sem disciplina; apenas expuseram e aceleraram problemas que já existiam
Muitos engenheiros têm padrões e práticas de escrita de código frouxos ou inexistentes, e muitas equipes também têm critérios fracos para colocar código em produção
Isso não é um fenômeno novo; só significa que ficou muito mais fácil para indivíduos e equipes que nunca seguiram padrões ao longo do ciclo de vida de desenvolvimento de software produzir muito mais código e concretizar ideias
Nunca vi alguém virar um bom engenheiro só por escrever código mais rápido
Os melhores engenheiros que conheço foram pessoas que, com base em experiência e julgamento cuidadoso, compartilharam insights importantes com a equipe e ajudaram a direcionar melhor o sistema
“Claude, faz um sistema aí. Mas faz bem feito. Valeu!”
Antes, quando a base de código começava a resistir ao desenvolvimento de funcionalidades, corrigia-se o gargalo imediato e empurrava-se o resto até o próximo ponto de resistência
Era um estilo de refatorar até certo ponto enquanto se entregavam funcionalidades, mas os modelos de fronteira empurram ainda mais para frente o momento em que “vira problema”
Como conseguem lidar, até certo ponto, com o monte de código dado, isso acaba aparecendo como LLMs criando mais regressões ou deixando passar mais requisitos, mas dá menos a sensação de que o trabalho ficou mais difícil para a pessoa
Até que, em algum momento, quebra coisa demais e precisa consertar, mas a base inteira virou uma camada fractal de decisões que eu não tomei, difícil de desembaraçar
Como você não edita o código diretamente, também desaparece aquela reação visceral de “adicionar isso desse jeito vai gerar tensão”, então fica mais difícil encontrar a oportunidade de uma boa refatoração
Sempre dá para refatorar código depois, e dá para forçar o agente a escrever partes e arquivos pequenos e modularizados
Boa engenharia continua sendo boa engenharia, tenha sido escrita por agente ou por humano
Por enquanto, pelo menos uma pessoa ainda precisa entender e conduzir a arquitetura, e os agentes podem ajudar muito bem com reconhecimento e sugestões
A menos que eu tenha perdido algum avanço nas últimas semanas, parece menos que a IA ficou mais confiável e mais que os erros ficaram mais sutis
Se o código nem compila, é fácil de achar, e se compila mas não funciona, também é relativamente fácil de perceber
Mas quando compila e funciona, só que erra em alguns casos de borda, ou tem vulnerabilidades de segurança, ou traz dívida técnica e decisões arquiteturais duvidosas, fica muito mais difícil de detectar, e a carga de revisão não diminui nada
Na verdade, código plausível pesa mais mentalmente na revisão do que código obviamente ruim
Basta fazê-lo escrever vários testes primeiro, verificar se o código atende a eles e orientá-lo a organizar o código corretamente
Mas agora a pressão vinda de cima está tão forte que o clima é de aplicar isso amplamente em qualquer lugar, e se você se opõe, é desanimador demais e ainda limita sua carreira, o que vai desgastando a cabeça
Quando você aponta um problema óbvio, surgem muitos contornos; logo aparecem outros problemas nesses contornos, e isso gera soluções novas sem fim
Em algum momento, tudo isso começa a parecer trabalho em função da própria máquina
Em muitas empresas, parece que o objetivo real se perdeu e só sobrou o próprio LLM
Não sei se as pessoas que estão apostando o futuro da empresa nessa visão têm garantida uma saída suave para escapar das consequências, ou se a racionalidade foi simplesmente jogada fora por completo
Dá para mitigar os problemas com princípios sólidos de engenharia, mas ainda questiono qual eficiência real isso gera em termos de carga cognitiva, tempo de desenvolvedor, dinheiro e recursos finitos
Na frase “o que quebra quando você passa de 200 linhas por dia para 2.000”, usar linhas de código como métrica de produção de engenharia é algo constrangedor
Revisar 200 linhas e revisar 2.000 linhas são cargas de trabalho completamente diferentes
Quando refiz o mesmo programa com a minha própria cabeça e usei o ChatGPT só como busca e autocompletar, cheguei ao mesmo resultado com 1.500 linhas
Honestamente, a diferença de esforço também não foi tão grande, embora a abordagem manual talvez tenha tido a vantagem de eu já ter pensado no que queria construir graças à primeira versão feita com vibe coding
Faz sentido usar linhas de código como entrada para revisão de software
Afinal, é preciso literalmente ler cada linha
Só são péssimas como medida única de produtividade do desenvolvedor, e é aí que começam os problemas
Ainda assim, são úteis por serem talvez a única métrica imediatamente intuitiva e comparável entre empresas, equipes, linguagens e contextos de aplicação
Mesmo a mesma equipe, trabalhando no mesmo produto, pode resolver uma mudança de 1.000 linhas muito rápido, enquanto uma correção de bug de 1 linha pode exigir dias de depuração
Por isso é difícil comparar PR, feature ou story points fora de contexto; se existisse uma métrica padrão de produtividade de desenvolvedor realmente viável, todo mundo já a usaria, mas isso parece intrinsecamente difícil
Nessas comparações, ajuda assumir que o contexto é o mesmo
Por exemplo, se uma equipe que constrói um produto específico numa empresa específica, com uma stack específica e um processo de qualidade específico, ontem produzia N1 linhas e hoje, com IA, produz N2 linhas, então ao longo do tempo a diferença entre N1 e N2 aproxima o impacto real
Até estudos mais rigorosos sobre produtividade com desenvolvimento assistido por IA geralmente medem isso em estilo de teste A/B, comparando PRs antes e depois do uso de IA no mesmo grupo
Para mim, a diferença está na qualidade e no rigor do pipeline
Vibe coding é tentar uma vez ou algumas vezes, conferir superficialmente o resultado e usar até quebrar
Serve para provas de conceito leves ou apps de baixo risco para uso pessoal, familiar ou de equipes pequenas
Engenharia agentic se preocupa com um conjunto mais amplo de questões, como correção funcional, desempenho, infraestrutura, resiliência/disponibilidade, escalabilidade e manutenibilidade
Há um pipeline em múltiplas etapas gerenciando o fluxo de trabalho, com possíveis fases como intake do projeto, triagem, especificação, decomposição em épicos, decomposição em stories, codificação, documentação e deploy
Cada etapa mistura gates determinísticos de qualidade, como passar em testes ou atingir metas de performance, com revisões adversariais sobre valor de negócio, completude da especificação, elegância do código e rigor e simplicidade da linguagem ubíqua
Isso também é um slider
Às vezes você não quer fazer entrevista, gastar tokens, passar por três revisões adversariais, estimativa de valor e especificação detalhada só para lançar uma funcionalidade; quer só jogar o ticket no sistema
Eu uso Opus, GPT-5.5 e modelos menores todos os dias, mas não entrego o trabalho inteiro a eles
Mesmo colocando bastante esforço em definir e refinar especificações, eles ainda fazem muita bobagem que eu não aprovaria numa revisão humana de PR
Se eu confiasse no resultado, ou criasse um grande pipeline agentic para ganhar uma falsa sensação de estabilidade, seria fácil deixar isso simplesmente escorrer para dentro da base de código
Talvez daqui a 10 anos melhore, mas hoje tanto vibe coding quanto pipelines de engenharia agentic parecem variações do mesmo tema de delegar tudo ao LLM
Hoje de manhã mesmo, achei que poderia deixar o Opus on Max fazer alterações num arquivo único, mas quase todo turno tinha erros ou omissões que precisei corrigir
O código sugerido provavelmente funcionaria na maior parte, mas estava complexo demais e até regrediu partes que eu já tinha simplificado manualmente
Se isso se multiplicar por milhares de commits de agentes, a base de código piora rapidamente
Equipes de desenvolvimento se complicam quando tentam construir sem o processo correto de design, testes e revisão
Isso já era verdade antes da codificação com agentes, mas agora é ainda mais, e as equipes que melhor entenderem como usar agentes dentro desse processo serão as mais bem-sucedidas
Você não sente que agentes de código chegam muito perto da solução já na primeira tentativa, mas exigem um trabalho enorme para acertar os últimos 10% ou 5%?
Se você mudar a forma de abordar o problema, o agente consegue fechar essa lacuna
Dez anos atrás, eu parava de programar a cada 10 ou 15 minutos para refatorar, testar e analisar se estava tudo certo
Porque um bug pode contaminar todo o código escrito depois
Agentes de código não conseguem fazer isso e seguem em frente carregando bugs ou arquitetura errada
O instinto é querer interromper o agente no meio do caminho, mas isso é impossível por vários motivos
Em vez disso, como o custo é muito baixo, você precisa encontrar o ponto em que o agente errou pela primeira vez, ajustar o prompt e, em vez de corrigir o código, apagar tudo e rodar de novo do zero
É só repetir isso até o prompt gerar código perfeito
Vão dizer que isso ainda exige muito trabalho humano, mas esse é exatamente o ponto
Humanos continuam sendo necessários, e usar a ferramenta assim faz a velocidade de escrita de código aumentar 10x
Você consegue fazer “algo que funciona” relativamente rápido, mas leva tempo para avaliar alternativas, refinar, testar e ganhar confiança
A ideia central está certa, mas ninguém sabe onde está o limite
O próximo ano mais ou menos vai ser um período em que todo mundo estará tentando descobrir isso, e por isso se ouve tanto que “precisamos reinventar o GitHub”
Em muitos casos, investir para mecanizar também essa parte final simplesmente não faz sentido econômico
Acho que os provedores de LLM seguiram a abordagem errada desde o começo
Em vez de focar em substituir trabalho, deveriam ter focado em complementar o trabalho, e parece que aprenderam isso do jeito caro
Talvez tivesse sido melhor recomeçar do zero, mas no início eu ainda não sabia como deveria ser a arquitetura desejada
Só porque o LLM sofre para encaixar funcionalidades na arquitetura existente não significa que se possa apagar uma base de código inteira em produção e começar de novo
É um ótimo texto escrito por alguém inteligente, humilde e disposto a continuar aprendendo
Gostei da frase: “Há muitos motivos pelos quais não tenho medo de que a carreira de engenheiro de software tenha acabado só porque computadores agora conseguem escrever seu próprio código. Em parte, é porque essas coisas são amplificadores da experiência prévia. Se você sabe o que está fazendo, consegue correr muito mais rápido”
E também desta: “Usar essas ferramentas continua me lembrando do quão difícil é o que fazemos. Construir software é brutalmente difícil. Mesmo com todas as ferramentas de IA do mundo, o que estamos tentando realizar aqui continua sendo realmente difícil”
Está certo ao apontar que o trabalho a montante também muda junto
As ferramentas de design estão evoluindo especialmente rápido, então já não parece valer a pena arcar com o custo de tradução de permanecer no Figma
A parte assustadora é que camadas de complexidade de IA vão se acumulando na base de código, e os humanos deixam de entender o código, de modo que passa a custar caro para os modelos mais recentes decifrarem e alterarem aquilo
Em pouco tempo, pode desaparecer o reuso de código, e vamos acabar queimando dinheiro reinventando a roda sem parar
Quando eu fazia apps Android no começo, era obrigatório usar IDE, e dava uma sensação de esgotamento da alma ter de escrever uma quantidade absurda de boilerplate só para, ao clicar num botão, aparecer um alerta “Hello World”
Repitam comigo: a maior parte do software passa a maior parte da vida na fase de manutenção
Portanto, a maior parte do dinheiro que o software gera também vem da fase de manutenção
A indústria, depois de quase 100 anos, ainda não entendeu isso
Alan Kay estava 100% certo ao dizer que a revolução dos computadores ainda não aconteceu
Apesar de todos os avanços atuais, as ferramentas ainda são em grande parte nível idade da pedra
Minha grande esperança é que a IA nos acelere até um ponto em que destrua completamente o paradigma atual de forma irreversível, para que finalmente possamos fazer algo novo, diferente e melhor
Então, por enquanto, vamos colocar um jetpack de IA no ciclo de vida de desenvolvimento de software e ver no que dá
Vamos nos mover rápido e quebrar as coisas de verdade
É uma observação oportuna e parece verdadeira para mim também
Eu precisava montar algo relativamente simples de download em lote → conversão → endpoint de API, e usei um prompt bem detalhado, mas deixei em aberto muitos detalhes de implementação, como a fonte dos dados
O Opus 4.7 fez algo cerca de 90% igual ao que eu teria feito, e ainda colocou muito mais métodos utilitários e validação por etapa
Ficou muito bom e me deu espaço mental para pensar em problemas mais difíceis
Sou principalmente desenvolvedor Python, mas uso com frequência outras linguagens de backend como Rust e Go, com as quais tenho familiaridade, embora não no mesmo nível
Com cerca de 13 anos de experiência fortemente concentrada numa linguagem e estudo formal de outras, fica muito mais fácil direcionar o LLM
A carga de aprender sintaxe, componentes básicos, gerenciador de pacotes, testes etc. não é grande comparada ao jeito antigo de programar
Há pouco tempo, ajudei um colega não desenvolvedor que estava automatizando relatórios com Claude cowork/code
Esse colega entendia bem a parte de business intelligence, mas tinha dificuldade com o vocabulário básico para fazer vibe coding de um wrapper em pyautogui que abrisse uma sessão RDP e preenchesse valores numa abstração em MS Access sobre o banco de dados de um fornecedor
Acho que desenvolvedores como profissão ainda estarão bem pelos próximos 5 a 10 anos
Usando o Codex 5.5, fico impressionado todos os dias ao perceber que a era da programação feita por humanos realmente está chegando ao fim. Ultimamente, os dias em que não escrevo uma única linha de código estão ficando cada vez mais frequentes. O papel e as exigências da profissão de desenvolvedor vão mudar de forma ampla e muito rápida.