Contrate o revisor antes do programador: montar a equipa de engenharia de uma startup quando os agentes escrevem o código (2026)

31 de julho de 2026
11 min read

31 de julho de 2026
11 min read
Há uma discussão no LinkedIn que não se vai resolver, e outra mais discreta no Reddit que já se resolveu. A do LinkedIn é sobre se a IA acabou com os empregos de engenharia de entrada — de um lado, o CEO da AWS, Matt Garman, a chamar à ideia de substituir juniores por IA «uma das coisas mais estúpidas que já ouvi», e do outro um muro de dados de recrutamento que mostra uma forte queda das ofertas de entrada. A do Reddit, em tópicos como os do r/ExperiencedDevs, é menos filosófica: séniores a descrever dias que se tornaram uma fila ininterrupta de pull requests para rever, e um memorando da Indeed a dizer que já não se espera que os engenheiros séniores sejam mentores de ninguém abaixo do seu nível.
Para um fundador prestes a fazer as suas três primeiras contratações de engenharia, as duas discussões têm a forma errada. A pergunta útil não é se a IA está a destruir os empregos júnior em termos agregados. É esta: dado que os agentes escrevem agora uma grande parte do seu código, o que está de facto a limitar a velocidade a que o seu produto sai — e quem precisa de contratar para o desbloquear? Os dados sobre isto são invulgarmente claros, e apontam para um sítio que a maioria dos fundadores não espera.
Os dados da CircleCI de 2026 contêm um resultado que devia estar afixado por cima da secretária de todos os fundadores: o débito dos ramos de funcionalidades subiu 59% em termos homólogos, enquanto o débito do ramo main da equipa mediana caiu. Escreve-se mais código do que nunca. Em proporção, chega menos à produção.
Os números por programador explicam o mecanismo. Os engenheiros que usavam IA concluíram mais 21% de tarefas e integraram mais 98% de pull requests — cerca do dobro do output —, mas o tempo de revisão das PR aumentou 91%. As PR geradas com IA esperam 4,6 vezes mais até um revisor sequer pegar nelas. Quando a revisão começa, termina cerca de duas vezes mais depressa, o que parece animador até se reparar no que implica: rever não é a parte lenta. A fila é. O tempo de ciclo quase não melhora, porque o trabalho fica à espera de uma pessoa com contexto e autoridade suficientes para dizer que sim.
É isto que as pessoas querem dizer quando afirmam que o gargalo se deslocou. Escrever código foi a restrição durante toda a história do software. Já não é. A restrição é decidir se o código pode ser integrado com segurança — e essa decisão não se distribui de forma igual por uma equipa. É, no entanto, ensinável: avaliar o output da IA, e saber que modos de falha procurar, é a maior parte do que a nossa formação para equipas de engenharia aborda.
Porque é que as startups são as mais atingidas
Uma grande empresa absorve uma acumulação de revisões dentro das camadas que já tem. Uma startup de quatro pessoas tem exatamente uma ou duas capazes de aprovar com critério uma alteração ao sistema central. Compre-lhes mais capacidade de agentes e não aumentou a velocidade de lançamento — tornou a fila deles mais comprida.
A razão de este gargalo ser tão persistente é que rever bem o output dos agentes exige exatamente aquilo que os agentes não fornecem: saber o que devia ter sido construído. Um engenheiro sénior que revê uma PR de 400 linhas com ar plausível não está a verificar a sintaxe. Está a perguntar se esta é a abstração certa, se duplica algo que já existe, se aguenta carga, se o caminho de erro é real e se parte em silêncio um pressuposto a três serviços de distância. Isso é contexto, e o contexto acumula-se; não se contrata de um dia para o outro.
É por isso que a queixa do Reddit é mais informativa do que o debate do LinkedIn. Os séniores contam que agora passam mais tempo a rever do que a desenhar — que o trabalho que antes passava por várias camadas da organização se está a concentrar nas poucas pessoas qualificadas para o avaliar. Isso não é uma queixa sobre carga de trabalho. É a descrição de um sistema cujo débito está limitado pelo seu recurso mais escasso, e em que cada ganho de eficiência a montante faz esse limite apertar mais.
A conclusão óbvia — formar a equipa só com séniores e deixar os agentes fazer o que os juniores faziam — é aquela a que muitos fundadores chegaram em 2025, e falha de duas formas concretas.
A primeira é aritmética. Os engenheiros séniores são a capacidade de revisão. Se toda a equipa estiver a gerar output com agentes a um volume duplicado e as mesmas pessoas forem as únicas que o podem aprovar, construiu um sistema em que cada nova contratação soma aos dois lados da equação. A partir de certo ponto, acrescentar mais um sénior produtor a uma equipa pequena piora a fila em vez de a melhorar. É por isso que a orientação mais útil a circular agora entre líderes de engenharia é enganadoramente simples: contrate o revisor antes do programador. A sua próxima contratação deve ser escolhida por conseguir absorver carga de revisão, e não por conseguir produzir mais trabalho que precisa de ser revisto.
A segunda falha é aquela para que Garman estava de facto a apontar, e vale a pena citá-lo bem, porque a frase curta perde-a. Os juniores, notou ele, são «provavelmente os funcionários mais baratos que tem, os que mais aderiram às suas ferramentas de IA» — e depois o verdadeiro argumento: «Como é que isso vai funcionar quando, daqui a dez anos, não tiver ninguém que tenha aprendido alguma coisa?» Os séniores não são um recurso renovável que se compra quando é preciso. São juniores a quem foram dados problemas difíceis e alguém para verificar o seu trabalho. Uma empresa que congela a contratação de entrada está a adiar um custo, não a evitá-lo, e o mercado em que vai comprar talento intermédio daqui a alguns anos será um mercado que todos os outros também deixaram à fome.
A prova mais sólida do argumento do LinkedIn é um estudo de Harvard dos economistas Seyed Hosseini e Guy Lichtinger que abrange cerca de 285 000 empresas norte-americanas e mais de 60 milhões de trabalhadores entre 2015 e 2025. Concluiu que, depois de as empresas adotarem a IA generativa, o emprego júnior cai cerca de 9–10% em seis trimestres, enquanto o emprego sénior fica praticamente estável. Chamam-lhe mudança tecnológica enviesada pela antiguidade, e o mecanismo é intuitivo: a IA generativa é boa no trabalho rotineiro e bem especificado em torno do qual os cargos de entrada foram construídos.
Mas o contra-argumento honesto merece espaço, porque os fundadores que fazem planos de contratação não devem atribuir de mais. O colapso da entrada começou em 2022, meses depois de a Fed subir as taxas de quase zero para 5,25%, e bem antes de a IA estar de forma significativa na maioria dos fluxos de trabalho. As correções do excesso de contratação pós-pandemia e os simples cortes de custos explicam grande parte do que aconteceu; a IA só acrescentou pressão real a partir do final de 2024. «Substituímo-los por IA» é, para várias empresas, uma história mais lisonjeira do que «contratámos de mais e as taxas subiram».
As duas coisas são verdade, e é a combinação que lhe interessa: o colapso macro não se deveu sobretudo à IA, e o efeito enviesado pela antiguidade que se junta por cima é real e mensurável. Na prática, isso significa que o talento júnior em 2026 está ao mesmo tempo mais disponível e mais subvalorizado do que em qualquer momento da última década — enquanto a competência específica de que mais precisa é a que ficou mais escassa. É uma oportunidade de contratação, não uma razão para congelar.
O retrato empírico das equipas que lançam depressa em 2026 é mais pequeno do que os fundadores esperam. A liderança de engenharia da OpenAI apontou grupos de três ou quatro pessoas com forte colaboração como a unidade que avança mais depressa; o Sora foi lançado em 28 dias com quatro pessoas. As equipas pequenas ganham aqui em parte por causa da restrição da revisão — menos passagens de testemunho, mais contexto partilhado, e um revisor que já percebe a alteração antes de a abrir.
A orientação sobre composição que daí decorre é coerente: a equipa nativa de IA tem mais peso sénior, mas não congela a contratação de entrada. E as provas sobre qualidade apontam no mesmo sentido — a McKinsey concluiu que as organizações com melhor desempenho combinaram a IA com engenheiros séniores para obter melhorias de 31–45% na qualidade do software, em vez de usarem a IA como substituta da experiência. A alavancagem veio de juntar a ferramenta ao discernimento, não de substituir o discernimento pela ferramenta.
O fio condutor é que a IA mudou qual é o recurso escasso, e a maioria dos planos de contratação ainda não acompanhou. Durante trinta anos, a resposta a «temos de lançar mais depressa» foi mais pessoas a escrever código. Essa resposta está agora errada de uma forma concreta e mensurável: pode duplicar o código e ver menos dele chegar à produção.
Os fundadores que acertarem na segunda metade de 2026 vão parecer um pouco fora de moda — equipas pequenas, com peso sénior, ainda a contratar juniores enquanto toda a gente no LinkedIn explica porque é que ninguém precisa deles. Serão também aqueles cujo ramo main continua a avançar. Contrate para a restrição que tem de facto, não para a que tinha em 2021.


IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.