- A IA cria em poucos minutos um protótipo com UI e banco de dados, mas não reduz a distância entre a primeira versão funcional e um produto pronto para produção
- Em um produto real, ainda restam problemas que exigem julgamento de engenharia mais do que escrita de sintaxe, como escalabilidade, tratamento de erros, observabilidade, segurança, autenticação e estrutura de dados
- O valor da ciência da computação está menos em produzir código e mais em formar modelos mentais para entender como sistemas funcionam e por que falham; é isso que permite identificar consultas ineficientes ou condições de corrida
- A demanda por transformar requisitos em código de forma mecânica tende a cair, mas engenheiros experientes podem delegar tarefas repetitivas à IA e trabalhar muito mais rápido ao focar nos problemas que exigem especialização
- Se você usar a IA como substituta da compreensão, será difícil corrigir, expandir ou repassar sistemas quebrados; por isso, é preciso aprender primeiro os fundamentos e depois usar as ferramentas de IA
O abismo entre protótipo e produto
- Ao descrever uma ideia em linguagem natural, é possível obter em poucos minutos um protótipo funcional com UI, banco de dados e a funcionalidade desejada
- Mas um protótipo que roda no notebook pode revelar vários problemas em um ambiente real
- Não suporta carga e não tem tratamento de erros
- Tokens de API podem vazar
- Um modelo de dados feito para demo pode desmoronar no momento em que se adiciona o segundo usuário
- A autenticação depende de premissas não validadas, e nem está claro se há segurança de fato
- Na etapa de implantação, aparece o grande gap de produção entre “funciona” e “está pronto”
O trabalho difícil sempre começou depois de escrever o código
- Engenheiros de software já conseguiam colocar algo para rodar rapidamente antes, e a parte que realmente consumia tempo vinha depois
- Projetar sistemas que continuem funcionando em escala
- Tratar exceções quando usuários entram por caminhos inesperados
- Construir observabilidade para detectar falhas
- Tomar decisões de arquitetura de dados que reduzam arrependimentos daqui a 3 anos
- A IA reduziu drasticamente o tempo até a primeira versão funcional, mas não encurtou a distância entre essa versão e um sistema pronto para produção
- O ciclo rápido de pedido, resposta e verificação do resultado dá a impressão de que o restante do desenvolvimento também foi comprimido, mas os problemas difíceis de software nunca foram, em primeiro lugar, escrever sintaxe
- É a capacidade de julgamento sobre o que construir, como estruturar, o que adiar e quando dizer não que separa um protótipo de um sistema de produção
Por que ciência da computação ainda é necessária
- Com o acesso fácil a código gerado por IA, mais iniciantes passaram a questionar se ainda faz sentido estudar por anos algoritmos, estruturas de dados, sistemas operacionais e teoria
- O valor da formação em ciência da computação não está só na habilidade de escrever código, mas em formar modelos mentais para entender como sistemas funcionam, falham e por que produzem certos resultados
- É essa base que permite identificar falhas potenciais no código gerado por IA
- Uma consulta que provoca varredura completa de tabela em uma tabela com 50 milhões de linhas
- Uma estratégia de cache que cria condições de corrida sob carga concorrente
- Uma arquitetura que resolve a necessidade atual, mas torna o próximo problema muito mais difícil
- Sem conhecimento fundamental, você passa a depender totalmente do julgamento do modelo
- O modelo gera ativamente código que acredita corresponder à sua intenção com base em correspondência de padrões, não em julgamento
- O código gerado pode parecer correto e alinhado às convenções, mas ainda falhar em produção
- Se você não tiver o conhecimento para reconhecer o problema, o diagnóstico pode levar dias
- Agora que a distância entre compreensão e resultado diminuiu, este é um ótimo momento para aprender ciência da computação; um estudante que realmente entende sistemas distribuídos consegue construí-los em muito menos tempo do que há 10 anos
Trabalho automatizado e produtividade ampliada
- A demanda por trabalho mecânico de programação, que transforma requisitos em implementação linha por linha, está de fato diminuindo, e essa área está sendo automatizada
- Enquanto a parte inferior da distribuição de produtividade é comprimida, o limite superior se expande
- Um engenheiro experiente usando ferramentas modernas de IA pode trabalhar em uma velocidade que seria difícil de imaginar 5 anos atrás
- Não porque os problemas difíceis desapareceram, mas porque a maior parte do trabalho mecânico que consumia tempo e atenção agora é resolvida
- O tempo liberado pode então ser usado nas tarefas que realmente exigem especialização
- O engenheiro que vai ficar para trás não é quem não sabe usar IA, mas quem usa a IA como substituta da compreensão
- Constrói sistemas por vibe coding sem conseguir raciocinar sobre eles
- Não consegue corrigir falhas nem expandir um sistema que cresceu
- Não consegue explicar a quem vai fazer a manutenção o que ele próprio construiu
Trabalhar em um nível mais alto de abstração
- A mudança necessária não é apenas adotar novas ferramentas, mas trabalhar em um nível mais alto de abstração sem perder as raízes nos fundamentos
- Engenheiros que usam a IA como amplificador, e não como substituta de conhecimento profundo, podem avançar mais rápido que seus pares
- Entendem o que estão pedindo ao modelo para gerar
- Analisam o código gerado de forma crítica, como se estivessem revisando o pull request de um engenheiro júnior
- Conversam em termos de arquitetura, e não apenas descrevendo funcionalidades
- Sabem julgar quando precisam discordar das sugestões do modelo
- Isso não substitui habilidades antigas por uma nova competência, mas aplica habilidades já existentes a um novo ambiente para obter uma alavancagem muito maior
- Mesmo depois do protótipo, ainda é necessário julgamento real de engenharia, e é essa capacidade que separa quem lança software confiável de quem lança apenas demos
- A ordem do aprendizado deve ser fundamentos primeiro, ferramentas de IA depois
1 comentários
Comentários no Hacker News
Estou pensando em descartar o código que fiz com LLM ao longo de vários meses em um side project. Mesmo escrevendo especificações de design com cuidado e trabalhando sobre uma base de código existente, as mudanças individuais pareciam lógicas, mas no conjunto viraram um bloco complexo em que várias partes ficaram sutilmente desalinhadas
Relatórios e artigos também ficam assim: cada seção parece plausível, mas o documento inteiro soa estranho. Parece que humanos, embora mais lentos nas tarefas detalhadas, ainda fazem um raciocínio de nível mais alto que os LLMs não conseguem. Quando você aponta um defeito, eles dizem “você está totalmente certo”, mas não conseguem encontrá-lo sozinhos ao revisar o próprio trabalho
Talvez seja perfeitamente possível fazer um app CRUD simples com framework JS comum, Tailwind e ORM, mas já era possível comprar templates SaaS antes, e boilerplate comercial bem feito à mão provavelmente é melhor do que o resultado de vibe coding
Também vejo com frequência, em PRs de outras pessoas, implementações que resolvem superficialmente o problema do prompt, mas são difíceis de manter no longo prazo. Por isso, eu mesmo decido o procedimento de implementação e o design, e trabalho passo a passo com pequenos modelos open source ou com Claude 4.5 e 4.6. Isso acelera exploração de APIs e escrita de boilerplate, ficando várias vezes mais rápido do que fazer tudo manualmente, sem degradar meu conhecimento nem destruir a base de código
A IA é uma nova camada adicionada à stack tecnológica, assim como linguagens de alto nível foram colocadas sobre código de máquina, então é preciso desapegar
Isso não quer dizer que IA seja inútil, mas que é preciso pensar mais profundamente nos requisitos e na validação final, e confiar menos que o processo por si só garantirá um bom resultado
Não gosto das cores nem da lógica de negócio verbosa, desnecessária e espalhafatosa, mas o importante agora é se o casal realmente acha útil no uso real, e o resultado tem sido positivo. Depois vou redesenhar a UI do meu jeito, definir os requisitos de backend e então reescrever tudo do zero para facilitar manutenção e expansão
A linha Claude é excelente para prototipagem e descoberta de requisitos, e depois facilita o processo de refazer tudo direito
Um critério simples de verificação é se você realmente viu, nos últimos 12, 24 e 36 meses, ótimos produtos novos ou grandes melhorias em produtos existentes. O único produto novo excelente que usei foi meu LLM preferido, e esses laboratórios, na verdade, continuam contratando mais gente
Se não houver melhora daqui a 12 meses, acho que vão repetir a afirmação de que “só em fevereiro de 2027 os LLMs ficaram bons o bastante, então ainda não dá para avaliar”
https://news.ycombinator.com/item?id=49120097
As atualizações de segurança mais recentes da Apple e o boletim de segurança de junho do Android também corrigem um número enorme de vulnerabilidades. Muitas surgiram em linguagens inseguras como C/C++, mas como LLMs são fortes em tarefas de transformação bem definidas e com pouca margem para desvio, também são úteis para migrar para linguagens seguras como Rust
Também na área médica o número de produtos disparou; a qualidade varia, mas dizer que não houve resultado nenhum é objetivamente falso
Se o produto funciona, recomendo pedir: “revise se a base de código está pronta para produção e se atende ao padrão para ser vendida por 1 milhão de dólares”. Aí a IA revela que está longe do nível que afirmava antes, e isso vira o “prompt de um milhão de dólares” que mostra o quanto você estava sendo enganado
https://news.ycombinator.com/item?id=18442941
Usei LLM de duas formas. Primeiro, fiz vibe coding com o Opus 4.6 e um backend em Node para um plugin que envia notificações em canais do Slack conforme a ordem de turno das pessoas, e um timer de fala por participante no Google Meet. Como era uma ferramenta interna, mesmo sem entender bem a implementação, ela roda sem problemas no GCP, e reduziu o custo da ferramenta de Slack de 20 dólares por pessoa por mês para um custo total de infraestrutura de US$ 0,07 por mês
Não foi feito de uma vez só; passei por planejamento detalhado, execução em etapas e adição de testes. Segundo, em produtos de longo prazo, a equipe projeta e revisa a arquitetura, cria tickets detalhados no JIRA e depois os repassa ao Opus. O modelo faz o plano de implementação e só pode programar depois da aprovação dos engenheiros
Para MVPs rápidos ou provas de conceito, o primeiro método é bom, mas em produtos de longo prazo é preciso abandonar o MVP e planejar desde o início a escalabilidade e uma arquitetura limpa, usando o LLM como trabalhador de codificação. O LLM ainda é fraco para julgar arquiteturas que humanos consigam manter por muito tempo e código limpo
O critério de julgamento é se é prazeroso consumir algo gerado por IA. Texto, vídeo, voz, cardápio de restaurante, fotos de roupas, documentos, controle de tráfego aéreo, publicidade — nada disso parece prazeroso, e vejo valor em LLMs como mecanismos de busca melhores ou ferramentas de perguntas e respostas
Se a IA acabar atendendo a esse padrão, os produtos gerados passarão a dominar os artesanais, e produtos e serviços feitos diretamente por pessoas provavelmente só poderão ser comprados por preços muito mais altos, como artigos artesanais hoje
Vai haver muito trabalho em organizar os resultados de vibe coding de outras empresas e transformá-los em sistemas realistas. O valor de cada projeto individual pode cair, mas a quantidade vai aumentar, e é bem provável que eles não funcionem direito sem ajuda
Foi dito que empresas sem engenheiros de software usam Claude Code para tarefas fora do negócio principal, mas ainda assim querem que os funcionários façam o trabalho para o qual foram contratados, em vez de ficarem mexendo no código
Como a produção sob medida fica mais fácil, produtos padronizados e sem diferenciação ficam mais difíceis de vender, mas ainda será preciso muito trabalho para entregar resultados realmente personalizados. Isso favorece em dobro quem tem experiência construindo diretamente e também conhecimento do domínio de trabalho em questão
Como as pessoas em geral não sabem do que precisam, a essência da consultoria — descobrir a demanda e entregá-la — continua a mesma, e como o software ficou mais barato, será possível atender mais clientes
A lógica básica do texto é falha. Se ainda há trabalho a fazer depois de criar um protótipo, então basta continuar fazendo esse trabalho. Parece equiparar o uso de IA a gerar tudo de uma vez com um prompt de quatro linhas, e soa menos como um insight fundamental e mais como uma autojustificação acrítica
Mesmo sem formação em engenharia, isso me pareceu intuitivamente correto, e já passei por isso várias vezes ao fazer jogos de cartas. No começo ia bem, mas por ter importado uma biblioteca padrão de baralho de 52 cartas, não consegui adicionar cartas especiais de evento, e passei a precisar de um modelo de dados flexível baseado em objetos de carta
Se isso for dito desde o início, talvez dê para resolver, mas se você trata software como algo descartável e não pensa a implementação em profundidade como um engenheiro experiente, não vai imaginar esse tipo de requisito. O problema de textos e códigos gerados por IA é que eles tiram o raciocínio que estava embutido no processo de criação
Ainda assim, nem todo software precisa ter escalabilidade, velocidade e manutenibilidade. Infraestruturas e apps usados por milhões precisam disso, mas um app de planejamento de refeições para a família não precisa suportar configurações de alergia para dezenas de milhares de funcionários do Google
A IA permite transformar software em uma ferramenta como comida caseira. Comida caseira não precisa ser uma culinária perfeita; basta alimentar a família e ser um presente de esforço para alguém
Se um produto pudesse ser feito com um único pedido, empresas de terceirização já teriam dominado as empresas de produto há muito tempo. Grande parte do desenvolvimento de produto acontece no trabalho iterativo após o protótipo/MVP inicial
Não é só técnica; é preciso mergulhar no problema por muito tempo, entender a causa raiz da dor e resolvê-la tanto na experiência do usuário quanto na tecnologia. Já era possível “promptear” empresas terceirizadas para fazer produtos antes, mas é por isso que se pagava a empresas de produto que acumularam especialização conversando com clientes por anos
Um título melhor para resumir a discussão seria The Prototype Isn't the Product. Com IA, dá para fazer com velocidade surpreendente protótipos descartáveis e apps pessoais para os quais “basicamente funciona” já basta, mas engenharia de software em que qualidade e manutenção importam continua difícil e lenta
Há muitas demonstrações chamativas de vibe coding, mas pouca discussão sobre o quanto a IA foi útil em grandes bases de código legadas ou em trabalho profissional cotidiano e sem glamour
Ninguém vai ligar para você às 6 da manhã de domingo porque um protótipo de jogo 3D feito com vibe coding travou, mas se aparecer um bug em um sistema que opera 24 horas por dia que você acabou de atualizar, com certeza vão ligar