Portfólio de engenheiro de IA: o que mostrar

O seu portfólio de engenheiro de IA não é uma galeria. É uma prova. Um recrutador e um tech lead olham para ele com uma única pergunta na cabeça: “essa pessoa entregou algo que aguenta dados reais e usuários reais, ou só colou tutoriais um no outro?”. Em 2026, qualquer um consegue chamar a API de um modelo. A diferença está na engenharia em torno dessa chamada: evals, observabilidade, decisões, trade-offs. Este texto trata do que mostrar, especificamente, e (tão importante quanto) do que não mostrar.

Três ou quatro arquétipos de projeto que de fato sinalizam competência

Você não precisa de dez projetos. Precisa de três, talvez quatro, que juntos cubram eixos diferentes de competência. Repetir o mesmo tipo de projeto (mais um chatbot, mais um “chat com PDF”) não acrescenta sinal nenhum, só multiplica o ruído.

• Um app de RAG com evals. Não apenas “suba um documento, faça uma pergunta”. Mostre o chunking, a escolha dos embeddings, o reranking e, o mais importante, um conjunto de avaliação: 30-50 pares de pergunta e resposta com métricas de faithfulness, context recall e answer relevance. Só esse projeto já separa um engenheiro de alguém que cola código de tutorial.
• Um agente que executa uma tarefa real. Nada de demo de “agente conversa com agente”. Algo útil: triagem de tickets, PRs automáticos com correções, pesquisa com citações. Mostre o loop de ferramentas, o tratamento de erros das ferramentas, os limites (máximo de passos, orçamento de tokens) e o que acontece quando o agente trava.
• Um fine-tune ou um harness de avaliação. Ou você ajustou um modelo menor para uma tarefa específica e mostra que ele supera o baseline no seu conjunto de dados, ou construiu uma ferramenta de avaliação que compara modelos/prompts com métricas definidas. Qualquer um dos dois mostra que você entende como a qualidade é medida, e não apenas declarada.
• Um produto lançado, com usuários. Mesmo que pequeno. Mesmo que sejam dez usuários. O que conta é que ele está em produção: tem domínio, monitoramento, controle de custos e um histórico do que quebrou e de como você consertou. Um projeto desses pesa mais do que cinco projetos que nunca saíram do localhost.

Por que “wrappers” ainda contam quando a engenharia é real

Existe um certo esnobismo circulando por aí: “isso é só um wrapper da API da OpenAI”. Ignore. A maior parte do valor de produto da IA em 2026 está justamente na camada em torno do modelo. A pergunta não é “isso é um wrapper?”, e sim “a engenharia dentro do wrapper é real?”.

Engenharia de verdade dentro de um wrapper significa: uma camada de evals que pega regressões de prompt; cache e fallbacks entre provedores; controle de custo por requisição; tratamento de rate limits e retry com backoff; validação da saída antes que ela chegue ao usuário; log de traces para cada chamada. Se você mostra isso, o “wrapper” é um sinal forte de engenharia. Se o seu código são três linhas de chamada sem nada disso, aí sim vão chamá-lo, com razão, de demo.

READMEs que mostram decisões e trade-offs

Do ponto de vista de contratação, o README é o arquivo mais importante do repositório. Quem lê passa os primeiros trinta segundos ali e, com base neles, decide se vai abrir o código ou não. Um README de “como rodar” é necessário, mas não suficiente. Acrescente uma seção de decisões.

• Problema e contexto. Duas frases: o que o projeto resolve e para quem. Sem isso, quem lê não sabe se está diante de um brinquedo ou de uma ferramenta.
• Decisões de arquitetura. “Escolhi o pgvector em vez de um banco vetorial dedicado porque a escala é de dezenas de milhares de vetores, e assim fica um serviço a menos para manter.” Essa frase diz mais do que um diagrama.
• Trade-offs que você deliberadamente não fez. “Deixei o reranking de fora porque, no meu conjunto de avaliação, ele aumentou o recall em 2% ao custo de 300ms de latência.” Isso mostra que você mediu, em vez de chutar.
• O que você faria com mais tempo. Uma seção curta de “próximos passos” mostra que você enxerga os limites da sua própria solução.

Como demonstrar evals e observabilidade

Hoje, esse é o sinal mais raro e mais forte. A maioria dos projetos de IA em portfólios não tem um único número. Se o seu tem, você entra na hora em outra liga.

