Engenharia de vibe

• "Vibe Engineering" é um novo nome para uma forma profissional de desenvolvimento que utiliza ferramentas de programação com IA e, diferentemente do "vibe coding" rápido e irresponsável, significa uma abordagem em que engenheiros experientes usam LLMs mantendo a qualidade do código e a responsabilidade
• Com o surgimento de agentes de programação como Claude Code, OpenAI Codex CLI e Gemini CLI, o uso de LLMs em projetos reais aumentou rapidamente, e alguns engenheiros executam vários agentes ao mesmo tempo para trabalho em paralelo
• Para usar LLMs de forma eficaz, são necessárias práticas já consolidadas de engenharia de software de alto nível, como testes automatizados, planejamento prévio, documentação abrangente, controle de versão e cultura de revisão de código
• Ferramentas de IA têm a característica de amplificar a expertise existente, e quanto mais habilidades e experiência um engenheiro sênior possui, mais rápido e melhores tendem a ser os resultados ao usar LLMs
• O termo enfatiza, por meio de uma distinção clara em relação ao "vibe coding", que se trata de uma forma mais difícil e sofisticada de usar IA para desenvolver software de produção, e a combinação aparentemente contraditória entre engenharia e vibe acaba tendo a vantagem de ser fácil de lembrar (destacando as mudanças no processo de desenvolvimento com a evolução das ferramentas de IA e a importância da expertise)

---

Distinção entre vibe coding e vibe engineering

• Vibe coding é uma forma rápida, solta e irresponsável de desenvolvimento de software com IA, totalmente guiada por prompts, uma abordagem que não presta atenção em como o código realmente funciona
• No extremo oposto do espectro, existe uma forma em que profissionais experientes aceleram o trabalho com LLMs, mas continuam orgulhosos do software que produzem e assumem responsabilidade por ele com confiança, e isso é chamado de vibe engineering
• Trabalhar de forma produtiva com LLMs como engenheiro de software em projetos reais, e não apenas em projetos de brinquedo, é uma verdade pouco comentada: é difícil, exige muita profundidade no entendimento das ferramentas e há muitas armadilhas a evitar

O surgimento dos agentes de programação e seu impacto

• Surgiram ferramentas de agentes de programação como o Claude Code, lançado em fevereiro de 2025, o Codex CLI da OpenAI, lançado em abril, e o Gemini CLI, lançado em junho, aumentando drasticamente a utilidade dos LLMs para problemas reais de programação
  • Essas ferramentas modificam o código repetidamente e testam de forma ativa até atingir o objetivo especificado
• Engenheiros de software experientes e confiáveis estão executando vários agentes ao mesmo tempo para resolver diversos problemas em paralelo e ampliar o escopo do trabalho
  • O autor estava cético no início, mas ao testar agentes de programação paralelos na prática, confirmou que isso é mentalmente exaustivo, mas surpreendentemente eficaz
• A maior parte da coleção tools.simonwillison.net foi construída no estilo clássico de vibe coding, mas iterar com agentes de programação para produzir código com qualidade de produção que possa ser mantido no futuro parece um processo completamente diferente

Práticas existentes de engenharia de software que os LLMs reforçam

• Testes automatizados: com uma suíte de testes forte, abrangente e estável, ferramentas de programação com agentes conseguem trabalhar rapidamente; sem testes, o agente pode afirmar que algo funciona sem realmente testar, ou mudanças novas podem quebrar funcionalidades não relacionadas
  • Desenvolvimento orientado a testes é especialmente eficaz para agentes que podem iterar em loop
• Planejamento prévio: quando você se senta para montar algo improvisando junto, tudo vai muito melhor se começar com um plano de alto nível, e isso se torna ainda mais importante ao trabalhar com agentes
  • Você pode iterar primeiro no plano e depois passá-lo ao agente para que ele escreva o código
