O Engenheiro Sênior na Era da IA

A narrativa de que LLMs tornam engenheiros sênior menos relevantes — porque podem gerar código que antes era habilidade diferenciada — é tecnicamente superficial e empiricamente não suportada. Ela confunde a habilidade de escrever código com a habilidade de engenharia. Escrever código é um meio. Engenharia é o processo de identificar o problema correto, projetar a solução adequada, tomar decisões com consequências de longo prazo, e garantir que o sistema resultante é correto, seguro, e manutenível no contexto específico em que opera. LLMs são extraordinariamente bons em algumas partes desse processo e fundamentalmente limitados em outras — e o balanço favorece, de forma não óbvia, engenheiros mais experientes.

Este conceito é a síntese de todo o módulo: o que significa ser um engenheiro sênior quando LLMs são ferramentas disponíveis, onde o valor do julgamento experiente é amplificado, onde o trabalho muda, e onde permanecer igual era a resposta errada. É também o conceito mais pessoal do módulo — porque responde à pergunta que todo engenheiro faz, de forma implícita ou explícita, quando começa a trabalhar com estas ferramentas: o que isso significa para mim?

A confusão entre escrita de código e engenharia

Quando se diz que LLMs ameaçam o papel do engenheiro, implicitamente se define o papel do engenheiro como "escrita de código". Essa definição é comum em cultura popular de tecnologia — o estereótipo do engenheiro que passa o dia digitando código é persistente — mas é uma definição inadequada do que engenheiros sênior de fato fazem.

Pesquisa de como engenheiros sênior passam seu tempo revela consistentemente: menos de 50% do tempo é em escrita direta de código. O restante é distribuído entre entender requisitos, design arquitetural, code review, mentoria, comunicação com stakeholders, diagnóstico de problemas em produção, e decisões técnicas com implicações de negócio. Essas atividades requerem julgamento contextual que LLMs não fornecem.

Mais especificamente: a parte do trabalho de um engenheiro sênior que requer julgamento acumulado sobre o sistema específico, o domínio de negócio específico, a equipe específica, e as restrições operacionais específicas — essa parte é irreplicável por qualquer LLM atual. LLMs têm conhecimento geral excelente. Não têm o conhecimento particular que define o trabalho sênior.

O que LLMs efetivamente mudam

Ser honesto sobre o que muda é condição para adaptar-se de forma inteligente. Há mudanças reais, e negá-las seria tão inútil quanto exagerá-las.

O custo de implementação de decisões conhecidas caiu

Quando a decisão de design foi tomada e o caminho de implementação está claro, LLMs reduzem drasticamente o tempo de implementação. Isso não é trivial — significa que a lacuna entre "decidir o que fazer" e "ter o código que faz isso" reduziu de horas ou dias para minutos. Isso tem impacto na cadência de iteração: é possível testar mais hipóteses de design rapidamente, refatorar com mais frequência porque o custo de refatoração caiu, e explorar alternativas antes de comprometer.

O que não mudou: o custo de decidir o que fazer. Entender os requisitos, identificar as alternativas, analisar trade-offs, escolher a abordagem — isso ainda requer o mesmo esforço cognitivo de antes. LLMs podem ajudar (como sounding board, para explorar alternativas rapidamente, para verificar se a análise perdeu algum ângulo), mas não substituem o julgamento.

A escrita de boilerplate e código mecânico tornou-se não-trabalho

Escrever migrações de banco de dados, implementar endpoints CRUD, gerar testes de regressão para funcionalidade existente, converter código de um formato para outro — essas tarefas que consumiam tempo significativo de engenheiros bons estão agora no domínio do LLM. Isso libera tempo para o trabalho que requer julgamento.

O impacto agregado é mais interessante: em uma equipe de 5 engenheiros onde 30% do tempo ia para trabalho mecânico, e esse trabalho é delegado para LLMs, há o equivalente a 1.5 engenheiro de capacidade liberada para trabalho de maior valor. Esse ganho é real — mas só se materializa se a equipe redireciona o tempo liberado para trabalho de maior valor, não simplesmente para mais volume do mesmo trabalho.