• Um conjunto de avaliação no repositório. Um arquivo com casos de teste (entrada, comportamento esperado, métrica). Até trinta casos bastam para mostrar que você pensa em termos de medição.
• Métricas, não impressões. “Faithfulness de 0.87 num conjunto de 40 perguntas” em vez de “até que funciona bem”. Apresente os números como o resultado num conjunto específico, e não como verdade universal.
• Observabilidade. Mostre que você registra traces (por exemplo, com uma ferramenta como o Langfuse ou um logger próprio): custo por requisição, latência p95, contagem de tokens, versão do prompt. Um print do dashboard no README vale mais que mil palavras.
• Um teste de regressão de prompts. Mostre que alterar um prompt dispara o conjunto de avaliação no CI. É uma raridade que grita “essa pessoa trabalhou com LLMs a sério”.

Higiene no GitHub

O seu perfil no GitHub é o seu cartão de visita antes que alguém leia o currículo. Três coisas estragam a impressão mais rápido: node_modules commitado, segredos no histórico de commits e vinte repositórios-esqueleto sem README. Faça uma faxina.

1. Fixe os seus 3-4 melhores repositórios. Deixe o resto privado ou arquivado.
2. Commits descritivos, e não “wip” ×40. O histórico de commits é uma prova do seu raciocínio.
3. Zero segredos no histórico. Escaneie o repositório (por exemplo, com gitleaks) antes de torná-lo público. Uma chave de API no git log é sinal vermelho numa contratação.
4. .gitignore, licença, um README limpo: higiene básica.
5. Um README de perfil com um parágrafo: quem você é e no que está trabalhando agora.

Um site pessoal e o efeito multiplicador de escrever e ensinar

Um site pessoal não precisa ser uma obra de arte. Ele precisa responder em trinta segundos: quem você é, o que construiu, como falar com você. Uma lista de projetos com uma frase de descrição e um link para o repositório e para a demo. Isso basta.

O multiplicador é escrever e ensinar. Se você conta como montou o conjunto de avaliação do seu app de RAG, ou por que abandonou o fine-tune em favor de um prompt melhor, mostra uma profundidade que o repositório sozinho não consegue transmitir. Um bom post técnico num blog, ou uma thread com uma lição real de engenharia, vale mais do que dez “reflexões sobre IA”. Também é um sinal de que você sabe se comunicar, uma habilidade pela qual os times pagam mais.

Antipadrões que matam um portfólio

• Clones de tutorial. Se dá para reconhecer o curso de onde o projeto saiu, o sinal é zero ou negativo. Pegue a ideia de um tutorial, mas mude o domínio, acrescente evals e coloque no ar: aí ela passa a ser sua.
• Sem métricas. Um projeto de IA sem um único número é uma declaração de “não sei se isso funciona”. É o maior erro individual em portfólios de IA.
• Sem deploy. “Funciona localmente” significa “nunca lidei com custo, latência, segredos e rate limits”. Coloque pelo menos um projeto no ar.
• Só notebooks. Uma pilha de arquivos .ipynb sem nenhuma aplicação sugere um experimentador, não um engenheiro. Transforme pelo menos um notebook em um serviço.
• README maior que o código. Um README longo e gerado automaticamente num projeto vazio é lido na hora como fachada. Menos promessas, mais código funcionando.

Um checklist concreto

1. 3-4 projetos cobrindo eixos diferentes: RAG com evals, um agente, um fine-tune/harness, um produto lançado.
2. Cada projeto tem um conjunto de avaliação no repositório e pelo menos uma métrica com número.
3. Pelo menos um projeto está em produção, com domínio próprio.
4. Todo README tem uma seção de decisões e trade-offs, e não só instruções para rodar.
5. A observabilidade está visível: custo por requisição, latência, versionamento de prompts.
6. Perfil no GitHub arrumado: 3-4 repositórios fixados, zero segredos, commits descritivos.
7. Um site pessoal com lista de projetos e um contato claro.
8. Pelo menos um post técnico descrevendo uma decisão real de engenharia.
9. Zero clones de tutorial reconhecíveis pelo nome.

TL;DR

Em 2026, um portfólio de engenheiro de IA é prova, não galeria. Mostre 3-4 projetos em eixos diferentes: um app de RAG com evals, um agente executando uma tarefa real, um fine-tune ou harness de avaliação e pelo menos um produto lançado. “Wrappers” contam se houver engenharia de verdade em torno da chamada ao modelo. Os READMEs devem mostrar decisões e trade-offs. O sinal mais forte e mais raro são as evals e a observabilidade: números em vez de impressões. Arrume o seu GitHub, coloque no ar um site simples, escreva um bom post técnico. Evite clones de tutorial, falta de métricas e falta de deploy.