• Documentação abrangente: assim como programadores humanos, LLMs só conseguem manter em contexto partes do codebase por vez; se você fornecer a documentação relevante, eles podem usar APIs de outras áreas sem precisar ler o código antes
  • Se você escrever uma boa documentação primeiro, o modelo pode construir uma implementação compatível apenas com esse input
• Bons hábitos de controle de versão: é ainda mais importante desfazer erros e entender quando e como algo mudou, já que o agente de programação pode ter feito alterações
  • LLMs são muito bons com Git e podem explorar o histórico por conta própria para rastrear a origem de bugs; usam git bisect melhor do que a maioria dos desenvolvedores
• Automação eficaz: integração contínua, formatação e lint automatizados, e deploy contínuo para ambientes de preview também ajudam ferramentas de programação com agentes
  • LLMs facilitam a escrita rápida de scripts de automação para que o trabalho possa ser repetido com precisão e consistência na próxima vez
• Cultura de revisão de código: se você for rápido e produtivo em code review, terá uma experiência muito melhor ao trabalhar com LLMs
  • Se você preferir escrever o código por conta própria a revisar algo equivalente escrito por outra pessoa (ou por alguma coisa), isso será difícil
• Uma forma muito estranha de técnica de gestão: obter bons resultados com agentes de programação é desconfortavelmente parecido com obter bons resultados de colaboradores humanos
  • É preciso fornecer instruções claras, garantir o contexto necessário e dar feedback acionável sobre o que foi produzido
  • A razão de isso ser muito mais fácil do que trabalhar com pessoas reais é que você não precisa se preocupar em ofendê-las ou desanimá-las, mas a experiência prévia em gestão será surpreendentemente útil
• QA manual realmente excelente: além dos testes automatizados, é preciso ser realmente bom em testar software manualmente, inclusive prevendo e explorando edge cases
• Fortes habilidades de pesquisa: há dezenas de maneiras de resolver um problema de programação, e identificar a melhor opção e validar a abordagem sempre foi importante; isso continua sendo uma barreira antes de soltar um agente para escrever código real
• Capacidade de implantar em ambientes de preview: quando o agente constrói uma funcionalidade, ter uma forma de visualizá-la com segurança (sem fazer deploy direto em produção) torna a revisão muito mais produtiva e reduz bastante o risco de entregar algo quebrado
• Instinto sobre o que pode ser terceirizado para a IA e o que deve ser tratado manualmente: isso continua evoluindo conforme modelos e ferramentas se tornam mais eficazes
  • Uma grande parte de trabalhar bem com LLMs é manter uma forte intuição sobre quando eles podem ser aplicados da melhor forma
• Um senso de estimativa atualizado: estimar quanto tempo um projeto vai levar sempre foi uma das partes mais difíceis — e mais importantes — de ser um engenheiro sênior, especialmente em organizações onde decisões de orçamento e estratégia se baseiam nessas estimativas
  • Programação assistida por IA torna isso ainda mais difícil: coisas que antes levavam muito tempo agora ficam muito mais rápidas, mas as estimativas passam a depender de novos fatores que todos ainda estão tentando entender

A essência e o significado da vibe engineering

• Para realmente aproveitar as capacidades dessas novas ferramentas, é preciso operar no mais alto nível do jogo, incluindo
  • não apenas ser responsável por escrever código, mas também por
  • pesquisar abordagens,
  • tomar decisões de arquitetura de alto nível,
  • escrever especificações,
  • definir critérios de sucesso,
  • projetar loops de agentes,
  • planejar QA,
  • administrar uma tropa cada vez maior de estranhos estagiários digitais que tentam enganar você sempre que têm chance,
  • e gastar muito tempo com revisão de código
• Quase tudo isso já é característica de engenheiros de software sênior
• Ferramentas de IA amplificam a expertise existente e, quanto mais habilidades e experiência você tiver como engenheiro de software, melhores e mais rápidos serão os resultados ao trabalhar com LLMs e agentes de programação

