1 pontos por GN⁺ 2 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • 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

 
GN⁺ 2 시간 전
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

    • Tenho usado cada vez mais programação assistida por LLM em vez de programação totalmente autônoma. Modelos como Opus tendem a ir mudando as coisas até atingir o objetivo, em vez de entender um bom design, e acabam deixando código para o humano arrumar e trabalho excessivo de investigação
      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
    • Muitas vezes fiquei preso em soluções complexas e superprojetadas e, depois de caminhar ou fazer outra coisa, percebi a solução simples. Os LLMs processam tudo imediatamente e tiram de você o tempo de refletir, perceber que chegou a um beco sem saída e pensar nos conflitos com a próxima tarefa
    • Meu side project também chegou a um ponto em que ficou difícil entender todo o código e modificá-lo diretamente com segurança, mas acho que isso já não é mais necessário. Passei quase 20 anos escrevendo código bonito; agora quero focar em produtividade e resultado, e, enquanto o Codex entender código espaguete, isso serve para projetos pessoais ou pequenas software houses independentes
      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
    • O valor real estava menos no código e mais no aprendizado obtido ao chegar até ele. No processo de sofrer para construir algo, você descobre repetidamente requisitos reais e dificuldades técnicas, mas a IA pula esse processo e faz parecer que o objetivo foi atingido superficialmente
      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
    • Em um novo projeto familiar de gestão de agenda, estou aproveitando a velocidade da IA para refinar problemas de experiência do usuário. Quero concluir as funcionalidades da v1 repetindo o ciclo de criar um recurso, usar por alguns dias e corrigir o que não gostei
      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”

    • Também é um bom critério ver se as versões web e para VS Code do Claude Code continuam cheias de bugs. Quase toda execução iterativa de agente quebra e exige recarregamento forçado, e às vezes nem isso resolve. A Anthropic tem, na prática, orçamento ilimitado para LLM e até modelos não lançados
    • Não sou um defensor de que LLM serve para tudo e uso de forma controlada, mas a descoberta automática de vulnerabilidades recente é um avanço interessante. O Chrome corrigiu, só em junho, mais bugs do que nos dois anos anteriores
      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
    • A velocidade de lançamento de projetos está parecida com a de antes, mas, graças às ferramentas de IA, o resultado ficou muito mais polido e rico em funcionalidades. Antes eu lançava algo com só o caminho feliz funcionando; agora consigo entregar cancelamento, exportação de conta, política de privacidade e até todo o app mobile e web sem grande esforço
    • Só de olhar algumas comunidades de desenvolvimento, o número de novos produtos triplicou desde que essas ferramentas apareceram. Não existe nem uma lista que acompanhe todo software lançado e se usou IA ou não, então é estranho concluir que isso não existe só porque você pessoalmente não viu melhora
      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
    • Acho que a adoção prática começou no fim do ano passado, mas é verdade que houve um aumento visível recente de software de hobby. O quão bem isso será mantido é outra questão
  • 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

    • Vi dois posts no Hacker News e, nos dois, o comentário mais votado dizia que “a IA não sabe escrever código e logo vai ruir”. É difícil entender essa insistência em chamar de miragem algo que pessoas usam com sucesso todos os dias há anos
    • Muitas bases de código ruins já foram vendidas por mais de 1 milhão de dólares
    • Nesse caso, fico curioso por quanto o Oracle Database deveria ser vendido
      https://news.ycombinator.com/item?id=18442941
    • Se você mandar corrigir os problemas e fizer a mesma pergunta de novo, ele provavelmente vai repetir críticas parecidas mesmo após as correções
    • Vale pensar por quanto o OpenClaw foi vendido
  • 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

    • Foi excelente para vibe coding de apps únicos e de baixo risco, mas implementar funcionalidades do mesmo jeito em uma enorme base de código legada virou um completo pesadelo
  • 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

    • Muitos consumidores não se importam com baixa qualidade se o produto apenas atender ao padrão mínimo e funcionar. O mesmo aconteceu com eletrodomésticos, software e fast-food
      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
    • Talvez você já esteja sempre aproveitando bons resultados de IA sem perceber. Ninguém gosta de conteúdo gerado avulso quando ele é ruim
    • Quando se vê que as pessoas gastam no total dezenas de bilhões de dólares por mês, dá para dizer que elas realmente gostam
    • Trato resultados gerados por IA apenas como matéria-prima, não como produto final pronto para entregar diretamente ao público
    • O problema não é ser IA, e sim a baixa qualidade. Mesmo quando está óbvio que é IA, as pessoas gostam de resultados bem feitos
  • 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

    • Não está claro quem é esse funcionário que não deveria mexer no código
  • 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

    • Isso corresponde exatamente à minha experiência com LLMs em codebases com cobertura de testes insuficiente, requisitos incertos e formas de deploy não padronizadas. Quando saem do caminho feliz, começam a fazer suposições ruins que quebram a produção, e nem os modelos mais inteligentes chegam ao nível de uma arquitetura adequada para esse tipo de ambiente
  • 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