Full-Stack Engineer

Você entrega features de ponta a ponta. O agente escreve o código; você arquiteta, especifica, valida e responde pelo resultado. Você se move rápido por todo o stack porque o agente não tem preferências de stack, e você parou de tê-las também.

Elevationprimary Convergencesecondary Emergencepartial

Família

Engenharia

Função legada equivalente

Full-Stack Engineer, Senior Software Engineer, Staff Engineer (carreira IC)

Reporta a

Tech Lead, Engineering Manager ou Director of Engineering

Trabalha com

Tech Lead · Product Designer · Product Manager · Agent Supervisor

O trabalho

Você entrega features. Ponta a ponta significa ponta a ponta: camada de dados, API, frontend, testes, deploy, observabilidade. Não porque você faz tudo pessoalmente, mas porque você responde pelo resultado e o agente cuida da camada que o trabalho exigir.

No dia a dia, você:

Especifica features de forma completa. Critérios de aceitação, edge cases, implicações de dados, comportamento de UX, classificação de risco, gates de validação. A especificação é o artefato que permite ao agente executar sem supervisão em tempo real.
Conduz diálogos de esclarecimento com o agente antes da execução. Responde as perguntas que resolvem ambiguidade genuína, adia as que devem ser respondidas durante a implementação e rejeita as que sinalizam uma spec vaga.
Arquiteta no nível da feature. Decisões de modelo de dados, formato de API, fronteiras de componente, escolha de dependências: suas, para tomar; do agente, para implementar.
Revisa PRs produzidos pelo agente. No T2, linha por linha. No T3, no nível de diff e comportamento. Você procura o caso faltante, a abstração errada, a quebra silenciosa, não erros de digitação.
Valida em gates graduados por risco. Amostragem para mudanças reversíveis. Aprovação direta para as irreversíveis. Você desenha os gates das suas features ao especificá-las.
Recalibra quando histórias travam. Implementações erradas geralmente são sintoma de spec errada ou contexto errado. Você diagnostica, re-especifica e retoma, em vez de debugar o output do agente.
Mantém o contexto da base de código. Templates de prompt compartilhados, arquivos de contexto, guias de estilo da casa, bibliotecas de cenário. São artefatos de primeira classe; você contribui com eles e os usa.
Responde pela observabilidade do que entrega. Telemetria, alertas, error budgets. Você desenha tudo isso na spec; o agente implementa; você verifica se o sinal é real.
Faz par com engenheiros adjacentes em decisões entre stacks. O agente absorve grande parte do que antes exigia handoffs entre especialistas, mas o julgamento humano ainda é melhor em pares.

Como é o sucesso

Resultados concretos neste nível:

Throughput. Você entrega features em dias, não sprints. Histórias completam (spec → implementar → revisar → merge) em horas ou dias para trabalho típico.
Qualidade. Defeitos em produção a partir das suas features são raros e em queda. O agente revisor captura o que você capturaria manualmente; suas intervenções capturam o resto.
Disciplina de custo. Gasto de tokens por PR mesclado é acompanhado. Custo por resultado melhora ao longo do tempo, não só throughput absoluto.
Trabalho entre stacks. Você entrega features que tocam frontend, backend e infraestrutura na mesma semana. O agente cuida da camada que for; você cuida do julgamento.
Saúde da base de código. Refatoração acontece, dívida técnica é paga, a base envelhece bem em vez de ossificar.

O que não conta como sucesso: linhas de código entregues, contagem de PRs, horas registradas, pontos de velocidade que não se traduzem em resultados de usuário.

O que torna esse trabalho interessante

A parte interessante não é a velocidade: é o que se torna possível nessa velocidade.

Você entrega mais rápido do que achava possível. O que antes levava um sprint leva um dia. A feature que você especificou terça de manhã está em produção quarta à tarde. O ciclo de feedback com o usuário fecha dentro da semana, e você sente isso.

Full-stack vira natural. Você para de ter preferência de stack porque o agente não tem. Você se move com fluidez entre decisões de modelo de dados, design de API e comportamento de UX porque a fricção do context-switch entre camadas caiu para perto de zero. A recompensa é uma amplitude genuína de escopo.