“Vibe engineering”, really? : reflexões sobre a escolha do termo

• Sobre o nome "vibe engineering" ser idiota: provavelmente é, e a ideia de "vibe" em IA já parece um pouco cansada neste ponto, além de o próprio "vibe coding" ser usado de forma depreciativa por muitos desenvolvedores
  • Ainda assim, estou pronto para recuperar a vibe para algo mais construtivo
• Nunca gostei da distinção artificial entre "coder" e "engineer", porque sempre pareceu uma pequena barreira de entrada, mas neste caso uma pequena barreira de entrada é exatamente o que precisamos
  • Vibe engineering estabelece uma distinção clara em relação ao vibe coding, sinalizando que esta é uma maneira diferente, mais difícil e mais sofisticada de trabalhar com ferramentas de IA para construir software de produção
• Gosto da possibilidade de isso soar arrogante e controverso, porque todo esse espaço ainda é absurdo de várias maneiras
  • Enquanto tentamos descobrir as maneiras mais produtivas de aplicar essas novas ferramentas, não devemos nos levar tão a sério
• No passado, houve tentativas de emplacar termos como programação assistida por IA, mas com sucesso quase nulo; desta vez, não parece ruim esfregar um pouco de vibe nisso e ver o que acontece
• Gosto muito da clara incompatibilidade entre "vibe" e "engineering", que torna o termo combinado lúdico e, esperançosamente, memorável por ser autocontraditório

[m00nlygreat]

Pelo que eu sei, não faz muito tempo que também tentaram dar o nome de "que tipo de programação?" e fracassaram, então acho que a expressão mais adequada é programação em par com IA.

Dar um nome só para poder dizer: fui eu que criei esse nome.

[m00nlygreat]

Alguém chegou a chamar isso de codificação aumentada (Augmented Coding), mas o termo desapareceu rapidamente.

[GN⁺]

Opiniões no Hacker News

• Ultimamente, quando leio temas assim, fico meio deprimido. Antes, eu sentia que tinha uma habilidade de programação difícil de encontrar, muito demandada e bem remunerada, e que, mesmo com linguagens e frameworks mudando rápido, eu era inteligente o bastante para acompanhar. Mas quando vejo pessoas como Simon Willison dizendo que esse novo estilo de codificação baseado em agentes e fluxos de trabalho paralelos é o futuro, parece que vai exigir um esforço enorme, e isso me desanima. Já usei agentes de código, mas acabei passando mais tempo esperando, e gerenciar várias tarefas ao mesmo tempo dificulta entrar no fluxo, então fica menos divertido. Por isso, às vezes penso em migrar para uma área totalmente diferente, como vendas.
  • Eu realmente entendo esse sentimento. Na verdade, um dos meus objetivos era justamente contestar a ideia de que "habilidade de programação vai perder o valor e qualquer um vai conseguir escrever código com LLM". Eu acredito que, na prática, quando uma pessoa já tem experiência em desenvolvimento e trabalha com agentes de código ou LLMs, ela se torna muito mais valiosa. Dá para usar tudo o que você aprendeu até aqui para gerar um impacto maior com novas ferramentas. Como o post também menciona, ferramentas de IA amplificam a capacidade de especialistas já existentes. Um iniciante pode até fazer uma UI bonita com ChatGPT, mas não consegue lidar com projeto de arquitetura, testes automatizados, CI/CD, deploy em Kubernetes, operação simultânea de vários agentes e coisas assim, então o papel de engenheiros experientes fica ainda mais importante.
  • Eu também acho pesado esse negócio de "gerenciar vários agentes altamente paralelizados". Por fora parece extremamente poderoso, então é natural que muitos devs se interessem, mas, na prática, isso me parece uma quantidade enorme de estresse e trabalho de gestão. Quando comecei a gostar de desenvolvimento, era porque programar em si era divertido, e eu passava o dia todo codando e aprendendo muito. Agora, depois de mais de 10 anos de carreira, minha cabeça mudou para uma visão mais de negócio, do tipo: "por que isso precisa ser codificado em primeiro lugar?". Em reunião, se outros times perguntam "dá para fazer isso?", a resposta quase sempre é "SIM". Tecnicamente, quase tudo dá. Mas a pergunta realmente importante é "quão difícil é?" ou "por que deveríamos fazer isso?". Ainda acho que o mais importante não é só iterar e lançar um monte de coisas, e sim enxergar a essência.
  • Você expressou exatamente o que eu sinto. Eu também realmente não gosto de ficar supervisionando e gerenciando IA. E, além disso, assusta o fato de essa codificação baseada em IA estar naturalizando uma realidade em que você não consegue trabalhar sem uma conta de uma Big Tech obscura e não verificada.
  • Não precisa se preocupar. Eu também estou mentorando um engenheiro júnior no nosso time, e ele tem muita dificuldade para melhorar código, porque, se funciona, já fica satisfeito. A estrutura não é boa e há pequenos problemas e questões de segurança escondidos por toda parte. Isso acontece até em apenas 3 arquivos Python. No nosso time temos 10 devs, e, quando usamos LLM, a diferença na qualidade do código aumenta ainda mais dependendo do nível de experiência. Pela minha percepção durante os 6 meses antes de o uso de LLM virar oficial, a diferença entre júnior, sênior e pessoas mais experientes na prática ficou ainda maior. É parecido com a visão do Simon.
  • No fundo, basta lembrar que quem tem conhecimento recebe mais poder das ferramentas, e não o contrário.
