Na era em que a IA despeja código, quando a maré baixar ficará claro quem estava nadando nu
(evan-moon.github.io)Resumo principal
- Em apenas 3 anos desde o surgimento do ChatGPT, o dia a dia do desenvolvedor está migrando de "escrever código" para "revisar a saída da IA"
- O papel do desenvolvedor não está desaparecendo; o centro de gravidade está se deslocando de autor de código para revisor e aprovador
- A IA não é uma entidade legal e não pode assumir responsabilidade; regulamentações como o EU AI Act também estão se fortalecendo na direção de atribuir a responsabilidade aos humanos
- Na era da IA, a competência central exigida não é técnica de prompt, mas prever o custo de mudanças no longo prazo, julgar abstrações e explicitar conhecimento tácito — em essência, as mesmas qualidades que sempre definiram bons desenvolvedores
- Pela distinção de Fred Brooks entre complexidade acidental e complexidade essencial, o que a IA resolve é apenas a complexidade acidental; a complexidade essencial do domínio ainda exige julgamento humano
- A validade de habilidades ligadas à ferramenta (como prompt engineering) está presa ao ciclo de troca de ferramentas, enquanto a capacidade de decisão de projeto e de verbalizar conhecimento tácito continua valendo enquanto existir a complexidade essencial do software
Resumo detalhado
3 anos após o ChatGPT
- No fim de 2022, quando o ChatGPT apareceu, era difícil imaginar que ele evoluiria nessa velocidade
- A definição tradicional de desenvolvedor: alguém que fazia "análise de requisitos em linguagem natural → design → implementação direta"
- Hoje, uma parte considerável do dia é ocupada por "passar contexto para a IA → ler, corrigir e pedir novamente o código gerado"
- Os agentes de coding com IA já foram além do papel de simples assistentes e, no nível de funções e módulos, geram código difícil de distinguir daquele escrito por humanos
De autor para tomador de decisão
- A atividade de produzir código está migrando de "escrever código diretamente" para "julgar o código"
- "Julgar" aqui não significa apenas verificar se a saída da IA corresponde ao esperado, mas validar se a intenção de negócio foi corretamente traduzida em implementação técnica
- A pergunta central é: "Quando um bug de pagamento surge em um código escrito por IA, quem é responsável?"
- Como a IA não é uma pessoa jurídica, os responsáveis são o desenvolvedor e a organização que revisaram e aprovaram o código
- EU AI Act, em vigor desde 2024: obriga supervisão humana de sistemas de IA em áreas de alto risco, como saúde, finanças e infraestrutura
- Responsabilidade em acidentes com carros autônomos → fabricante e motorista; IA médica aprovada pela FDA → a decisão final é do médico; Flash Crash de 2010 → quem opera o algoritmo é o alvo da regulação
- Quanto mais avançada a automação, a estrutura de responsabilidade não fica mais difusa; ao contrário, tende a ser atribuída de forma ainda mais clara aos humanos
Competências exigidas do desenvolvedor na era da IA
① Capacidade de prever o custo de mudanças no longo prazo
- A IA é otimizada para criar "código que funciona" (reproduzindo os padrões mais frequentes do conjunto de treinamento)
- Código que funciona agora e código fácil de manter daqui a 6 meses são avaliados por critérios completamente diferentes
- O custo de um design ruim não aparece quando o código é escrito, mas quando ele precisa ser alterado
- No LinkedIn, vêm aumentando relatos como "fizemos com IA, mas a manutenção ficou difícil e tivemos de contratar desenvolvedores" e "não conseguimos evoluir a funcionalidade e acabamos desistindo"
② Capacidade de avaliar código por vários ângulos
- É preciso considerar simultaneamente qualidade estrutural, implicações de desempenho e aspectos de segurança, além da correção funcional (que pode ser verificada com testes)
- Quanto mais rápida fica a geração de código por IA, mais facilmente se rompe o equilíbrio entre velocidade de produção e capacidade de revisão
- Quando humanos escreviam tudo diretamente, havia um limite físico para o volume de código produzido; a IA gera centenas de linhas em segundos
- Se critérios de revisão, sistemas de revisão paralela e gates automatizados forem insuficientes, a dívida técnica se acumula ainda mais rápido
- Muitas empresas não percebem aumento de produtividade após adotar IA porque a produção de código acelerou, mas a revisão do código gerado pela IA virou o gargalo
③ Capacidade de abstração
- A IA também consegue definir interfaces, separar classes e modularizar, e faz isso bem do ponto de vista formal
- A diferença decisiva: a abstração da IA se baseia em médias estatísticas; a abstração de um desenvolvedor experiente se baseia em julgamentos de trade-off diante de recursos limitados e de um futuro incerto
- O aspecto perigoso do código gerado por IA é que, à primeira vista, ele parece bom — os arquivos estão razoavelmente separados, os nomes seguem convenções e os padrões são familiares
- O problema aparece quando mudanças se tornam necessárias: "Só queríamos adicionar mais um meio de pagamento e só então percebemos que seria preciso mexer simultaneamente em várias partes daquela estrutura que parecia tão limpa"
- Exemplo de frontend: a IA pode concentrar data fetching, gerenciamento de estado e renderização de UI em um único componente gigante ou, no extremo oposto, criar 3 custom hooks + um context provider para um gráfico simples
④ Capacidade de tornar explícito o conhecimento tácito
- Para dar instruções precisas à IA, é preciso transformar a intuição de "tem algo estranho aqui" em uma linguagem concreta como "esta função tem duas responsabilidades"
- Não se trata de técnicas formais de prompt como few-shot ou chain-of-thought, mas da capacidade de definir com clareza o que deve ser construído, decidir qual contexto é importante e transmiti-lo
- Vida útil da proficiência em ferramentas: presa ao ciclo de substituição das ferramentas (
jQuery → React,Webpack → Vite) - Vida útil da capacidade de decisão de design e de verbalizar conhecimento tácito: continua válida enquanto existir a complexidade essencial do software
A necessidade de projetar uma prática deliberada
- Diz-se para "focar no que a ferramenta não consegue fazer", mas vivemos a situação paradoxal de ter cada vez menos oportunidades de desenvolver justamente isso
① Dois pontos que não devem ser delegados à IA: design e review
- Design antes da escrita do código: se você definir primeiro as interfaces e os limites de responsabilidade antes de digitar o prompt, poderá comparar a saída da IA com sua própria decisão de design
- O hábito de deixar a IA fazer o review de PR e aprovar logo em seguida se ela não apontar problemas = "ir para a quadra na aula de educação física, ficar sentado no banco o tempo todo e depois voltar para a sala"
② Tempo para codar diretamente de forma intencional
- A sensibilidade de design só surge quando se conhece a dor da implementação. Uma dor que nunca foi vivida não vira sensibilidade
- Para um desenvolvedor júnior, revisar código gerado por IA é "como pedir a alguém que ainda está aprendendo a dirigir para avaliar as decisões de um carro autônomo"
- A capacidade de coding no futuro não será algo usado apenas no trabalho diário, mas um treinamento para manter o discernimento (o processo de obter uma licença de revisor)
③ Praticar a verbalização do "porquê"
- Se você para em "está estranho", isso é só intuição; se chega a "esta função tem duas responsabilidades", isso vira linguagem
- Mesmo que o código criado pela IA funcione, não parar aí e cultivar o hábito de se perguntar: "Por que essa estrutura foi escolhida?" e "Se fosse outra estrutura, quais seriam os trade-offs?"
No fim, a essência não mudou
- Fred Brooks (1986): complexidade acidental (limitações das ferramentas) vs complexidade essencial (inerente ao próprio problema)
- O que a IA resolve é a complexidade acidental — boilerplate, padrões repetitivos, erros de sintaxe
- A complexidade essencial (ambiguidade nos requisitos de negócio, equilíbrio entre objetivos de design conflitantes, incerteza sobre mudanças futuras) não desaparece, mesmo com o avanço da IA
- Enquanto os humanos continuarem sendo os agentes do julgamento e da responsabilidade, a essência das capacidades necessárias para julgar não mudará
- Quanto mais automatizada a produção de código, mais se destacará o peso da capacidade de julgamento para inspecionar o que foi produzido
14 comentários
Agradeço pelos bons comentários!
O fato de eu ter mencionado "responsabilidade" no texto não é porque os humanos cometem menos erros do que a IA em todos os aspectos, mas porque os sistemas jurídicos e éticos da sociedade moderna pressupõem apenas humanos (ou pessoas jurídicas) como "agentes responsáveis".
Como o gcback disse, se a segurança estatística for comprovada, no futuro o próprio sistema de responsabilização pode mudar; porém, pelo menos no curto prazo, entendo que será difícil para o dilema social de "quem irá para a cadeia ou pagará indenização por um acidente causado pela IA" acompanhar a velocidade da tecnologia..!
Concordo. Foi uma ótima leitura.
Será que a maré está mesmo baixando, ou será que está subindo? “As competências exigidas dos desenvolvedores na era da IA”, bem, sei lá... isso se os desenvolvedores continuarem existindo.
Do ponto de vista de quem usa IA no trabalho real, essa ideia de que o desenvolvimento com IA leva a supervisionar os resultados da IA é algo com que eu realmente me identifico.
E a IA também está ajudando muito a resolver a complexidade essencial. [na análise de requisitos, checagem de contradições, checagem de redundâncias, questionamentos sobre o valor essencial]
Precisamos que haja mais pessoas que confiem cegamente na IA.
Qual seria o motivo?
Acho que isso também deve ser uma fase de transição.
Mesmo entre treinadores de futebol famosos, muitos não foram ex-jogadores.
Acho que ele ficou famoso não por ter sido um eleito, e sim porque tinha uma compreensão excepcional.
Mas como estamos falando de futebol, isso me faz lembrar de Chung Mong-gyu.
Isso porque ele tem as qualificações necessárias para ser técnico de futebol mesmo sem ter sido jogador profissional, e quem assume o cargo de técnico é alguém capaz de se responsabilizar pelo resultado da partida.
Isso mesmo, também existem técnicos que não foram jogadores.
Mas esses técnicos, ao que parece, não se destacam por não terem sido jogadores... e sim porque, mesmo sem esse passado, possuem uma percepção superior à de muitos jogadores. Nesse campo, dá para dizer que são praticamente "super-humanos".
Eu também concordo.
Recentemente, vendo abordagens de harness ou loop, parece que estamos indo na direção em que a pessoa só fornece a spec, e até revisão ou QA ficam por conta da própria IA entre si.
Concordo.
No fim, como o nível de revisão e verificação inevitavelmente também pode se tornar superior no caso da IA em comparação com os humanos, parece inevitável que o custo acabe ficando menor do que o custo atual de responsabilizar pessoas.
Seja humano ou IA, é um jogo em que vence o lado que, estatisticamente, comete menos erros.
Democratização da direção? kkk Quem dirige é porque tem qualificação; não é para alguém sem qualificação dirigir também.