---

title: "Papéis e Novas Skills no Time AI-Native: Do Senior Engineer ao AI Systems Designer" subtitle: "Como a engenharia de software se reorganiza em torno de loops de agentes, context engineering e evals — sem substituir devs, criando novas especializações" date: "2026-07-25" slug: "papeis-skills-time-ai-native" tags: ["ai-native", "engineering-teams", "skills", "ai-engineer", "career"] excerpt: "Time AI-native não é substituir devs por prompts. É emergir de novas especializações — AI Engineer, Context Designer, Evals Owner, AI Reviewer, Platform/Infra — e redesenhar a carreira do T-shaped para comb-shaped."

English summary (PT-BR article): An AI-native team is not about replacing developers with prompts. It is about new specializations emerging around agent loops — AI Engineer, Context Designer, Evals Owner, AI Reviewer, Platform/AI Infra Engineer — and reshaping the developer career from T-shaped to comb-shaped with new skills like prompt writing, context engineering, evals literacy, and AI security awareness.

Papéis e Novas Skills no Time AI-Native: Do Senior Engineer ao AI Systems Designer

No manifesto sobre equipes AI-native, definimos AI-native como um modelo de organização onde a IA não é uma ferramenta ocasional, mas a camada operacional que molda arquitetura, processo, papéis e cultura. A pergunta que fica pendente é a mais difícil de responder:

Quem faz isso acontecer?

A resposta curta é: ninguém sozinho. A resposta longa é que a reorganização de um time AI-native não substitui a figura do engenheiro por um "prompt operator". Ela faz emergir novas especializações em torno de loops de agentes, context windows, evals e infraestrutura de LLM. O senior engineer tradicional não some. Ele ganha novas ferramentas, novas responsabilidades e novos vizinhos de profundeza técnica.

Este artigo é o segundo da série sobre times AI-native. Vamos mapear os papéis que estão se consolidando em 2026, redesenhar a carreira do desenvolvedor de T-shaped para comb-shaped, listar as skills que sobem e descem de valor, e mostrar um exemplo concreto de como um AI Engineer descreve uma tarefa para um agente.

Principais aprendizados

• Um time AI-native cria novos papéis (AI Engineer, Context Designer, Evals Owner, AI Reviewer, Platform/AI Infra) — não substitui o dev por um prompt writer genérico.
• A carreira do desenvolvedor migra de T-shaped (uma profundeza) para comb-shaped (múltiplas skills + 1-2 profundezas), porque a IA exige leitura crítica em várias camadas.
• Skills que sobem de valor: arquitetura, system design, leitura crítica, escrita de specs, evals literacy, context engineering.
• Skills que descem: memorização de boilerplate, sintaxe pura de API, configuração manual repetitiva.
• Todo dev precisa hoje de noções de prompt writing, context engineering e segurança de IA (prompt injection, data leakage, IP).
• Anti-patterns: "IA vai substituir todo dev" gera medo paralisante; "todo mundo vira prompt engineer" reduz o problema; ignorar evals mata a qualidade.

A reorganização de papéis não é "menos devs"

A primeira tentação quando se fala em IA é pensar em redução de cabeça. O LinkedIn Workforce Report 2026 e o World Economic Forum Future of Jobs 2025 mostram um movimento mais interessante: o número de títulos com "AI" cresceu muito mais rápido que a redução de títulos tradicionais. O que está acontecendo não é substituição líquida, é reorganização.

Em um time AI-native maduro, as mesmas pessoas que antes codavam 100% do tempo agora dividem o trabalho entre codar, desenhar context windows, escrever evals, revisar saídas de agentes e manter a infraestrutura de IA. O trabalho de escrever código de produção não desaparece. Ele é complementado por um trabalho novo que não existia antes: o de orquestrar, avaliar e proteger sistemas probabilísticos.

A Stack Overflow Developer Survey 2024 já mostrava que mais de 70% dos desenvolvedores usavam ferramentas de IA no fluxo de trabalho. O passo seguinte, que é o tema deste artigo, é entender que usar a ferramenta não basta. É preciso ter pessoas cuja responsabilidade é desenhar o sistema em volta dela.

Os cinco papéis que estão se consolidando

Os títulos variam entre empresas, mas as responsabilidades são recorrentes. Abaixo, os cinco papéis que aparecem com mais força em times AI-native maduros em 2026.

1. AI Engineer / AI Systems Designer

O AI Engineer é o papel mais próximo do que a Anthropic chama de AI engineer: alguém responsável por desenhar sistemas que usam LLMs de forma confiável. Isso inclui desenhar loops de agentes, decidir quando usar workflow versus agent, escolher onde o contexto vive, como o estado é passado adiante, quando há intervenção humana e como o sistema se recupera.

Esse papel não é o "prompt engineer" de 2023. O prompt é só uma das variáveis. O AI Engineer pensa no contrato do loop: estado, decisão, ação, evidência, parada. Ele é quem decide, por exemplo, se uma task deve rodar como um único agente com três tools ou como um orquestrador com workers especializados — decisão que vimos em detalhe no artigo sobre loops de agentes.

Skills-chave: system design, context engineering, evals literacy, leitura crítica de saídas probabilísticas, conhecimento de ferramentas como Model Context Protocol, SDKs de agentes e frameworks de evals.

2. Context Designer (ex-Prompt Engineer)

O prompt engineer virou context designer. A diferença é crucial: o prompt é uma string; o contexto é um sistema. Hoje a maior parte do trabalho de "escrever prompts" é, na verdade, desenhar a context window completa — system prompt, exemplos recuperados via RAG, histórico de turno, schemas de ferramentas, memória de longo prazo, arquivos do repositório, saídas de tools anteriores.