Você desenha mais, digita menos. A maior parte do seu ofício agora vive em especificação e decisões arquiteturais, não na digitação. Para engenheiros que entraram no ramo porque amavam mais a parte de desenho do que a parte de digitação, isso é um retorno ao que era divertido.

Os problemas difíceis são os satisfatórios. Ligar mais um endpoint CRUD leva minutos. Os problemas que sobram são os que precisam de julgamento: acertar uma máquina de estados, escolher a fronteira entre dois domínios, decidir o que testar e o que confiar. Esses são os problemas que distinguem engenharia sênior de engenharia júnior e são o grosso do que sobra.

Você colabora com outro agente, não só com outros humanos. Trabalhar com um agente competente é um ofício próprio, diferente de pair programming, diferente de trabalho solo. Os diálogos de esclarecimento são interessantes em si. As sessões de recalibração são interessantes em si.

Você vê seu trabalho no mundo rapidamente. Features em produção horas depois da especificação significam que seu senso de agência no papel é mais forte do que tem sido para a maioria dos engenheiros sêniores em anos. O lag entre pensamento e impacto comprimiu.

O que pode não agradar. Você escreve menos código à mão. O flow state de horas de codificação concentrada acontece menos, e quando acontece, tende a ser em lugares incomuns (sessões de recalibração, trabalho de infraestrutura que o agente ainda não faz bem). As fronteiras entre "seu trabalho" e o do agente se diluem. Se sua identidade profissional está enraizada em produzir o artefato pessoalmente, essa identidade vai ter de migrar. Alguns engenheiros encontram uma versão mais profunda da satisfação no novo trabalho; outros não. Seja honesto consigo mesmo sobre que tipo de engenheiro você é.

Quem prospera nesse papel

As aptidões que mais importam no T3 são diferentes das que definiam engenharia sênior pré-IA.

Você pensa antes de digitar. Velocidade de digitação parou de importar; qualidade de pensamento prévio importa muito. Você pausa para considerar edge cases antes de especificar; não encaixa padrões e mergulha.

Você escreve com clareza. Especificações são, primeiro, escrita; depois, código. Pessoas cujo raciocínio escrito é confuso escrevem specs confusas e obtêm outputs confusos.

Você se sente confortável respondendo por resultados que não produziu pessoalmente. O agente escreveu o código; você assinou; se falhar, você responde. Pessoas que sustentam essa accountability sem microgerenciar o agente prosperam.

Você lida bem com diagnóstico bagunçado. Quando uma história trava, a causa geralmente está na spec ou no contexto, não no código. O trabalho detetivesco, descobrir qual hipótese quebrou, faz parte do ofício agora. Pessoas que gostam disso acham o trabalho rico; pessoas que querem problemas limpos com respostas limpas têm dificuldade.

Você tem gosto. Quando o agente produz três implementações plausíveis, você sabe qual é a certa para esta base. Gosto é difícil de avaliar em entrevista e mais difícil de ensinar, mas é a vantagem mais durável no T3.

Você se importa com sistemas, não só com features. Features são entregues sem parar. Os engenheiros que prosperam ao longo do tempo são os que prestam atenção em como a base de código envelhece, que padrões recorrem, o que a próxima decisão arquitetural precisa antecipar.

Menos essencial do que antes: velocidade bruta de codificação, trivia de algoritmos, pedantismo de linguagem, capacidade de manter cinco arquivos na cabeça. Esses eram os marcadores de engenharia sênior pré-IA. Ainda ajudam. Mas não são mais o que diferencia o papel.

Habilidades para desenvolver

As aptidões descrevem disposição. As habilidades abaixo são o que você constrói ativamente.

Engenharia de especificação. Escrever specs que um agente consegue executar de ponta a ponta. Critérios de aceitação, edge cases, classificação de risco, gates de validação. Como praticar: escreva a spec antes de qualquer código, mesmo para tarefas pequenas. Releia suas specs um mês depois; as que envelheceram mal são seu material de aprendizado. Veja o Guia de especificação.