• No começo de 2023, na época do lançamento do GPT-4, aconteceu uma mudança parecida no setor de tradução. Em tradução inglês-japonês, que é a área em que trabalhei, a tradução automática chegou pela primeira vez perto do nível humano. Na época, tive várias discussões com tradutores profissionais, e, como aqui, muita gente dizia estar frustrada por achar que habilidades difíceis de tradução perderiam o sentido. Muita gente reagia dizendo que, se usasse LLM como assistente, até a parte divertida e desafiadora do processo desapareceria. A maioria dos tradutores que conheci trabalhava como freelancer e traduzia cada frase com muito cuidado. Eles não tinham muita vontade de virar gerentes de grandes projetos de tradução e, mesmo que pudessem usar habilidades sofisticadas de comunicação cultural e contextual, isso não os motivava tanto. Hoje em dia eu já não trabalho tanto com tradução, mas continuo acompanhando de perto os avanços em IA e, às vezes, comparo modelos com tarefas de tradução. Recentemente venho experimentando sistemas de tradução com múltiplos LLMs em camadas, cruzando revisão e melhoria das traduções uns dos outros. Em alguns documentos, o resultado realmente chegou muito perto de uma tradução humana de altíssimo nível. O custo de API não era barato, mas, para traduções importantes, valia muito a pena. E, ao projetar um sistema desses de "vibe translation", minha experiência como tradutor claramente ajudou. Isso lembra o vibe engineering de que Simon fala. Na minha idade atual, 68 anos, isso até está tudo bem, mas, se LLMs e coisas do tipo tivessem surgido no começo da minha carreira, ali pelos 5 a 10 anos de experiência, acho que talvez eu tivesse desistido de ser tradutor.
  • Tradução é realmente um ótimo tema para discussões sobre LLM. Obrigado por compartilhar sua experiência. Por outro lado, a maioria das pessoas não atribui um valor profundo ao tradutor. Por exemplo, quase ninguém lembra quem traduziu um livro. E, como hoje em dia as pessoas talvez leiam menos livros do que antes, isso pode ser ainda mais forte. Além disso, por esse motivo, historicamente a tradução quase sempre foi contratada e paga por número de palavras ou linhas. É tratada como uma checagem final, como segurança de software. As áreas de tradução que talvez realmente tenham competitividade futura são direito, porque alguém precisa responder judicialmente ou assumir responsabilidade, e interpretação simultânea ou presencial, porque exigem contato direto e encontros reais.
