Líderes de pensamento

CÃģdigo Vibe, IA e a Nova Realidade da Engenharia

mm
Adicione Unite.AI às suas fontes preferidas no Google

HÃĄ dez anos, a ideia de que a IA poderia escrever cÃģdigo em vez de programadores soava mais como uma fantasia emocionante. Hoje, tornou-se parte da realidade cotidiana. MVPs sÃĢo construídos em dias, interfaces sÃĢo geradas a partir de prompts de texto e assistentes de IA estÃĢo se tornando participantes integrais de equipes de engenharia.

Contra esse pano de fundo, mais e mais pessoas estÃĢo fazendo as mesmas perguntas: A IA estÃĄ realmente substituindo os programadores? A inteligÊncia artificial pode realmente igualar e substituir um engenheiro sÊnior? E o que acontecerÃĄ com a profissÃĢo no futuro prÃģximo?

Sou um desenvolvedor eu mesmo e tenho uma opiniÃĢo sobre isso. Vamos analisar.

Qual ÃĐ o cerne do problema?

Existe uma narrativa dominante sobre a programaçÃĢo de IA que vai mais ou menos assim:

A IA estÃĄ se tornando extremamente eficaz em escrever cÃģdigo e, importante, jÃĄ evita muitos dos erros comuns que os humanos cometem. Ainda mais interessante ÃĐ que a IA pode ser melhor em lidar com os chamados casos de borda: cenÃĄrios raros e incomuns que sÃĢo ubíquos na engenharia de software e frequentemente difíceis para os desenvolvedores antecipar com antecedÊncia.

Quando o programador diz: “Quero um botÃĢo aqui”, ele obtÃĐm uma resposta: “Aqui estÃĄ o botÃĢo, aqui estÃĢo 18 casos de borda que vocÊ deve considerar, aqui estÃĢo os testes que vocÊ precisa executar e, por sinal, vocÊ tambÃĐm pode querer adicionar isso e aquilo.” VocÊ pode olhar para isso e pensar: “Simâ€Ķ isso realmente faz sentido.” Sozinho, vocÊ pode ter percebido esses problemas semanas depois – depois que algo jÃĄ havia dado errado em produçÃĢo. A IA frequentemente sugere soluçÃĩes imediatamente. Para os engenheiros que jÃĄ tÊm empregos, isso aumenta significativamente a produtividade e a eficiÊncia.

E essa narrativa leva diretamente a uma questÃĢo econÃīmica: se uma empresa precisava de 100 desenvolvedores para lidar com uma certa carga de trabalho, teoricamente agora pode precisar de apenas 20 – porque esses 20 podem realizar a mesma quantidade de trabalho com a ajuda da IA.

O que estÃĄ por trÃĄs dessa aceleraçÃĢo?

Cada vez mais, vejo engenheiros de software muito fortes temerem por suas posiçÃĩes, lugar no mercado e renda. Parece que logo nÃĢo haverÃĄ mais trabalho para os codificadores.

E minha resposta ÃĐ geralmente: caras, nÃĢo ÃĐ tÃĢo dramÃĄtico quanto parece. Na verdade, os engenheiros experientes estÃĢo ganhando um novo tipo de valor agora. Porque podemos ser uma das Últimas geraçÃĩes de desenvolvedores que realmente escreveram cÃģdigo à mÃĢo e entendem profundamente como os sistemas funcionam por baixo dos panos. A prÃģxima geraçÃĢo estÃĄ cada vez mais trabalhando com ferramentas de IA – e, junto com isso, a prÃģpria prÃĄtica de engenharia estÃĄ mudando.

Aqui estÃĄ o que a narrativa anterior nÃĢo leva em conta:

O cÃģdigo gerado pela IA frequentemente parece perfeitamente bom. As tarefas sÃĢo resolvidas, as interfaces funcionam e tudo roda. Mas, com o tempo, a longo prazo, problemas mais sutis começam a aparecer: compromissos arquitetÃīnicos, decisÃĩes de engenharia fracas, problemas com estruturas de dados ou questÃĩes de escalabilidade. E isso acontece porque a IA jÃĄ ÃĐ muito boa em resolver tarefas locais, enquanto a lÃģgica de longo prazo de grandes sistemas ainda requer experiÊncia e julgamento humanos.

