Uma auditoria que fiz no front-end do meu próprio produto encontrou quatro listas editáveis que rastreavam as linhas pela posição, sobre arrays alterados in place. Compilava, e nada no build reclamava. Remover uma linha do meio fazia o framework reaproveitar o nó do DOM da linha removida para o próximo item, então o estado de input e de foco de cada linha podia ficar preso na linha errada até um re-render completo. Uma revisão focada em estilo aprovaria esse diff. Corrigi as quatro e adicionei um spec que fixa o comportamento. Pegar esse tipo de bug é uma parte maior do trabalho agora.
A Netguru escreve que o trabalho de front-end sênior em 2026 se parece menos com escrever componentes e mais com dirigir um sistema que os escreve. A primeira parte bate com o que vejo: produzir um componente não é mais onde está o valor. O resto eu descreveria de outro jeito. Dirigir soa como gestão, e o trabalho parece mais ler, decidir e tornar difícil fazer a coisa errada.
Eu construo meu próprio produto, o MailHive, com Angular 21 e um workflow assistido por IA, e até agosto eu era o único desenvolvedor front-end num time de cinco desenvolvedores no BMO. Nos dois casos, o componente nunca foi a parte difícil. A IA só removeu o disfarce que o trabalho de digitá-lo costumava oferecer.
Leia o Comportamento, Porque Estilo Deixou de Ser Evidência
Código gerado parece limpo. Bons nomes, estrutura organizada, comentários nos lugares certos. Isso costumava ser um sinal fraco de que o autor tinha pensado no assunto. Agora é uma evidência bem mais fraca. Você precisa ler o que o código faz quando o estado muda.
Se foi uma pessoa ou um modelo que as digitou não faz diferença para o revisor. A armadilha é a mesma nos dois frameworks com que trabalho:
<!-- Angular. Position is not identity when the list mutates. -->
@for (condition of conditions; track $index) { ... }
<!-- Follows the object while its reference is stable. Prefer condition.id if you have one. -->
@for (condition of conditions; track condition) { ... }{/* React. Same trap. */}
{rows.map((row, i) => <Row key={i} {...row} />)}
{/* Follows the item. */}
{rows.map(row => <Row key={row.id} {...row} />)}Um conceito como esse viaja entre Angular e React. Uma lista de nomes de ferramentas, não.
Assuma os Estados Que Ninguém Pediu
Peça uma tela e você recebe a tela. Recebe o caminho feliz, bem renderizado. O trabalho sênior é a lista que o prompt não mencionou: a conta vazia, a rede lenta, o salvamento que falhou com metade do formulário alterada, a permissão revogada no meio da sessão, o leitor de tela, o label em francês muito mais longo que o em inglês. Se você já trabalhou do Figma até produção, sabe que essa lista é a maior parte do trabalho real.
Minha formação em UX ajuda aqui. Esses estados são uma decisão de produto antes de serem código. O que o usuário deve ver quando isso falha, e ele consegue se recuperar? Um modelo vai inventar uma resposta de bom grado. Alguém precisa perceber que aquilo era uma decisão, e levá-la para a pessoa que é dona dela.
Transforme Seu Gosto em Restrições
Revisar o mesmo erro duas vezes é sinal de que a verificação deveria ser automatizada. Na primeira vez que você o vir, pergunte se uma máquina consegue pegá-lo dali em diante. Aqui está parte do que vive no repositório do MailHive agora, vários itens vindos de uma auditoria do repositório e não de um único bug:
- Regras de lint que impõem fronteiras de módulos, para que um novo import de uma feature em outra falhe, com as violações existentes na baseline.
- Regras de acessibilidade de template em todos os nossos templates, com as violações existentes na baseline para que só as novas falhem.
- Uma verificação de que os quatro arquivos de idioma têm as mesmas chaves, para que uma chave de tradução faltando quebre o pipeline e não o usuário.
- Instruções de projeto que a IA lê, mais um registro de bugs passados que ela não pode repetir, em que cada entrada precisa referenciar um incidente real.
- Registros de decisão que explicam por que uma escolha de arquitetura foi feita, para que nem eu nem um modelo a reabra por acidente.
Cada um torna as próximas mil linhas geradas um pouco mais seguras. A pesquisa DORA do Google chama a IA de amplificador das forças e fraquezas que uma organização já tem. Na escala de um repositório, as restrições são o que é amplificado, ou a falta delas.
Diga Não Cedo, Porque Código É Fácil Demais de Adicionar
Quando adicionar código custa quase nada, a tentação é adicionar. Toda abstração, helper e service gerado ainda vai precisar ser lido, testado e migrado por alguém depois. Apagar código e se recusar a gerá-lo contam, os dois, como trabalho. O MailHive tem um job de CI, o knip, que falha com código de front-end não utilizado, porque o volume sozinho enterra um produto pequeno.
Com grandes reescritas é igual. Um modelo vai planejar e rascunhar uma de bom grado, e não vai estar lá para explicar a regressão ao cliente. Alguém precisa pesar o risco contra o que o negócio ganha, e dizer em voz alta quando a resposta é não.
Mantenha a Habilidade Que Permite Julgar
É por isso que dirigir não descreve o trabalho, para mim. Você só consegue julgar um achado como aquelas quatro listas porque entende como um framework reconcilia uma lista. Você julga código gerado com um conhecimento que veio de escrever e depurar código. Se você para de construir esse conhecimento, suas revisões ficam mais fracas, devagar, e nada te avisa.
Não tenho uma resposta limpa para esse risco, principalmente para quem está mais no começo da carreira. O Digital Economy Lab de Stanford encontra o emprego de pessoas de 22 a 25 anos em funções muito expostas cerca de 19% abaixo de onde estaria se tivesse acompanhado o ritmo de colegas menos expostos, sem uma lacuna comparável para profissionais experientes. Os autores chamam isso de descritivo, não causal. Ainda assim me preocupa, porque os juniores de hoje são de onde vêm os próximos seniores. O que eu tento fazer: ir fundo de propósito nas áreas pelas quais respondo. Escrever eu mesmo a parte difícil quando preciso entendê-la. Tratar uma explicação da IA como uma hipótese inicial, e depois ler a documentação do framework e o teste que está falhando.
O Que Mostrar numa Entrevista
Um post do blog do Stack Overflow de outubro de 2026 dá aos empregadores uma frase que vale guardar: contrate pelo julgamento, não por uma lista de ferramentas. Fluência em ferramentas importa, mas é a parte mais fácil de mostrar, e a maioria dos candidatos lista Copilot ou Claude Code hoje. Estas são as histórias que eu prepararia no lugar, com um exemplo real para cada uma:
- Uma vez em que você pegou algo que parecia certo e estava errado. O que entregou o problema?
- Um guardrail que você adicionou depois de um erro, e o que ele pegou desde então.
- Um estado ou fluxo que ninguém especificou, e como você conseguiu que a decisão fosse tomada.
- Algo que você decidiu não construir, e o que isso poupou.
- Como você decide qual resultado da IA recebe uma leitura atenta e qual recebe uma leitura rápida.
Cada uma delas é uma história sobre julgamento, e julgamento é o que o cargo pede agora.
Referências
- Netguru. Is frontend development dying? https://www.netguru.com/blog/is-frontend-development-dying
- Stack Overflow Blog. Is AI really reshaping the developer market? October 2026. https://stackoverflow.blog/2026/10/22/is-ai-really-reshaping-the-developer-market/
- Brynjolfsson, Chandar, Chen. Canaries in the Coal Mine, Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/
- DORA. 2025 State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/
- Angular. Track expressions in @for blocks. https://angular.dev/guide/templates/control-flow
- React. Why React needs keys. https://react.dev/learn/rendering-lists
- knip. https://knip.dev/