• Ultimamente acho meio absurdo como a comunidade técnica anda forçando demais esse discurso de que "codar está mais rápido e a produtividade aumentou". É um clima que valoriza resultados rápidos de qualquer jeito. Na minha experiência, LLM muitas vezes cospe código prolixo e bagunçado. Claro, pode ser mais rápido do que eu, mas mesmo assim eu sinto que o código que faço devagar costuma ser muito melhor. Esse clima de fazer tudo correndo no chat, gerar resultado correndo e levar tudo para produção correndo já foi a causa daquela enxurrada antiga de produtos web malfeitos. Em vez de ficar brincando com termos chamativos como vibe coding ou vibe engineering, deveríamos discutir seriamente por que essa velocidade é tão necessária mesmo com qualidade baixa, e por que a própria automação e os processos não poderiam ser melhorados de outra forma. Por exemplo, dá para criar testes unitários muito rápido, mas acho que também deveríamos perguntar por que precisamos de tantos testes unitários para começo de conversa. Eles claramente são necessários, mas tenho a sensação de que a abstração, a visão mais de cima, está avançando, enquanto as ferramentas de baixo nível, os detalhes, evoluem devagar.
  • O problema central das discussões em engenharia de software é que, mesmo quando ferramentas e linguagens parecem iguais, na prática existe um abismo enorme em tolerâncias, segurança, compliance e critérios de manutenção. Algumas pessoas estão fazendo só um protótipo simples com rapidez; outras lidam com roadmaps de 10 anos ou dados sensíveis. Como essas duas perspectivas acabam se misturando, convivem ao mesmo tempo a visão de que produzir rápido é competência e o medo de que isso gere resultados terríveis. Nenhum dos lados está necessariamente errado, mas parece que o contexto real de trabalho e o nível de risco são sempre ignorados nessas discussões.
  • Sendo realista, é verdade que LLM ajuda absurdamente na velocidade de desenvolvimento. Eu programo há mais de 20 anos, desde o ensino fundamental, e as pessoas ao meu redor reconhecem minha velocidade, mas, depois de adotar LLM, minha escala aumentou de forma gigantesca. O jogo já mudou, e agora a questão é se você consegue se adaptar ou não. Também tenho muita frustração com a incerteza do futuro, mas, se você é um engenheiro em situação parecida, eu entendo perfeitamente.
  • Vou tentar expor a lógica de por que velocidade é tão importante em desenvolvimento de software. Não estou dizendo que minha visão esteja necessariamente certa, nem tenho dados concretos para provar isso. Talvez nem os termos estejam bem definidos. Para começar, dá para pensar em "software trivial" como algo em que todo mundo conhece claramente seu valor e sua solução, em que a validação automática é possível, ou em que existe apenas uma forma de implementação. Mas a maior parte do software real não é trivial. Sempre aparecem bugs, requisitos ausentes, abstrações que vazam, funcionalidades inúteis, problemas de integração, problemas de desempenho, problemas de segurança, complexidade e dores de manutenção. Não importa o quão excelente seja o desenvolvedor ou o quão bem o código seja escrito, esses problemas são inevitáveis. E eles só aparecem e vão sendo melhorados aos poucos por meio de feedback repetido, uso real, manutenção e inúmeros experimentos. Ou seja, não dá para fazer um software perfeito de uma vez; a qualidade melhora ao longo de várias iterações. A qualidade geral do software é dominada pela quantidade desses "loops de feedback". E o tempo que leva para completar um loop limita o número total de iterações possíveis. No fim, quanto maior a velocidade de produção, mais loops de feedback você consegue atravessar e, portanto, melhor o software pode se tornar. Mesmo um código lento, mas de alta qualidade, tem limite se só passar por uma iteração. Por outro lado, mesmo algo de baixa qualidade, se puder iterar infinitamente, pode chegar a um resultado melhor.
  • Daqui a 5 anos isso vai parecer um dos maiores casos de falácia do custo afundado do mundo.