É por isso que, uma vez que esses projetos atingem ambientes de produçÃĢo sÃĐrios – bancos, plataformas de comÃĐrcio eletrÃīnico, serviços em grande escala – as equipes eventualmente ainda precisam de pessoas que possam analisar profundamente a arquitetura, identificar as causas raiz e restaurar a lÃģgica geral do sistema.

Muitas vezes, recebo ligaçÃĩes de amigos dizendo coisas como: “Michael, pode pular e nos ajudar a entender por que o sistema estÃĄ começando a desmoronar?” Embora eu trabalhe agora com IA Física na Introspector, ainda ocasionalmente posso ajudar com esse tipo de trabalho de engenharia manual difícil: reconstruir a lÃģgica do sistema, analisar a arquitetura e descobrir onde os problemas começaram a se acumular.

E ÃĐ exatamente por isso que acredito que engenheiros fortes permanecerÃĢo muito valiosos por um longo tempo. Ao mesmo tempo, ÃĐ frequentemente os engenheiros experientes que estÃĢo ajudando a melhorar e treinar modelos de IA hoje. Na Keymakr, vimos isso acontecer quando procurÃĄvamos por desenvolvedores experientes para validar cÃģdigo e ajudar a treinar modelos – pessoas que possam confiar no pensamento de engenharia real, experiÊncia prÃĄtica e compreensÃĢo profunda de como os sistemas se comportam no mundo real.

As principais hipÃģteses

E isso nos leva à maior pergunta sobre o futuro: para onde tudo isso estÃĄ levando? Como vamos crescer a prÃģxima geraçÃĢo de engenheiros se eles estÃĢo entrando na indÚstria por um caminho completamente diferente desde o início?

Se olharmos para a situaçÃĢo objetivamente, sem hype ou medo, vejo alguns cenÃĄrios possíveis.

  • Um futuro incerto

A primeira e provavelmente a resposta mais honesta ÃĐ que muito poucas pessoas hoje estÃĢo pensando realmente à frente. Simplesmente porque ninguÃĐm ainda entende completamente como esse futuro serÃĄ na prÃĄtica.

Talvez, em alguns anos, os agentes de IA realmente sejam capazes de escrever cÃģdigo quase perfeito – com arquitetura forte, escalabilidade e compreensÃĢo contextual. Agora, essa pergunta ainda estÃĄ completamente aberta.

Ao mesmo tempo, grandes empresas de tecnologia como Apple, Microsoft e Google continuam ativamente contratando pesquisadores fortes, especialistas em PhD e pessoas de ambientes acadÊmicos. Isso provavelmente sugere que acreditam que a compreensÃĢo profunda de engenharia permanecerÃĄ importante, mesmo em um mundo onde a maioria do cÃģdigo ÃĐ gerada automaticamente.

Empresas menores, no entanto, frequentemente operam com um horizonte de planejamento muito diferente. Quando vocÊ nÃĢo sabe se sua startup ainda existirÃĄ em seis meses, torna-se difícil pensar seriamente sobre o que pode acontecer daqui a dez anos. Claro, ninguÃĐm intencionalmente quer construir algo fundamentalmente quebrado. As equipes ainda tentam identificar riscos e fraquezas potenciais.

Mas, na realidade, a lÃģgica ÃĐ frequentemente muito mais simples: primeiro, construa um produto que funcione e gere receita – entÃĢo lide com a arquitetura, otimizaçÃĢo e reescrita do sistema mais tarde. O problema ÃĐ que, em muitos projetos, “mais tarde” continua sendo adiado indefinidamente.

  • EvoluçÃĢo em espirais