O ritmo de mudança tecnológica acelerou

LLMs estão acelerando o próprio desenvolvimento de ferramentas de LLM. Novos modelos, novas capacidades, novos frameworks agenticos, novas integrações — o ritmo de mudança no ecossistema de IA é mais rápido do que qualquer outro ecossistema tecnológico na história recente de engenharia de software. Isso cria uma pressão de atualização contínua que é genuinamente nova.

A resposta a essa pressão não é tentar acompanhar cada novidade — é desenvolver a capacidade de avaliar rapidamente se uma nova ferramenta ou modelo muda a equação o suficiente para justificar adoção. Isso requer entender os princípios subjacentes (o que um LLM pode e não pode fazer), não apenas conhecer as versões específicas de ferramentas.

O que permanece invariante

Identificar o que não muda é tão importante quanto identificar o que muda — porque é onde o investimento de desenvolvimento é mais durável.

Julgamento sobre o problema correto

O problema mais caro em engenharia é resolver o problema errado de forma brilhante. LLMs são extremamente bons em resolver o problema que você especificou — e igualmente incapazes de identificar se você especificou o problema correto. A pergunta "estamos construindo a coisa certa?" é de responsabilidade humana por completo.

Engenheiros sênior desenvolvem ao longo da carreira a capacidade de questionar os requisitos: "por que precisamos disso?", "o que acontece se não construirmos?", "existe uma solução mais simples que satisfaz 80% do caso?", "este requisito reflete o que o usuário precisa ou o que o usuário pediu?". Essa capacidade de questionar o problema não foi afetada por LLMs — e continua sendo um dos diferenciadores mais valiosos.

Conhecimento de domínio acumulado

Saber como o sistema de cobrança funciona, quais são as invariantes do modelo de dados, por que uma decisão arquitetural específica foi tomada há três anos, quais são os pontos de falha históricos de uma integração com parceiro específico — esse conhecimento não está em nenhum repositório público e não pode ser adquirido por LLM. É acumulado pela presença no projeto ao longo do tempo.

LLMs democratizaram conhecimento geral de engenharia. O que restou como diferenciador é o conhecimento particular: do sistema específico, do domínio específico, da equipe específica, das decisões tomadas e seus contextos. Engenheiros com mais tempo em um sistema ou domínio têm mais desse conhecimento — e esse conhecimento tornou-se mais valioso, não menos, porque é o que complementa o que LLMs fornecem.

Responsabilidade pela correção e segurança

A responsabilidade pelo código que vai para produção não migrou para o LLM — como estabelecido no conceito anterior. Isso significa que a habilidade de verificar correção, identificar falhas de segurança, e avaliar adequação para o contexto de produção específico permanece critical. LLMs ajudam (como discutido no conceito 06 sobre code review), mas não substituem o julgamento humano sobre essas dimensões.

Arquitetura de sistemas

Projetar como componentes de um sistema devem interagir, quais são as fronteiras de serviço corretas, como distribuir responsabilidades, quais são os trade-offs de consistência versus disponibilidade para este sistema específico — essas decisões requerem entender o contexto de negócio, as restrições operacionais, e as habilidades da equipe. LLMs podem propor arquiteturas, e propostas de LLM podem ser um bom ponto de partida, mas a decisão arquitetural precisa ser tomada por alguém que entende o contexto completo.

Mais especificamente: arquitetura envolve decisões com consequências que se desdobram ao longo de anos. Um LLM que não conhece a história do sistema, os episódios de falha anteriores, as direções de produto para os próximos 12 meses, e as capacidades da equipe não pode tomar essas decisões com o mesmo julgamento que um arquiteto experiente no domínio.

Mentoria e desenvolvimento de equipe