• Acho que, em vez de "vibe coding", o nome mais apropriado seria algo como "agentic coding" ou "agentic software engineering". Meu fluxo de desenvolvimento começa com o plano de código do Claude, e o primeiro passo é sempre criar uma especificação clara. Uso TDD e também imponho, por meio de automação, regras ocultas de qualidade de código que eu defini. Por exemplo, se algo foge do design system, o commit nem acontece, e eu também automatizei verificações para garantir separação em camadas, como obrigar handlers HTTP a passar pela service layer. Eu lembro periodicamente o modelo de seguir bem o TDD, e o Claude 4.5 se lembra muito melhor disso do que o 4.1. Graças ao TDD, até o review de código em PR ficou absurdamente fácil. Também criei uma ferramenta simples que entrega o PR e a especificação ao Gemini para apontar automaticamente inconsistências, omissões e erros. É uma boa ferramenta de backup. Mas, no fim das contas, o importante é ter a capacidade de julgar por conta própria qual resultado você quer e onde o agente está saindo da rota. No final, vale a regra: "entrada ruim, saída ruim; entrada boa, saída boa".
  • Você disse que lembra o modelo sobre TDD, mas, no vibe coding, o agente realmente executa de forma iterativa o loop red-green-refactor do TDD? Ou ele gera tudo de uma vez em uma passada só? Fiquei curioso.
  • Em vez de vibe based, acho que o nome que combina mais é "slop-coding".
• Tenho dúvidas se o nome "vibe engineering" faz mesmo sentido. Na prática, é um jeito de impor todo tipo de restrição ao agente: testes automáticos, planejamento prévio, documentação detalhada, formatação/lint de código, QA manual e assim por diante. Eu também li o texto do Karpathy e comecei a fazer vibe coding; no começo, experimentei esse fluxo de confiar no processo como um todo, mesmo quando o código travava, apenas reexecutando várias vezes. Mas, conforme fui ganhando experiência, percebi que, no fim, você precisa controlar o modelo. Operar agentes é parecido com corrida de kart: você precisa de várias restrições, como os pneus ao redor da pista. O essencial é o Constraint Harness, e o código em si ficou fácil de gerar e regenerar. Daqui para frente, o mais importante será saber acumular bons testes e restrições para o que a IA produz.
  • O nome "vibe engineering" parece leve demais e pouco sério. Um termo neutro e que descreva melhor a função, como "LLM-assisted programming", não seria melhor? Claro que tem menos impacto.