A segunda resposta, na minha opiniÃĢo, ÃĐ ainda mais interessante. Se vocÊ olhar para a histÃģria da indÚstria, ela jÃĄ passou por transiçÃĩes semelhantes muitas vezes antes. Os primeiros programadores trabalhavam com cartÃĩes perfurados. EntÃĢo veio a geraçÃĢo de engenheiros que escreviam em Assembly – algo que jÃĄ ÃĐ difícil para muitos desenvolvedores modernos imaginar. Naquela ÃĐpoca, vocÊ tinha que literalmente entender como o hardware funcionava, pensar em termos de lÃģgica de processador e manter uma enorme quantidade de complexidade de baixo nível na cabeça.

EntÃĢo veio a era do COBOL. Mainframes de bancos inteiros foram construídos com ele, e a parte mais surpreendente ÃĐ que uma porçÃĢo significativa da infraestrutura bancÃĄria global ainda roda nesses sistemas antigos hoje. Ainda hÃĄ programadores com 60 e 70 anos mantendo essa base de cÃģdigo, e eles permanecem especialistas extremamente valiosos.

A prÃģxima geraçÃĢo mudou para C++, Python e JavaScript. Eu mesmo pertenço a essa era. Por exemplo, mal entendo como o COBOL funciona. Na teoria, eu poderia aprender – mas para mim jÃĄ parece algo distante e estranho.

E, quando vocÊ olha para isso historicamente, um padrÃĢo interessante emerge: cada nova geraçÃĢo de engenheiros nÃĢo precisa mais entender profundamente como a tecnologia da geraçÃĢo anterior funcionava. Com o tempo, o conhecimento se torna incorporado à prÃģpria infraestrutura.

Os cartÃĩes perfurados desapareceram hÃĄ muito tempo – sua lÃģgica agora estÃĄ incorporada aos processadores. A Assembly praticamente desapareceu como ferramenta mainstream porque sua complexidade se tornou oculta dentro dos sistemas operacionais, drivers e abstraçÃĩes de baixo nível. AtÃĐ mesmo seus fones de ouvido hoje provavelmente contÊm um pequeno sistema operacional executando toda essa complexidade oculta em segundo plano – a maioria das pessoas simplesmente nunca pensa nisso.

Claro, ainda hÃĄ especialistas que entendem toda essa magia de baixo nível. Mas, para a maior parte da indÚstria, isso jÃĄ se tornou uma camada de abstraçÃĢo.

E isso leva a uma ideia muito lÃģgica: talvez a IA seja simplesmente a prÃģxima etapa dessa evoluçÃĢo. Talvez a prÃģxima geraçÃĢo realmente nÃĢo precise entender a programaçÃĢo clÃĄssica tÃĢo profundamente quanto fizemos.

  • A economia do mercado

Outra hipÃģtese que tenho ÃĐ que o cÃģdigo vibe – ou desenvolvimento assistido por IA – eventualmente pararÃĄ de ser percebido como “aceleraçÃĢo gratuita”. Na realidade, jÃĄ nÃĢo ÃĐ completamente gratuito; ÃĐ apenas que, por enquanto, nem todos estÃĢo calculando cuidadosamente a verdadeira economia por trÃĄs disso.

Modelos, tokens, infraestrutura, solicitaçÃĩes constantes, manutençÃĢo de toda a pipeline de IA – tudo isso estÃĄ se tornando um despesa operacional significativa. É por isso que acredito que as empresas logo começarÃĢo a olhar muito mais de perto para o custo real do desenvolvimento assistido por IA e a fazer uma pergunta muito pragmÃĄtica: o que ÃĐ realmente mais eficiente – expandir uma equipe de engenharia ou manter toda a infraestrutura de IA em torno do desenvolvimento?

Um cenÃĄrio muito realista ÃĐ que equipes de engenharia fortes possam, no final, provar ser mais sustentÃĄveis economicamente, especialmente quando se trata de manter, evoluir e dar suporte a produtos a longo prazo.