O Context Designer é responsável por decidir o que entra na janela, em qual ordem, com qual prioridade, e quando deve sair. Esse trabalho é parte engenharia, parte curadoria editorial. Ele define políticas de compressão, priorização de fontes, exclusão de ruído e injeção de contexto dinâmico por tarefa.

Skills-chave: prompt writing avançado, retrieval design, curadoria de conhecimento, design de schemas de tool, consciência de janela de tokens, compressão de contexto.

3. Evals Owner / AI Quality Engineer

Se o código determinístico tem QA, o sistema com LLM tem Evals Owner. Esse papel é o dono do ciclo de qualidade de saídas probabilísticas. Enquanto o QA clássico verifica que o código faz o que a spec diz, o Evals Owner verifica que o modelo se comporta bem o bastante em uma distribuição de entradas que ninguém consegue enumerar por completo.

Suas responsabilidades incluem construir golden sets, definir métricas (task success, evidence coverage, recovery rate, cost per success), rodar avaliações automáticas antes de deploy, monitorar regressão comportamental e desenhar avaliação humana para casos ambíguos. A documentação da Anthropic sobre evals para agentes é uma boa base, mas a tradução para o produto precisa de alguém dedicado.

Skills-chave: estatística aplicada, design de experimentos, métricas de qualidade de LLM, ferramentas como promptfoo e LangSmith, escrita de rubricas, modelos como juiz (LLM-as-judge).

4. AI Reviewer / Code Reviewer Especializado

Toda empresa que usa IA para gerar código precisou criar uma nova classe de revisor. Esse papel é diferente do code reviewer tradicional porque ele precisa detectar três classes de problema específicas de saída de IA:

1. Erros sutis de lógica que parecem plausíveis, mas estão errados (off-by-one em raciocínios longos, edge cases não considerados).
2. Problemas de segurança — prompt injection que veio junto com um arquivo, código que vazou dados para um log, dependência inventada (a "biblioteca que não existe").
3. Questões de IP e licença — código que foi parafraseado de treinamento de terceiros, trechos longos demais de projetos open source mal licenciados.

O AI Reviewer não revisa apenas o que o código faz. Ele revisa de onde veio, o que carrega embutido e quais riscos introduz.

Skills-chave: leitura crítica de código, conhecimento de vulnerabilidades de LLM (OWASP Top 10 for LLM), consciência de licenças open source, capacidade de detectar raciocínios longos falhos.

5. Platform / AI Infra Engineer

Por último, alguém precisa cuidar do servidor. Em escala, chamar um LLM direto da aplicação não escala — você precisa de roteamento entre providers, cache semântico, rate limiting, observabilidade de custo, retries com fallback, controle de versão de prompt, pipelines de embedding, vector store e RAG infra.

O Platform AI Infra Engineer é o SRE da camada de IA. Ele desenha a infraestrutura que mantém o resto do time produtivo sem torrar orçamento nem comprometer latência.

Skills-chave: serving de LLM (vLLM, TGI), observabilidade (LangSmith, Helicone, Arize), cache semântico, RAG (pgvector, Pinecone, Qdrant), controle de custo, segurança de API keys.

A tabela completa: Papel, Responsabilidade, Skills e Ferramentas

Papel	Responsabilidade principal	Skills-chave	Ferramentas representativas
AI Engineer / AI Systems Designer	Desenhar loops de agentes e orquestração	System design, context engineering, evals literacy	Claude Agent SDK, OpenAI Agents SDK, Model Context Protocol
Context Designer (ex-Prompt Engineer)	Construir context windows e políticas de contexto	Prompt writing, retrieval design, curadoria	LangChain, LlamaIndex, embeddings, vector stores
Evals Owner / AI Quality Engineer	Qualidade de saídas probabilísticas e regressão	Estatística, design de experimentos, LLM-as-judge	promptfoo, LangSmith, OpenAI Evals, Braintrust
AI Reviewer / Code Reviewer Especializado	Revisar código gerado por IA (lógica, segurança, IP)	Leitura crítica, OWASP LLM Top 10, licenças	ferramentas de SAST, scanners de segredos, diff semantics
Platform / AI Infra Engineer	Serving, RAG infra, observabilidade de LLM	SRE aplicado a IA, cache semântico, custo	vLLM, Helicone, Arize, pgvector, Pinecone, OpenLLMetry

Do T-shaped ao comb-shaped: redesenhando a carreira

O desenvolvedor T-shaped clássico tem uma profundeza (backend, frontend, dados) e uma largura razoável em áreas adjacentes. Esse modelo funcionou bem por uma década, mas ele pressupõe que o trabalho de largura é secundário.

Em um time AI-native, isso muda. A largura deixa de ser opcional porque as ferramentas de IA obrigam o dev a tocar simultaneamente em camadas que antes eram separadas: prompt (texto), retrieval (dados), tool schema (API), eval (estatística), observabilidade (infra). Um dev que só sabe backend e se recusa a escrever prompt ou eval acaba isolado em uma ilha de código determinístico, perdendo a alavanca que o resto do time tem.

A metáfora que tem funcionado é a de comb-shaped (pente): múltiplas profundezas menores, com 1-2 profundezas fortes. O dev continua especialista em uma coisa, mas ganha profundeza prática em três a cinco áreas adjacentes necessárias para fechar o loop de IA.

O ponto de chegada não é obrigatoriamente "AI Systems Designer". Muitos devs vão permanecer comb-shaped sem virar especialistas. O que muda é que a porta de saída da transição não é "virar gerente" nem "continuar codando como antes". É um espectro de papéis com diferentes misturas de profundeza.