Desenvolver engenheiros é uma das atividades de maior alavancagem de um sênior — um bom engenheiro que ajuda a desenvolver cinco outros cria impacto multiplicado. LLMs podem explicar conceitos, dar feedback em código, e responder perguntas técnicas — mas não podem substituir a relação de mentoria humana onde o mentor conhece o mentorado, entende onde estão seus pontos de desenvolvimento, e pode dar feedback contextualizado sobre o trabalho real que o mentorado está fazendo.

Onde o valor sênior é amplificado

Há dimensões onde LLMs amplificam especificamente o valor de engenheiros mais experientes, não o reduzem.

A alavancagem do contexto

LLMs são tão bons quanto o contexto que recebem. Engenheiros sênior têm mais contexto relevante — sobre o sistema, o domínio, os trade-offs históricos — e consequentemente conseguem extrair outputs de mais alta qualidade dos LLMs. A mesma pergunta, feita por um engenheiro com contexto rico versus um sem contexto, gera respostas de qualidade muito diferente porque o contexto no prompt determina a qualidade do output.

Isso cria uma assimetria: LLMs amplificam a vantagem de quem tem contexto. Quem tem mais contexto (engenheiros experientes) extrai mais valor. A ferramenta não nivela o campo — ela amplifica a diferença, pelo menos para trabalho que requer contexto rico.

Avaliação e curadoria

LLMs geram; engenheiros avaliam. A qualidade da avaliação determina a qualidade do que entra na base de código. Engenheiros mais experientes avaliam com mais critério: reconhecem assunções incorretas, identificam padrões problemáticos, sabem quais casos de borda o código gerado não cobre. A curadoria de alta qualidade requer a experiência para saber o que procurar.

Isso significa que a cadeia de valor mudou: antes era predominantemente "implementar"; agora é "especificar → gerar → avaliar → refinar". A etapa de avaliação tem o maior impacto na qualidade do output final — e requer o julgamento mais experiente.

Definição de processo para o time

Quem estabelece como o time usa LLMs determina se o time extrai o valor ou acumula os riscos. Definir quando usar LLM e quando não usar, como estruturar prompts para o contexto específico do projeto, que nível de revisão é adequado para cada categoria de código, como preservar rastreabilidade — essas são decisões de processo que requerem julgamento técnico e organizacional. Em times que adotam LLMs, o engenheiro sênior que lidera a definição desse processo tem impacto significativo na produtividade e qualidade do time inteiro.

Novas habilidades para o contexto de IA

Além do que permanece, há habilidades genuinamente novas que engenheiros sênior precisam desenvolver para operar bem no ecossistema com LLMs.

Especificação precisa

Como detalhado no conceito 02, especificação precisa — transformar um problema mal definido em uma descrição formal com comportamento esperado, exemplos concretos, restrições, e casos de não-objetivo — é uma habilidade que LLMs tornam mais valiosa. Um engenheiro que escreve especificações precisas extrai código de qualidade muito superior do que um que escreve prompts vagos. Essa habilidade de especificação era importante antes; tornou-se crítica agora.

Avaliação de output de LLM

Saber quando confiar no output de um LLM, quando questionar, e quando rejeitar — é uma habilidade que se desenvolve com prática. Envolve entender os padrões de falha específicos de LLMs (discutidos ao longo do módulo), reconhecer quando o output é plausível mas semanticamente errado, e saber quais dimensões verificar com mais cuidado para cada tipo de tarefa. Não é uma habilidade que se aprende apenas lendo — requer prática deliberada com feedback.

Gestão de contexto em sessões longas

Em sessões longas com agentes de IA (como Claude Code para implementação de features complexas), o contexto acumula e a qualidade do output pode degradar à medida que o contexto relevante fica mais diluído. Saber quando iniciar uma nova sessão, como estruturar o contexto inicial para máxima efetividade, e quando retomar o controle manual — são habilidades de gestão de trabalho agentico que não tinham análogo antes.

Avaliação de ferramentas do ecossistema