Julgamento de revisão no diff. Ler output do agente para detectar o caso faltante, a abstração errada, a quebra silenciosa, sem ler cada linha. Como praticar: revise PRs gerados por IA do seu time. Articule por que você questionaria. Acompanhe os questionamentos que se mostraram errados; é aí que seu julgamento está descalibrado.

Diagnóstico de recalibração vs. debug. Quando o trabalho trava, saber se o problema está na spec, no contexto ou na implementação. Como praticar: mantenha um diário curto das histórias travadas. Classifique cada post-mortem como recalibração (problema de spec/contexto) ou debug (problema de implementação). Acompanhe quais intervenções de fato destravaram.

Classificação de risco. Distinguir trabalho reversível do irreversível e atribuir o gate de validação certo. Como praticar: para cada história que você especifica, nomeie os gates explicitamente. Justifique. Ajuste à medida que aprende com classificações erradas. Veja Padrões de execução de IA.

Julgamento entre stacks. Tomar boas decisões fora da sua especialidade histórica. Convergência no T3 significa que um engenheiro sênior com background backend agora pode responder por features voltadas ao usuário de ponta a ponta. Como praticar: leia PRs em áreas adjacentes (frontend, infra, dados). Note o que acha confuso: a lacuna é sua superfície de aprendizado. Faça parceria com a pessoa cuja especialidade era essa.

Ofício do diálogo de esclarecimento. Q&A produtiva com o agente antes da execução. Saber quais perguntas responder por completo, quais adiar, quais sinalizam uma spec confusa. Como praticar: preste atenção nas perguntas que um agente faz antes de implementar. Categorize-as. A categorização vai mostrar onde suas specs precisam de trabalho.

Curadoria de contexto. Manter os templates de prompt compartilhados, arquivos de contexto e bibliotecas de cenário de que os agentes do time bebem. Como praticar: contribua com uma melhoria por sprint. Os artefatos compõem; contribuições pequenas importam.

Escolha uma habilidade, pratique-a por duas semanas em trabalho real e perceba como sua relação com o papel muda. Tentar desenvolver as sete ao mesmo tempo é o modo de falha mais comum.

Como isso difere do papel histórico de engenheiro sênior

Engenheiro sênior histórico (pré-IA)	Engenheiro sênior (nativo em IA)
Escreve código complexo pessoalmente; revisa o dos outros	Escreve especificações; revisa output do agente em gates graduados por risco
Especializa-se em frontend, backend ou infraestrutura	Opera em todo o stack porque o agente o faz
Passa 50-70% do tempo codificando	Passa menos de 20% do tempo codificando
Throughput limitado pelas horas individuais de foco	Throughput limitado pela qualidade da spec e pelo julgamento de revisão
Handoffs para especialistas em trabalho entre stacks	Faz par com especialistas em julgamento, entrega entre stacks sozinho
Os melhores engenheiros são os produtores mais rápidos e prolíficos	Os melhores engenheiros são os especificadores mais claros e os revisores mais criteriosos
Testes escritos linha a linha por humanos	Cenários de teste especificados por humanos, escritos pelo agente, revisados por humanos

O papel não é um "sênior" rebatizado. O dia a dia é estruturalmente diferente.

Quais padrões de evolução de papéis estão em jogo

Elevação (primário). O centro de gravidade do papel se move da execução para especificação e validação. O valor migra da velocidade de digitação para a qualidade da spec e o julgamento de revisão.
Convergência (secundário). As fronteiras entre frontend, backend e infraestrutura se diluem. Um engenheiro sênior com julgamento forte consegue direcionar o agente em todo o stack numa feature que antes exigia a coordenação de três especialistas.
Emergência (parcial). Algumas responsabilidades são genuinamente novas: diálogos de esclarecimento com agentes, sessões de recalibração, contribuições para configuração do agente revisor.

Especialização e Absorção não se aplicam de forma relevante: o papel se expande em vez de se estreitar, e não se contrai nem desaparece.