Nenhum desenvolvedor sério ainda espera que a IA faça seu trabalho magicamente por eles. Chegamos a um consenso mais pragmático, embora ainda um pouco desconfortável: AI é um ótimo estagiário, não um substituto para um desenvolvedor sênior. E, no entanto, se isto for verdade, o corolário também é verdadeiro: se a IA é o estagiário, isso faz com que você o gerente.
Infelizmente, a maioria dos desenvolvedores não são bons gerentes.
Vemos isso todos os dias na forma como os desenvolvedores interagem com ferramentas como Copiloto GitHubCursor ou Bate-papoGPT. Lançamos instruções vagas e incompletas como “tornar o botão azul” ou “consertar a conexão do banco de dados” e então ficamos surpresos quando a IA alucina uma biblioteca que não existe desde 2019 ou refatora um fluxo de autenticação crítico em uma vulnerabilidade de segurança aberta. Culpamos o modelo. Dizemos que ainda não é inteligente o suficiente.
Mas o problema geralmente não é a inteligência do modelo. O problema é a nossa falta de clareza. Para obter valor dessas ferramentas, não precisamos de melhores truques de engenharia imediatos. Precisamos de melhor especificações. Precisamos tratar a interação da IA menos como um feitiço e mais como um processo formal de delegação.
Precisamos ser melhores gestores, em outras palavras.
A habilidade que falta: Especificação
O gerente de engenharia do Google, Addy Osmani, publicou recentemente uma masterclass sobre esse tópico exato, intitulada simplesmente “Como escrever uma boa especificação para agentes de IA.” É um dos planos mais práticos que já vi para fazer bem o trabalho de gerente de IA e é uma grande extensão de alguns princípios básicos Eu expus recentemente.
Osmani não está tentando vender a você o futuro da ficção científica da codificação autônoma. Ele está tentando evitar que seu agente divague, esqueça ou se afogue no contexto. Seu ponto central é simples, mas profundo: lançar uma especificação massiva e monolítica em um agente geralmente falha porque as janelas de contexto e o orçamento de atenção do modelo atrapalham.
A solução é o que ele chama de “especificações inteligentes”. Eles são escritos para serem úteis ao agente, duráveis em todas as sessões e estruturados para que o modelo possa seguir o que é mais importante.
Esta é a habilidade que falta na maior parte do discurso “IA será 10x mais desenvolvedora”. A alavancagem não vem do modelo. A vantagem vem do ser humano que pode traduzir a intenção em restrições e depois traduzir o resultado em software program funcional. A IA generativa aumenta o valor de ser um engenheiro sênior. Isso não diminui.
Dos prompts ao gerenciamento de produtos
Se você já orientou um desenvolvedor júnior, já sabe como isso funciona. Você não diz simplesmente “Construir autenticação”. Você expõe todos os detalhes: “Use OAuth, ofereça suporte ao Google e GitHub, mantenha o estado da sessão no servidor, não mexa nos pagamentos, escreva testes de integração e documente os endpoints”. Você fornece exemplos. Você chama minas terrestres. Você insiste em uma pequena solicitação pull para poder verificar o trabalho deles.
Osmani está traduzindo essa mesma disciplina de gerenciamento em um fluxo de trabalho de agente. Ele sugere começar com uma visão de alto nível, deixar o modelo expandi-lo para uma especificação mais completa e, em seguida, editar essa especificação até que ela se torne a fonte compartilhada da verdade.
Essa abordagem “especificação em primeiro lugar” está rapidamente se tornando standard, passando de postagens de weblog para ferramentas. A equipe de IA do GitHub tem defendido desenvolvimento orientado por especificações e lançou o Spec Equipment para restringir o trabalho do agente por trás de uma especificação, um plano e tarefas. JetBrains apresenta o mesmo argumentosugerindo que você precisa revisar pontos de verificação antes que o agente comece a fazer alterações no código.
Até Birgitta Böckeler, da Thoughtworks, opinoufazendo uma pergunta incômoda que muitas equipes estão evitando silenciosamente. Ela observa que as demonstrações baseadas em especificações tendem a presumir que o desenvolvedor fará uma série de trabalhos de análise de requisitos, mesmo quando o problema não é claro ou é grande o suficiente para que os processos do produto e das partes interessadas normalmente dominem.
Tradução: se a sua organização já se esforça para comunicar os requisitos aos humanos, os agentes não irão salvá-lo. Eles ampliarão a confusão, apenas com uma taxa de token mais alta.
Um modelo de especificação que realmente funciona
Uma boa especificação de IA não é uma solicitação de comentários (RFC). É uma ferramenta que torna o desvio caro e a correção barata. A recomendação de Osmani é começar com um resumo conciso do produto, deixar o agente elaborar uma especificação mais detalhada e, em seguida, corrigi-la em uma referência viva que você possa reutilizar nas sessões. Isso é ótimo, mas o valor actual vem dos componentes específicos que você inclui. Com base no trabalho de Osmani e nas minhas próprias observações de equipes bem-sucedidas, uma especificação funcional de IA precisa incluir alguns elementos não negociáveis.
Primeiro, você precisa objetivos e não objetivos. Não basta escrever um parágrafo para o objetivo. Você deve listar o que está explicitamente fora do escopo. As não metas evitam reescritas acidentais e aumento de escopo “útil” onde a IA determine refatorar toda a sua estrutura CSS enquanto corrige um erro de digitação.
Em segundo lugar, você precisa contexto o modelo não inferirá. Isto inclui restrições de arquitetura, regras de domínio, requisitos de segurança e pontos de integração. Se for importante para a lógica de negócios, você precisa dizê-lo. A IA não consegue adivinhar seus limites de conformidade.
Terceiro, e talvez o mais importante, você precisa limites. Você precisa de listas explícitas de “não toque”. Essas são as proteções que impedem o estagiário de excluir a configuração do banco de dados de produção, comprometer segredos ou modificar diretórios de fornecedores legados que mantêm o sistema unido.
Finalmente, você precisa critérios de aceitação. O que significa “pronto”? Isso deve ser expresso em verificações: testes, invariantes e alguns casos extremos que tendem a ser perdidos. Se você está pensando que isso parece uma boa engenharia (ou mesmo um bom gerenciamento), você está certo. Isso é. Estamos redescobrindo a disciplina que vínhamos deixando passar, vestida com novas ferramentas.
O contexto é um produto, não um immediate
Um dos motivos pelos quais os desenvolvedores ficam frustrados com os agentes é que tratamos as solicitações como uma atividade única, e não é. Está mais perto de criar um ambiente de trabalho. Osmani ressalta que prompts grandes geralmente falham não apenas devido aos limites brutos de contexto, mas porque os modelos apresentam pior desempenho quando você acumula muitas instruções ao mesmo tempo. A Anthropic descreve essa mesma disciplina como “engenharia de contexto”. Você deve estruturar o histórico, as instruções, as restrições, as ferramentas e os resultados necessários para que o modelo possa seguir com segurança o que é mais importante.
Isso muda a descrição do trabalho do desenvolvedor para algo como “arquitetos de contexto”. O valor de um desenvolvedor não está em conhecer a sintaxe de uma chamada de API específica (a IA sabe disso melhor do que nós), mas sim em saber qual A chamada de API é relevante para o problema de negócios e garante que a IA também saiba disso.
É importante notar que a postagem de Ethan Mollick “Onboarding your AI estagiário” coloca isso em linguagem simples. Ele diz que é preciso aprender onde o estagiário é útil, onde é chato e onde não se deve delegar porque o índice de erros é muito caro. Essa é uma maneira elegante de dizer que você precisa de julgamento. Essa é outra maneira de dizer que você precisa de experiência.
A armadilha da propriedade do código
Há um perigo aqui, é claro. Se transferirmos a implementação para a IA e focarmos apenas nas especificações, corremos o risco de perder contato com a realidade do software program. Charity Majors, CTO da Honeycomb, foi soando o alarme sobre este risco específico. Ela distingue entre “autoria de código” e “propriedade de código”. A IA torna a autoria barata – quase zero. Mas a propriedade (a capacidade de depurar, manter e compreender o código em produção) está se tornando cara.
Majors argumenta que “quando você confia excessivamente em ferramentas de IA, quando você supervisiona em vez de fazer, sua própria experiência decai rapidamente”. Isto cria um paradoxo para o modelo “desenvolvedor como gestor”. Para escrever uma boa especificação, como aconselha Osmani, você precisa de um conhecimento técnico profundo. Se você gastar todo o seu tempo escrevendo especificações e deixando a IA escrever o código, poderá perder lentamente esse profundo conhecimento técnico. A solução é provavelmente uma abordagem híbrida.
O desenvolvedor Sankalp Shubham liga isso “dirigir em marchas mais baixas”. Shubham usa a analogia de um carro com transmissão handbook. Para tarefas simples e padronizadas, você pode mudar para uma marcha mais alta e deixar a IA agir rapidamente (alta automação, baixo controle). Mas para problemas novos e complexos, você precisa reduzir a marcha. Você mesmo pode escrever o pseudocódigo. Você pode escrever o algoritmo difícil manualmente e pedir à IA apenas para escrever os casos de teste.
Você continua sendo o motorista. A IA é o motor, não o motorista.
O futuro é orientado pelas especificações
A ironia nisso tudo é que muitos desenvolvedores escolheram sua carreira especificamente para evitar sendo gerentes. Eles gostam de código porque é determinístico. Os computadores fazem o que lhes é ordenado (principalmente). Os humanos (e, por extensão, os estagiários) são confusos, ambíguos e requerem orientação.
Agora, a principal ferramenta dos desenvolvedores tornou-se confusa e ambígua.
Para ter sucesso neste novo ambiente, os desenvolvedores precisam desenvolver habilidades sociais que são, na verdade, bastante difíceis. Você precisa aprender como articular uma visão com clareza. Você precisa aprender como dividir problemas complexos em tarefas modulares e isoladas que uma IA possa realizar sem perder o contexto. Os desenvolvedores que prosperarem nesta period não serão necessariamente aqueles que conseguem digitar mais rápido ou memorizar as bibliotecas mais padronizadas. Serão eles que poderão traduzir os requisitos de negócios em restrições técnicas de forma tão clara que mesmo um papagaio estocástico não conseguirá bagunçar tudo.