O ecossistema de ferramentas de IA para engenharia está evoluindo rapidamente. Novos modelos, novos agentes, novas integrações de IDE — avaliar se uma nova ferramenta muda a equação o suficiente para justificar adoção e processo de aprendizado requer critérios. Quais dimensões importam (qualidade de output, latência, custo, integração com o fluxo existente)? Como avaliar em condições que refletem o trabalho real, não benchmarks genéricos? Como comparar modelos para o caso de uso específico do time?

Adaptações de carreira

Além do trabalho diário, há implicações de carreira que vale considerar explicitamente.

Onde investir em desenvolvimento de habilidades

Habilidades que LLMs tornam mais valiosas: design de sistemas, arquitetura, julgamento de trade-offs, entendimento de domínio profundo, comunicação técnica precisa, avaliação de código gerado, definição de processo. Habilidades que LLMs tornam menos diferenciadas: escrita de boilerplate, implementação de algoritmos conhecidos, tradução de especificação clara para código.

Isso não significa abandonar fundamentos — fundamentos são precisamente o que permite avaliar o output de LLMs com competência. Significa que o diferencial competitivo migra de "implementar com qualidade" para "julgar com qualidade". Investimento em conhecimento de domínio profundo, em arquitetura de sistemas, e em comunicação técnica tem ROI crescente.

Portfólio e demonstração de habilidade

Com LLMs, a questão "você implementou isso?" torna-se menos relevante do que "você projetou isso?", "você identificou o problema certo?", "você avaliou as alternativas?". Demonstrar habilidade sênior em um contexto de IA requer mostrar o trabalho que requer julgamento — especificações, decisões arquiteturais documentadas (ADRs), análise de trade-offs, e processo de revisão — não apenas o código resultante.

A pressão de adaptação é real

Engenheiros que não se adaptam a trabalhar com LLMs terão desvantagem competitiva. Isso não é porque LLMs substituem engenheiros — é porque um engenheiro que trabalha bem com LLMs entrega mais do que um que não usa, com qualidade comparável. A pressão não é de substituição, é de adoção. Resistir à adoção por princípio ("prefiro escrever meu próprio código") é análogo a resistir ao uso de IDE em favor de editores de texto puro — uma posição possível mas progressivamente menos competitiva.

O mito da nivelação: LLMs tornando júniors competitivos com sêniors

Uma versão comum da narrativa de ameaça é mais específica: LLMs não eliminam engenheiros, mas tornam engenheiros júnior competitivos com sêniors para tarefas antes diferenciadas. Essa narrativa merece análise cuidadosa porque tem um núcleo de verdade e uma generalização exagerada.

O que é verdadeiro

Para tarefas bem definidas com contexto completo fornecido, a lacuna de qualidade entre um engenheiro júnior com bom prompting e um sênior implementando diretamente reduz significativamente. Se você dá a um júnior uma especificação precisa, o contexto relevante do código existente, e um processo de revisão adequado, o código que produz com LLM pode ser comparável ao que um sênior produziria manualmente.

O que é exagerado

A nivelação só ocorre quando a tarefa é bem definida com contexto completo. O trabalho sênior de maior valor — identificar que a tarefa está mal definida, fornecer o contexto que estava faltando, revisar com a profundidade necessária — não foi nivelado. LLMs nivelam a implementação de especificações claras. Não nivelam a criação de especificações claras de problemas ambíguos.

Empiricamente: times que adotaram LLMs e mediram produtividade consistentemente relatam que engenheiros mais experientes extraem mais valor das ferramentas, não menos. A hipótese de nivelação não é suportada pelos dados disponíveis de times em produção.

A tese central deste módulo

Este módulo foi construído ao longo de 15 conceitos com uma tese central: LLMs são ferramentas que amplificam a capacidade de engenharia quando usados com competência e processo adequado. A competência requer entender o que LLMs fazem bem (e o que fazem mal), o processo requer adaptação deliberada do fluxo de trabalho para extrair valor enquanto gerencia os riscos.

O título desta formação — "senior is a verb" — aplica-se diretamente ao contexto de IA. Ser sênior no contexto de IA não é uma categoria estática ("conheço os modelos") — é um verbo: a prática contínua de avaliar, adaptar, definir processo, mentoriar, e julgar. O contexto muda; a natureza do trabalho de senioridade é a mesma.