• "Planejamento prévio" talvez também possa ser chamado de spec-driven development. Na verdade, todo desenvolvimento, de uma forma simples, talvez sempre tenha sido baseado em especificações prévias. Mas o ponto central é uma "forma muito estranha de gestão": dar instruções claras, contexto suficiente e feedback acionável. Quando se olha só para o texto, parece até mais próximo de waterfall do que de agile.
• Agora parece que o termo vibe-coding passou a significar toda a codificação baseada em IA. Na prática, quando eu trabalho com IA, a sensação é mais parecida com pair programming, e eu penso mesmo "estou vibe-ing de verdade". Mas aquela vibe-coding original de simplesmente largar tudo na mão dela, no estilo "Take the wheel, LLama of God", ainda vai continuar sendo um fenômeno comum, então acho que precisamos de uma palavra separada para isso. Eu sugeriria “Yolo-Coding”. Combina bem também com a sequência no-code, low-code, yolo-code.
  • Eu acho melhor que vibe coder mantenha uma imagem negativa parecida com no-code. Não gosto muito de vibe engineer, mas, de qualquer forma, acho que no futuro o próprio título de engenheiro/desenvolvedor vai pressupor o uso de agentes, e o desenvolvimento "manual" é que talvez vire exceção.
  • No $enterprise, procurando um nome novo para distinguir "responsible vibing" de "YOLO vibe coding", acabamos chegando ao termo "agent assisted coding", porque precisava muito ter uma sigla de três letras.
  • O significado original de "vibe coding", como no post do Ilya Sutskever no Twitter, é simplesmente digitar o prompt, copiar e colar o resultado e executar sem nem revisar. Sem análise nem validação.
  • Para mim, AI-assisted coding é algo mais no nível de autocomplete ou ajuda para ler documentação ruim. Já vibe coding é quando
  • o desenvolvedor não entende nada do código que o LLM escreveu
  • dívida técnica é criada imediatamente sem qualquer code review
  • juridicamente há enorme fragilidade por questões de proteção autoral na UE/EUA O maior problema fatal do vibe coding, na minha opinião, é que código produzido por LLM essencialmente não pode ser protegido nem registrado por copyright. Há algumas exceções, como o Reino Unido, mas na maioria dos países acho que não tem saída.
  • Eu também criei no Claude um comando de barra tipo /yolo para simplesmente executar sem muita orientação.
• Existe um experimento em que pombos, ao interagir com um aparelho que distribui comida aleatoriamente, passam a acreditar que estão sendo recompensados por causa do próprio comportamento e começam a repetir vários movimentos e danças engraçadas.
  • Talvez essas danças engraçadas sejam justamente coisas como "escrever testes" ou "fazer planejamento".
  • Será que existe algum artigo que sirva de referência para isso? Se eu procuro por "pombo fazendo gracinha", só aparecem vídeos de redes sociais e fica difícil achar.
• "Augmented Engineering" (AE) é um nome melhor. É "engenharia aumentada" porque a IA expande a nossa capacidade e permite alcançar os melhores resultados. AE também pode ser interpretado como "Advanced Engineering". Como a IA nos dá acesso imediato ao conhecimento técnico mais recente, naturalmente isso seria uma engenharia mais avançada. Já vibe não é grande coisa.
  • Não acho que valha a pena se preocupar tanto com a terminologia, e criar um nome separado pode até passar a sensação de que codificação com IA é algo que só se aplica a alguns desenvolvedores. No futuro, codificação tradicional será a forma excepcional, e o termo vibe atual também vai desaparecer em breve.
  • Tenho uma objeção à última frase: a IA não apenas permite absorver "instantaneamente" o conhecimento mais recente de engenharia, como também pode absorver instantaneamente os erros, falhas, mal-entendidos e defeitos de projeto repetidos nos últimos 1 a 10 anos. Ou seja, você nunca deve confiar sem senso crítico no que a IA fornece, deve sempre verificar a fonte, e ainda confirmar se essa fonte não foi gerada por IA também. Como os datasets estão cada vez mais contaminados, isso exige ainda mais cuidado.
  • Eu perguntaria se "Augmented Engineering" realmente precisa ser um nome separado. No fundo, isso é só "engenharia". Do mesmo jeito que ninguém chama de "engenharia assistida por livro" o fato de trabalhar consultando referências, o mesmo vale para vibe. Se quiser muito, poderia chamar de "Yolo engineering" ou até "Machine Outsourced Irresponsible LMAO Engineering", e esse último "Advanced Engineering" também me parece um pouco inflado.
• O Simon sempre acerta em cheio no ponto, mas o problema real não é tanto "coding" e sim a palavra "vibe". Mesmo mudando para vibe engineering, ainda fica a nuance de "seguir em frente sem saber o que está fazendo". Acho que um termo como "AI-assisted software engineering", que delimita melhor as duas pontas, funciona melhor.

[kimjoin2]

Criando um nome sem sentido;