No entanto, acho que ÃĐ exatamente aqui que um novo tipo de equipe de engenharia pode surgir: grupos muito pequenos de especialistas altamente experientes focados em manter a estabilidade e a resiliÊncia da infraestrutura em si. Com o tempo, isso pode se tornar uma das especializaçÃĩes de engenharia mais valiosas da indÚstria.

  • Pessoas que trabalharÃĢo ao lado da IA

E a suposiçÃĢo final – embora muito realista – ÃĐ que a prÃģxima geraçÃĢo de engenheiros provavelmente terÃĄ que construir suas carreiras em um ambiente completamente diferente. E isso vai muito alÃĐm da programaçÃĢo sozinha. Mudanças semelhantes jÃĄ estÃĢo começando a redefinir direito, finanças, medicina e quase todos os campos onde a IA pode assumir uma parte significativa do trabalho intelectual rotineiro.

Apesar de tudo isso, ainda tendo a ver o que estÃĄ acontecendo de forma bastante positiva. Provavelmente porque, no geral, eu realmente gosto de progresso. Eu gosto da ideia de que a tecnologia pode melhorar a vida das pessoas, libertar os humanos de enormes quantidades de trabalho repetitivo e tornar muitos processos mais seguros e eficientes.

Por exemplo, sistemas de direçÃĢo autÃīnoma como os da Tesla ou da Waymo jÃĄ estÃĢo demonstrando níveis de segurança notavelmente altos em muitos cenÃĄrios em comparaçÃĢo com os motoristas humanos. E isso ÃĐ genuinamente impressionante.

Ao mesmo tempo, o mundo em que as nossas crianças estÃĢo entrando serÃĄ muito mais complicado em termos de identidade profissional. Eles terÃĢo que procurar seu lugar e propÃģsito em um cenÃĄrio em rÃĄpida mudança.

Se uma criança hoje quiser se tornar um advogado, um analista financeiro ou um programador, hÃĄ uma grande chance de que essas profissÃĩes sejam completamente diferentes no futuro. Talvez essas se tornem especialistas que trabalham em estreita colaboraçÃĢo com IA jurídica, IA financeira ou IA de codificaçÃĢo – pessoas que operam sistemas de IA, validam saídas, fornecem contexto e tomam as decisÃĩes-chave.

Acho que ÃĐ importante reconhecer que quase todos esses cenÃĄrios jÃĄ se sentem realistas hoje. E, gostemos ou nÃĢo, tudo o que estÃĄ acontecendo agora ÃĐ parte de uma onda muito maior de progresso tecnolÃģgico. É muito improvÃĄvel que esse processo possa ser interrompido. O que significa que teremos que aprender a viver nesse novo mundo – gradualmente aprendendo a equilibrÃĄ-lo, comunicar-se com ele e, talvez, atÃĐ desenvolver uma nova forma de coexistÊncia ao lado dele.

Michael Abramov ÃĐ o fundador e CEO da Introspector, trazendo mais de 15 anos de experiÊncia em engenharia de software e sistemas de visÃĢo computacional de IA para a construçÃĢo de ferramentas de rotulagem de nível empresarial.

Michael começou sua carreira como engenheiro de software e gerente de P&D, construindo sistemas de dados escalÃĄveis e gerenciando equipes de engenharia multifuncionais. AtÃĐ 2025, ele atuou como CEO da Keymakr, uma empresa de serviços de rotulagem de dados, onde ele pioneirou fluxos de trabalho humanos no loop, sistemas de QA avançados e ferramentas personalizadas para atender às necessidades de dados de visÃĢo computacional e autonomia em larga escala.

Ele possui um B.Sc. em CiÊncia da ComputaçÃĢo e uma formaçÃĢo em engenharia e artes criativas, trazendo uma lente multidisciplinar para resolver problemas difíceis. Michael vive na interseçÃĢo da inovaçÃĢo tecnolÃģgica, liderança de produto estratÃĐgica e impacto no mundo real, impulsionando a prÃģxima fronteira dos sistemas autÃīnomos e automaçÃĢo inteligente.