Engenheiros que vão desenvolver-se bem neste contexto são os que entendem essa distinção: não estão aprendendo ferramentas — estão desenvolvendo julgamento sobre quando e como usar ferramentas. O julgamento é o invariante; as ferramentas mudam.

Comparação por linguagem

// docs/decisions/0042-adocao-de-llms-no-fluxo-de-desenvolvimento.md

# ADR-0042: Adoção de LLMs no Fluxo de Desenvolvimento

**Status:** Aceito — 2026-03-15
**Decisores:** @arch-lead, @tech-lead, @security-lead
**Revisão programada:** 2026-09-15

## Contexto

O time de Plataforma (8 engenheiros) recebe crescente pressão para
aumentar velocidade de entrega. LLMs (Claude Code, GitHub Copilot)
estão sendo usados informalmente por alguns membros sem processo definido.

Riscos identificados sem processo: inconsistência de padrões,
código não revisado adequadamente, potencial vazamento de código
proprietário via APIs externas.

## Decisão

Adotar LLMs com processo estruturado:

1. **Escopo permitido:** Implementação de código após spec revisada,
   geração de testes de regressão, geração de boilerplate (migrations,
   DTOs, controllers CRUD), documentação de APIs públicas.

2. **Escopo excluído:** Algoritmos de precificação, código do motor de
   risco, integrações com parceiros sob NDA, qualquer código que contenha
   ou requeira contexto com dados de clientes reais.

3. **Ferramentas aprovadas:** Claude Code (API key corporativa, zero
   data retention), GitHub Copilot Business (filtro de duplicação ativo).
   Uso de Claude.ai consumer ou ChatGPT: não aprovado para código do projeto.

4. **Processo de revisão:** PR template `ai_generated` obrigatório para
   PRs com mais de 40% de código gerado. Checklist inclui verificação
   de consistência de padrão, casos de borda de domínio, e segurança.

5. **Rastreabilidade:** Tag `[gen: claude]` em mensagens de commit.
   Arquivo .ai-generated.json para módulos onde rastreabilidade
   granular é necessária (compliance financeiro).

## Consequências positivas

- Estimativa: 20-30% redução em tempo de implementação de código mecânico
- Freeing de tempo sênior para design e review de qualidade
- Processo explícito elimina inconsistência de adoção informal

## Consequências negativas e mitigações

- Risco de atrofia de habilidade em júniores → Sessions mensais de coding
  sem LLM, PR reviews que exigem explicação da implementação
- Risco de dívida técnica por revisão inadequada → Checklist obrigatório,
  step de CI que detecta padrões inconsistentes
- Overhead de processo → Revisão do ADR em 6 meses para calibrar

## Alternativas consideradas

**Não adotar:** Mantém status quo mas não mitiga uso informal
  já existente. Descartada.
**Adoção sem processo:** Maximiza velocidade de curto prazo com risco
  alto de dívida técnica. Descartada.
**Usar apenas ferramentas locais (Ollama):** Elimina risco de dado,
  qualidade significativamente menor. Reservada para código de alto sigilo.

# tools/skill_development_planner.py
# Gera plano de desenvolvimento baseado em padrões de uso de LLM.
# Integra com dados de commit e auto-avaliação.

from dataclasses import dataclass
from enum import Enum

class SkillLevel(Enum):
    STRONG = "forte - pratica regularmente sem IA"
    AT_RISK = "em risco - raramente pratica sem IA"
    ATROPHIED = "atrofiada - dependência estabelecida"

@dataclass
class SkillAssessment:
    skill: str
    level: SkillLevel
    ai_delegation_rate: float  # 0.0 a 1.0
    last_practice_without_ai: str  # data aproximada

