CEO do GitHub diz que, mesmo com o boom da AI, codificação manual continua sendo essencial
(techinasia.com)- O CEO do GitHub, Thomas Dohmke, enfatiza a importância da capacidade de codificação manual mesmo com a expansão das ferramentas de AI
- Mesmo quando a AI gera código, ele defende que os desenvolvedores precisam revisar e corrigir diretamente para trabalhar com eficiência
- Depender apenas da automação pode trazer ineficiência real e prejudicar a produtividade, e o uso excessivo de código gerado por AI, como no "vibe coding", aumenta os riscos de qualidade e segurança
- Ele explica, com base em tendências e casos do setor, que a abordagem híbrida entre AI e desenvolvedores humanos é a mais eficaz
- O papel do desenvolvedor não está desaparecendo; ele está evoluindo para uma atuação que exige colaboração com AI, resolução estratégica de problemas e capacidade de arquitetura
CEO do GitHub destaca a importância da codificação manual mesmo na era da AI
O CEO do GitHub, Thomas Dohmke, destacou a importância de manter a capacidade de codificação manual, mesmo com a expansão do uso de ferramentas de AI no desenvolvimento de software
- Em participação no “The MAD Podcast with Matt Turck”, ele explicou que os desenvolvedores precisam ter a capacidade de editar diretamente o código gerado por AI para evitar queda de produtividade
- Um fluxo de trabalho eficaz, segundo ele, é aquele em que a ferramenta de AI gera o código e envia um Pull Request, e então o desenvolvedor usa sua habilidade para corrigir imediatamente
- Também foi mencionado que, ao depender apenas de agentes de automação, há risco de ineficiência por gastar tempo desnecessário explicando pequenas alterações em linguagem natural
- Dohmke apontou que “tentar descrever em linguagem natural algo que você já sabe fazer diretamente em uma linguagem de programação é a escolha mais ineficiente”
- O termo “vibe coding”, citado pelo cofundador da OpenAI Andrej Karpathy, refere-se à dependência excessiva de código gerado por AI, e Dohmke também alertou para esse ponto
Insights e tendências do setor
1. A melhor solução para codificação com AI é uma estratégia híbrida
- A visão de Dohmke está alinhada ao consenso do setor de que a combinação entre automação por AI e habilidade humana de programação é a melhor abordagem
- Segundo pesquisa da Deloitte, os desenvolvedores usam ferramentas de AI principalmente para escrever código boilerplate, mas mantêm a revisão final humana, obtendo assim um ganho de produtividade de 10 a 20 minutos
- Cerca de metade do código gerado por AI contém erros parciais, por isso a estratégia de “confiar, mas verificar” vem se consolidando como padrão do setor
- O Google já gera mais de 25% de todo o seu código com AI, mas sua experiência mostra que o processo de revisão ativa e aprimoramento por desenvolvedores humanos continua indispensável
- Essa abordagem equilibrada reflete o amadurecimento do setor, que reconhece os limites da AI e caminha para ampliar, e não substituir, a expertise dos desenvolvedores
2. O papel do desenvolvedor está mudando, não desaparecendo
- Em vez de eliminar as profissões de programação, a AI está levando o papel do desenvolvedor a mudar de codificador puro para gestor de processos de desenvolvimento baseados em AI
- Especialistas projetam que a carreira de desenvolvimento deve se dividir entre engenheiros de produto que utilizam AI e arquitetos voltados à garantia avançada de qualidade e segurança de sistemas
- Essa mudança indica a necessidade de novas capacidades, como uso eficaz de AI, resolução estratégica de problemas e competência de design em alto nível
- Somado à escassez de engenheiros de software, o efeito das ferramentas de AI em apoiar desenvolvedores juniores tem sido comprovado, criando também novas oportunidades de crescimento para profissionais experientes
- Isso sugere que, assim como ocorreu com ferramentas de desenvolvimento e tecnologias de abstração no passado, a criatividade humana continua sendo necessária
3. O dilema entre produtividade e qualidade no “vibe coding”
- O fenômeno do “vibe coding” expõe a vantagem de produtividade do código gerado por AI, mas também seus limites de qualidade e segurança
- Ferramentas de AI ajudam em prototipagem rápida e desenvolvimento iterativo, mas também aumentam as preocupações com queda da qualidade do código e riscos de segurança
- Em casos reais, já houve vulnerabilidades de segurança decorrentes do uso de código gerado por AI sem validação
- Em ambientes como startups lideradas por fundadores sem formação técnica, o uso excessivo de código gerado por AI pode acumular dívida técnica e acabar prejudicando o crescimento de longo prazo
- A experiência de grandes empresas de tecnologia indica que o essencial na adoção de AI é o equilíbrio entre automação e controle rigoroso de qualidade, uma lição que também é importante para startups
1 comentários
Opiniões no Hacker News
Fico muito intrigado com o motivo de as pessoas não falarem mais sobre a complexidade essencial dos sistemas
Em No Silver Bullet, Fred Brooks aponta que a verdadeira dificuldade da engenharia de software vem de entender, esclarecer e modelar o espaço central do problema. A complexidade acidental, como limitações de ferramentas, é secundária
Ultimamente, fala-se muito que agentes de IA vão criar bases de código inteiras a partir de prompts em linguagem natural no lugar dos engenheiros. Mas essa suposição parte da ilusão de que o problema da especificação já foi resolvido. Na prática, transformar ideias vagas em sistemas detalhados e robustos continua sendo o papel central do engenheiro
Se alguém fornece especificações detalhadas e trabalha iterativamente com a IA para criar software, na prática está usando IA para eliminar complexidade acidental. Isso é parecido com a transição de assembly para linguagens de alto nível. Não substitui o engenheiro, apenas aumenta a produtividade. Também reduz o custo do trabalho repetitivo e cria a chance de ampliar o impacto
Se um agente constrói um produto apenas com prompts, é porque alguém já definiu o sistema com clareza. E se a IA apenas replica produtos existentes, isso deixa de ser resolução de problema técnico e passa a ser disputa de distribuição ou custo, o que não é inovação em engenharia, mas inovação de negócios
Fico me perguntando se estou deixando passar alguma coisa
O ponto central é por que o trabalho de especificação já vinha sendo negligenciado muito antes do surgimento da IA
As partes interessadas (clientes, gerentes) sempre fizeram as pessoas programarem no improviso. Dão uma explicação vaga e alguém milagrosamente entrega uma solução que parece se encaixar. Ninguém sabe se a solução funciona por completo. Muitas vezes só seguem em frente porque parece funcionar mais ou menos
Na maioria dos casos, o programador concretiza isso com base em conhecimento de domínio (por exemplo, porque sabe intuitivamente como deve ser uma página correta de envio de formulário)
Agora só trocaram a outra parte por uma IA, e ainda está para ser visto se esse modo de trabalho pode simplesmente se repetir do mesmo jeito
A distinção entre complexidade essencial/acidental é uma percepção muito importante para pensar até onde a IA pode assumir o desenvolvimento de software
Muitos desenvolvedores não conseguem explicar em palavras por que não serão substituídos por IA, mas sentem isso intuitivamente exatamente nesse ponto
Eu mesmo já tentei fazer um agente como o Claude resolver problemas em uma base de código enorme e muito complexa, cheia de lógica de negócio externa. Mas a IA não consegue intuir corretamente os requisitos de negócio nem o contexto, então não faz mudanças de código ligadas ao negócio. Ela só ajuda com mudanças de código mais restritas em contexto. Ou seja, só consegue lidar com complexidade acidental, e tem limites para traduzir requisitos reais em sistema, que é o verdadeiro papel do desenvolvedor
Além disso, na prática, o que muitos desenvolvedores resolvem talvez nem sejam problemas técnicos, mas problemas de distribuição/mercado. Substituir juniores por IA ainda parece arriscado. A maior questão é que a IA não consegue fazer autocorreção sozinha. Mesmo assim, continuarão surgindo negócios baseados em IA tentando reduzir custos de empresas existentes. Se essa mudança será boa ou ruim pouco importa para quem for expulso do mercado de trabalho
Há uma resposta para “será que estou deixando passar algo?”
Na verdade, existe um número enorme de desenvolvedores que não sabem usar software. Esses serão facilmente substituídos por IA
Em empregos anteriores, trabalhei com JavaScript, e as pessoas que faziam coisas realmente impressionantes eram apenas aquelas que programavam por hobby havia muito tempo. Na empresa, a maioria mal conseguia colocar texto na tela. Não é brincadeira
Muita gente tentou encarar frameworks gigantes, mas no fim só fazia copiar e colar até algo funcionar. Fingem resolver alta complexidade, mas quase tudo é trabalho desnecessário ou exibicionismo de código
Quase não têm capacidade de criar apps originais, escrever documentação ou medir usabilidade real
Como resolver isso? Implementando padrões elevados como o exame da ordem dos advogados, eliminando sem dó quem não atinge o nível mínimo e contratando essas pessoas apenas como juniores ou aprendizes, para que uma geração de desenvolvedores possa amadurecer direito
A resposta simples sobre o “ponto que está faltando” é que ninguém no setor leu "No Silver Bullet"
Quem escreve sobre dívida técnica e arquitetura de sistemas normalmente não é quem toma as decisões que realmente determinam os rumos do time ou do negócio, e esses livros também são leitura opcional para engenheiros
Quem lidera o discurso de substituir programação por IA muitas vezes não consegue distinguir entre criar um MVP e expandir uma base de código por 10 anos enquanto melhora o legado
Por exemplo, um gerente já fez a sugestão clássica e errada de dividir o dia em 33% para cada um de 3 projetos. Alocar pessoas e estruturar tempo deveria ser competência de gestão, mas no fim quem faz isso funcionar de verdade são os engenheiros
Agora esses mesmos gerentes propõem “vamos mandar a IA resolver toda a dívida técnica e os testes”, e quando não funciona direito quem precisa explicar são os engenheiros
No fundo, falar de complexidade é só repetir um problema de má gestão. A grande maioria dos engenheiros experientes já não acredita que seu trabalho será substituído por um prompt simples
O verdadeiro tema que deveríamos discutir é: “a engenharia de software tem um sério problema de gestão, e a IA só evidencia isso ainda mais”
Muitos não desenvolvedores ou estudantes sentem que desenvolver software exige aprender ferramentas complicadas e se sentem atraídos pela promessa de que “qualquer um pode criar software se fizer boas especificações” (omitindo completamente que a própria capacidade de especificar é muito difícil e exige tecnologia de suporte)
O movimento no-code também era assim, e na prática as ferramentas no-code são limitadas; quanto mais poderosas ficam, mais exigem aprendizado complexo e especializado
A tese de substituir engenharia de software com LLM também acaba sendo uma versão de “em vez de aprender o sistema, basta escrever prompts em linguagem natural e o modelo usa as ferramentas por você”
Vendo por esse lado, o que hoje chamam de vibe coding é praticamente o extremo desse objetivo (embora tenha fragilidades reais, como manutenção)
Na minha visão, um dos motivos pelos quais gestores querem eliminar engenheiros de software é que eles não conseguem se comunicar bem com eles
Com LLMs, acreditam que podem se comunicar com a máquina sem precisar dos “nerds (desenvolvedores)”, e acham que isso resolve o problema
Linguagens de programação são um meio adequado para especificações precisas do programa desejado. Linguagem natural jamais terá esse grau de clareza
Por isso, revisar e editar o que a IA gera é natural. Em alguns casos, pode até ser mais fácil corrigir diretamente do que explicar a mudança
Fico pensando se os estudos independentes mostrando que o Copilot aumenta a taxa de erros não ajudaram naturalmente a espalhar uma postura mais cautelosa
Quem vende IA muitas vezes afirma que autores humanos em breve deixarão de ser necessários
Transformers podem ser aplicados a várias tarefas: testes automatizados, expansão de especificações, aceleração de novos projetos, exploração de APIs desconhecidas, construção de funcionalidades iniciais, revisão de código etc.
Mesmo que código seja o meio correto para especificação, Transformers funcionam como uma interface automatizada entre linguagem natural e esse meio (o código)
Hoje, graças ao enorme volume de conhecimento, Transformers não têm problema para gerar código
Assim como humanos buscam automação na programação, Transformers representam um salto enorme
Em algum momento no futuro, a substituição de programadores por IA pode virar realidade (como aconteceu com o tear automático, a imprensa e as calculadoras eletrônicas substituindo trabalho humano)
Só que isso talvez não aconteça agora, nem dentro de 10 anos, e ainda há desafios como alucinação, precisão, ferramental e infraestrutura
A existência de empregos em programação pode variar conforme domínio, habilidade e expectativa de remuneração
É importante levar ferramentas de IA a sério e se adaptar. Caso contrário, há o risco de ficar para trás, como aconteceu nas épocas da adoção da computação pessoal e da internet
Acho que a pseudocriatividade da IA tem limites
Se tudo o que os LLMs aprendem volta a circular apenas como entrada para LLMs, a faixa de ideias novas jamais se ampliará
Os humanos continuam demonstrando criatividade para ir além dessa faixa
No futuro, LLMs podem até ultrapassar essa barreira, mas por enquanto não parecem muito diferentes de um “macaco com máquina de escrever”
Na minha experiência, os LLMs funcionam melhor quando usados como scaffolding (ferramenta de sustentação)
Eu despejo de forma crua a funcionalidade que quero criar e então peço para o modelo montar isso junto com os controladores básicos necessários
O que sobra para mim é focar só nas views e na lógica real de negócio, deixando a divisão do trabalho bem clara
Pelo que sei, quando linguagens de alto nível surgiram, no começo também houve críticas parecidas com as de hoje a LLMs ou código em linguagem natural, no sentido de “falta precisão porque não dá para controlar memória diretamente”
O problema não é que linguagem natural seja incapaz de precisão, mas que a maioria das pessoas explica os requisitos de forma imprecisa ou só consegue deixar claro o que quer, sem explicar direito o que o computador realmente precisa fazer
Como resultado, o engenheiro faz um enorme trabalho de adivinhação ao traduzir requisitos de negócio, ou o LLM tenta assumir esse papel entendendo ainda menos contexto
O melhor uso da IA é manter meu estado de fluxo sem travar em APIs que nunca vi antes ou em funcionalidades chatas que não quero implementar manualmente
A IA consegue aplicar padrões comuns a todo o código de forma rápida e eficiente, mas essencialmente 'não sabe o que está fazendo'
Compartilhando uma experiência recente: tentei fazer um LLM refatorar código relacionado ao cálculo de tamanho e posicionamento de pop-ups
Um trecho estava escrito com
ife outro comswitch, mas o LLM não reagiu com nenhuma flexibilidade a essa diferença e, mesmo com explicações claras, uniformizou os dois paraifou os dois paraswitchO LLM tende a continuar o padrão dos tokens anteriores
Aqui isso não foi um grande problema, mas em situações um pouco mais complexas ele ignora nuances e entrega código superficialmente plausível
Por outro lado, se você quebra em partes pequenas e dá instruções claras, o LLM é bastante eficiente. Por exemplo, instruções como “salve o tamanho em
m_StateStoragee aplique na etapa de renderização” ele executa facilmenteEspecialmente com modelos como os da Cerebras, que conseguem processar rapidamente até alguns kilobytes de código, isso é muito mais rápido do que eu digitar diretamente meus pensamentos como código
No fim, o que se avalia hoje são críticas limitadas ao desempenho atual dos modelos Transformer
Este setor muda tão rápido que as limitações de hoje podem deixar de fazer sentido em um mês
“LLM” também é, estritamente falando, um termo vago. Os modelos Transformer mais recentes são multimodais e lidam com várias formas de dados, não só texto
Portanto, se for criticar, é preciso apontar concretamente qual modelo/ferramenta/paradigma está sendo discutido para que a conversa seja útil
Sobre os estudos que falam em “falta de engenheiros de software” e que “a IA ajuda especialmente desenvolvedores juniores”
Na linha do tempo em que eu vivo, o mercado de trabalho em tecnologia está péssimo, e a IA está até prejudicando juniores ao tomar deles as experiências pelas quais deveriam crescer
Tive uma experiência curiosa recentemente com o Claude. No Zed, mandei “corrija o erro na linha 71”, e ele foi mexer em formatação inútil na linha 91
Parecia brincadeira de telefone sem fio com um LLM
Para uma correção tão simples, fazer eu mesmo é mais rápido. Essa experiência só reforçou a sensação de que “LLMs realmente não pensam”
LLMs são péssimos em reconhecer números de linha
A lição disso foi “LLMs não sabem contar números de linha”
Da próxima vez, seria melhor dizer “corrija o erro na função XYZ” ou colar diretamente a linha em questão
E, claro, LLMs não pensam mesmo. São apenas uma enorme equação
Parece que há muita gente nesta thread programando com IA pela primeira vez
Pode ter sido erro do operador
Você precisa dar contexto adequado ao LLM. Números de linha são um contexto ruim
Para mim, o papel do engenheiro de software é transformar requisitos em software
Software não é só código, e requisitos também não são dados apenas em linguagem natural simples
Neste momento, mesmo trabalhando com IA, eu não sou mais rápido com ela do que sem ela (tirando tarefas simples e software pequeno)
Hoje, para mim, a IA está num nível de desenvolvedor júnior/pleno
Nos últimos 2 anos, não senti uma melhora revolucionária tão grande assim na prática
A maioria dos requisitos não chega documentada com clareza
Quase ninguém sabe qual é de fato a lógica de negócio
Por isso, o engenheiro de software frequentemente precisa ir atrás das pessoas para perguntar
Também é necessário experiência e intuição para pensar na direção de crescimento do software e em como projetá-lo de modo que suporte essa expansão
Não consigo imaginar LLMs assumindo nem parte desse papel
Nunca vi um projeto de software com requisitos claramente definidos
Metade do projeto é descobrir “o que realmente se quer”
LLMs ainda não chegam nem ao nível júnior
Se a IA atual estiver no nível de um desenvolvedor pleno da sua empresa, então isso é um problema de contratação da empresa
Uma das maiores vantagens dos computadores é a automação confiável e reproduzível
Linguagens formais, como linguagens de programação, permitem transmitir com clareza e sem ambiguidade os requisitos da automação desejada
A linguagem natural não tem esse nível de precisão
A verdadeira fonte de verdade de um programa continua sendo o código
Se humanos querem controlar com precisão o comportamento de programas, a capacidade mais importante continua sendo entender e modificar código
A palavra “manual” tem uma nuance negativa
O que o artigo parece querer dizer é “programação humana continua sendo central”
Não tenho certeza se o CEO do GitHub realmente usou a palavra “manual”. Seria bom ter a fonte do artigo com um termo mais neutro ou preciso
Não é desejável rebaixar programação humana a “manual”. Desenvolvedores humanos também usam diversos kits de automação, não só IA
Pode ser tão negativo quanto “pensamento manual”
Não sabia dessa conotação negativa de “manual”
Fico curioso se hoje em dia existe tanta antipatia assim por trabalho manual
Fico me perguntando qual seria a diferença entre “manual coding” e “human coding”
“Depender só de agentes de IA pode ser ineficiente”
Por exemplo, muitas vezes editar o código diretamente é muito mais rápido do que explicar longamente uma mudança simples em linguagem natural
Portanto, uma interação ativa com agentes de IA provavelmente será o fluxo de trabalho ideal
Muitas vezes, enquanto penso na mudança em linguagem natural, antes mesmo de digitar já me ocorre na cabeça a alteração direta de que preciso
Quanto mais contexto uma mudança exige, mais parece que eu mesmo consigo corrigir mais rápido do que um agente
Fico curioso sobre quão ativa essa interação pode ser sem se tornar ruim
Entrei recentemente em uma startup de tooling para agentes, e discutimos muito esse tipo de coisa internamente
Acho aceitável ficar dando feedback contínuo ao agente do tipo “honestamente, você está indo mal nisso!”, mas imagino que em certo ponto isso possa ficar cansativo
Queria ouvir mais opiniões, imaginações de fluxo de trabalho ou feedback sobre isso
A IA ainda não chegou perto do que se esperava
Por exemplo, eu frequentemente sofro com referências erradas ou especificações incorretas. Acho que isso acontece porque a IA foi treinada com dados desatualizados e tem pouca capacidade de atualização em tempo real
As soluções atuais de LLM e GI tentam resolver todas as etapas (n-step) de uma vez, e isso acaba reduzindo a utilidade
Se resolvessem bem só da etapa 1 até a etapa i, já ajudariam muito mais os humanos
Ainda não vi a solução de IA totalmente modular que eu quero (por exemplo: refletir meu estilo no GitHub e resolver o problema x consultando apenas os recursos a, b e c)
E espero ver uma IA de programação que explore problemas sequencialmente, faça mais perguntas no meio do caminho e converse mais
Achei interessante ver um CEO expressando uma visão um pouco diferente sobre IA e programação
Em geral, CEOs e investidores costumam prever redução do papel dos desenvolvedores dizendo que “mais de 30% de todo o código é escrito por IA”, mas o diagnóstico aqui é que, na prática, os mesmos desenvolvedores apenas usam ferramentas para escrever código mais rápido
Também destaca que escrever código em si é apenas uma parte do trabalho de desenvolvimento de software