# Habilidades monitoradas para engenheiros que usam LLMs regularmente
CORE_SKILLS = [
    "debugging independente (sem sugestão de LLM)",
    "estimativa de complexidade algorítmica",
    "leitura de código não familiar sem explicação de LLM",
    "design de schema de banco de dados",
    "análise de trace de performance",
    "design de API sem scaffold de LLM",
    "escrita de testes de domínio (não gerados por LLM)",
    "code review de código não trivial",
]

def assess_skills(
    assessments: list[SkillAssessment]
) -> dict[str, list[str]]:
    """Retorna plano de desenvolvimento por prioridade."""
    at_risk = [a for a in assessments if a.level == SkillLevel.AT_RISK]
    atrophied = [a for a in assessments if a.level == SkillLevel.ATROPHIED]

    plan: dict[str, list[str]] = {
        "imediato": [],
        "próximo mês": [],
        "trimestre": [],
    }

    for skill in atrophied:
        plan["imediato"].append(
            f"🔴 {skill.skill}: prática semanal obrigatória sem IA. "
            f"Último exercício: {skill.last_practice_without_ai}."
        )

    for skill in at_risk:
        plan["próximo mês"].append(
            f"🟡 {skill.skill}: agendar sessão de prática sem IA por mês. "
            f"Taxa de delegação atual: {skill.ai_delegation_rate:.0%}."
        )

    return plan

def generate_practice_exercises(skill: str) -> list[str]:
    """Sugere exercícios específicos para manter habilidade."""
    exercises = {
        "debugging independente": [
            "Reservar 1h por semana para debugging de bug real sem abrir LLM",
            "Usar apenas logs e debugger — sem pesquisa externa por 30 min",
            "Documentar hipóteses antes de verificar: forma o hábito de raciocínio",
        ],
        "leitura de código não familiar": [
            "Ler e explicar uma PR de outra equipe sem usar LLM para explicação",
            "Explorar um módulo legacy por 30 min — apenas leitura e notas",
            "Revisar contribuição open source fora da área de conforto",
        ],
        "escrita de testes de domínio": [
            "Escrever casos de teste antes de qualquer implementação ou LLM",
            "Para cada feature: listar casos de domínio que LLM não geraria",
            "Revisar suíte existente: identificar casos que nenhum humano escreveu",
        ],
    }
    # default genérico para habilidades não mapeadas
    return exercises.get(skill, [
        f"Praticar {skill} sem assistência de LLM por 1h/semana",
        f"Documentar o que aprendeu: consolida o aprendizado",
    ])

# Exemplo de uso
if __name__ == "__main__":
    # Auto-avaliação — idealmente integrada com dados de commit
    my_assessment = [
        SkillAssessment(
            "debugging independente",
            SkillLevel.AT_RISK,
            ai_delegation_rate=0.7,
            last_practice_without_ai="há ~3 semanas"
        ),
        SkillAssessment(
            "escrita de testes de domínio",
            SkillLevel.ATROPHIED,
            ai_delegation_rate=0.9,
            last_practice_without_ai="há ~2 meses"
        ),
        SkillAssessment(
            "code review",
            SkillLevel.STRONG,
            ai_delegation_rate=0.2,
            last_practice_without_ai="esta semana"
        ),
    ]

    plan = assess_skills(my_assessment)
    for priority, items in plan.items():
        if items:
            print(f"\n=== {priority.upper()} ===")
            for item in items:
                print(f"  {item}")

// docs/onboarding/ai-tools-guide.md (como comentário Go para referência)

/*
=== USO DE FERRAMENTAS DE IA NO TIME ===

Bem-vindo ao time. Este guia explica como usamos LLMs —
e igualmente importante, como NÃO os usamos.

--- FERRAMENTAS APROVADAS ---

Claude Code (via API corporativa):
  Aprovado para: implementação após spec revisada, testes de regressão,
  boilerplate, documentação de API pública.
  NÃO use para: módulos de risco (ver /internal/risk/README.md),
  integrações com parceiros sob NDA, código com dados de cliente no contexto.

GitHub Copilot Business:
  Aprovado com filtro de duplicação ativo (já configurado no .github).
  Alternativa ao Claude Code para completions de inline.

--- O QUE NÃO DELEGUE ---

1. Entendimento de domínio: quando o LLM explica algo sobre nosso negócio,
   verifique com alguém do time. LLMs não conhecem nossas regras específicas.

2. Decisões de design: use LLM como sounding board, não como árbitro.
   Documente a decisão em ADR com o raciocínio — não "o LLM sugeriu".

3. Revisão de segurança final: LLM como primeiro passo, humano como último.
   Para código de autenticação ou autorização: pair review obrigatório.

--- CONVENÇÕES ---

Commits com código substancialmente gerado: inclua [gen: claude] na mensagem.
PRs com >40% gerado: use o template .github/pull_request_template_ai.md.

--- DESENVOLVIMENTO DE HABILIDADES ---

Nos primeiros 3 meses, reserve 2h/semana para implementar
algo sem assistência de LLM — pode ser uma feature pequena,
pode ser um exercício. O objetivo é não perder a capacidade
de operar independentemente.

Seu buddy de onboarding pode sugerir exercícios adequados
ao seu nível e às áreas onde você precisa desenvolver fluência.

--- DÚVIDAS ---

Para dúvidas sobre o que é ou não apropriado submeter a um LLM:
pergunte antes, não depois. A política está em /docs/ai-policy.md.
*/

package onboarding

Síntese: o que este módulo construiu

Ao longo de 12 conceitos, este módulo construiu um mapa completo de como trabalhar com LLMs em engenharia de software — não como entusiasmo tecnológico, mas como prática profissional com fundamentos, técnicas, processos, e limites explícitos.

O mapa tem quatro dimensões: o que LLMs fazem (01 — fundamentos, 03 — agentic coding), como usar bem (02 — spec-driven, 04 — prompting, 05 — testes, 06 — code review, 07 — refactoring, 08 — documentação, 09 — CI/CD), como avaliar e controlar (10 — avaliação de output, 11 — riscos e limites), e o que tudo isso significa para o engenheiro que o usa (12 — este conceito). Os três conceitos seguintes (13, 14, 15) aprofundam o ecossistema técnico de agentes de IA: o protocolo que conecta LLMs a ferramentas, os tipos de agentes, e como configurá-los.

A tese do módulo, repetida: LLMs são amplificadores de capacidade quando usados com competência e processo. A competência se constrói entendendo a ferramenta. O processo se constrói adaptando deliberadamente o fluxo de trabalho. E o julgamento sobre quando e como usar — esse é o trabalho de senioridade que permanece, que nenhuma ferramenta automatiza, e que toda esta formação está construindo.

Exercícios práticos

1. Mapa pessoal de impacto: Para o trabalho que você faz no dia-a-dia, faça uma categorização em três grupos: (a) trabalho que LLMs já fazem ou poderiam fazer com boa qualidade, (b) trabalho que LLMs ajudam mas não substituem seu julgamento, (c) trabalho que LLMs fundamentalmente não conseguem fazer bem. Para cada grupo, estime que porcentagem do seu tempo vai para ele atualmente. Como muda se você delega o grupo (a) para LLMs? O que você faria com o tempo liberado?
2. ADR de adoção: Escreva um ADR que documentaria a decisão de adotar LLMs no seu time atual (ou hipotético). Inclua: contexto, decisão, escopo permitido e excluído, ferramentas aprovadas, processo de revisão, rastreabilidade, e consequências positivas e negativas com mitigações. O objetivo não é ter um documento perfeito — é o exercício de pensar a adoção como decisão arquitetural com trade-offs explícitos, não como adoção por entusiasmo.
3. Avaliação de habilidades em risco: Identifique as três habilidades técnicas que você delegou mais frequentemente para LLMs nos últimos três meses. Para cada uma, avalie honestamente: você ainda consegue executar essa habilidade de forma independente com a mesma qualidade que conseguia antes? Se não, planeje sessões de prática deliberada sem assistência de LLM para as próximas quatro semanas.