Framework muda, julgamento fica: 7 perguntas que eu faria para contratar um Senior AI Engineer

Faz um tempo que eu reparo numa coisa curiosa nas conversas sobre IA.

Alguém diz que está procurando um engenheiro de IA, e a primeira pergunta que aparece é quase sempre a mesma: “ele sabe LangChain?”. Ou LangGraph. Ou CrewAI. Ou o framework que estiver em alta naquela semana.

Não tem nada de errado em conhecer essas ferramentas. Eu uso algumas delas, você provavelmente também. O problema é que elas envelhecem rápido. O framework que todo mundo usava há um ano talvez já nem seja a primeira escolha hoje. E daqui a um ano vai ter outro nome na moda.

Se a sua régua para medir alguém é a ferramenta, você está medindo a coisa que menos dura.

Então resolvi fazer um exercício: se eu estivesse entrevistando hoje alguém para uma vaga sênior de AI Engineering, o que eu perguntaria? E, mais importante, o que eu gostaria de ouvir como resposta?

Cheguei a sete perguntas. Nenhuma delas cita framework.

1. “Como você decide se um problema realmente precisa de LLM?”

Parece uma pergunta boba, mas é a que mais me diz sobre a pessoa.

Quem tem pouca experiência costuma responder algo como “hoje dá para fazer quase tudo com LLM”. E dá mesmo. Só que dar para fazer não significa que deveria.

Quem já pagou a conta de um sistema em produção responde diferente. Essa pessoa começa perguntando se não dá para resolver com uma regra simples, uma consulta no banco, uma busca comum ou um classificador barato. Ela quer saber quanto custa errar, se existe alguém ou algo conferindo o resultado e se o volume e o tempo de resposta cabem no orçamento.

A resposta que eu gostaria de ouvir é mais ou menos esta: “Primeiro eu monto a solução mais simples possível e meço. Só coloco o modelo se ele superar essa base com folga suficiente para pagar o custo e a latência que ele traz.”

LLM é uma ferramenta incrível para lidar com linguagem bagunçada e ambígua. Para somar dois números, é um desperdício caro.

2. “O que fica em código e o que fica com o modelo?”

Essa pergunta separa quem constrói sistema de quem constrói demo.

A regra que eu gosto é simples: o modelo propõe, o código decide.

Tudo que precisa ser exato, auditável ou tem consequência real fica em código. Isso inclui permissões, cálculos, regras de negócio, validações, controle de gastos e qualquer ação que não dá para desfazer. O modelo fica com a parte de interpretação: entender o que o usuário quis dizer, resumir, classificar um texto livre, redigir uma resposta.

Na prática, o modelo devolve uma saída estruturada, e o código confere se aquilo faz sentido antes de executar qualquer coisa.

Quando alguém me diz que controla permissões “colocando no prompt que o modelo não pode fazer X”, eu já sei que essa pessoa ainda não viu um sistema quebrar. Instrução no prompt é pedido, não é trava.

3. “Como você mede se uma mudança melhorou ou piorou o sistema?”

Se eu pudesse fazer só uma pergunta, faria esta.

Todo mundo que trabalha com IA já passou por isso: você mexe no prompt, testa três exemplos, parece melhor, sobe para produção. Uma semana depois descobre que resolveu um problema e criou outros dois que ninguém viu.

Isso tem nome: vibe check. E não é avaliação.

Uma resposta madura envolve ter um conjunto de casos de teste reais, com as situações difíceis e os erros que já aconteceram antes. Envolve medir coisas separadas, como se a resposta é fiel aos fatos, se está completa, se tomou a ação certa, em vez de dar uma nota geral de “qualidade” que ninguém sabe o que significa. Envolve comparar cada versão nova com a anterior antes de publicar.

Tem um detalhe que eu acho bonito numa resposta sênior. A pessoa não exige que tudo melhore sempre. Ela aceita pequenas perdas em uma dimensão desde que não haja regressão grave no que importa. Uma versão que escreve mais bonito mas inventa mais informação não passa, por mais agradável que pareça.

4. “O que acontece quando uma API, tool ou modelo falha?”

Porque vai falhar. Não é questão de se, é de quando.

Aqui eu quero ouvir que a pessoa separa os tipos de falha. Tem a falha passageira, como timeout ou limite de requisições, que se resolve tentando de novo com calma e com um limite de tentativas. E tem a falha mais traiçoeira, quando tudo “funciona” mas o resultado vem errado: um JSON quebrado, uma ferramenta chamada com o argumento errado, uma resposta inventada com toda a confiança do mundo.

Dois pontos me chamam atenção numa boa resposta.

O primeiro é a preocupação com ações que não podem acontecer duas vezes. Se o sistema tenta de novo depois de um erro, ele não pode cobrar o cliente em dobro.

O segundo é saber falhar com honestidade. Quando não dá para responder direito, o sistema deve dizer isso ou chamar um humano, e não entregar algo que parece certo mas não é.

5. “Como você controla estado, contexto e memória sem transformar tudo num prompt gigante?”

Os modelos hoje aceitam janelas de contexto enormes, e isso criou um vício: jogar tudo lá dentro e deixar o modelo se virar.

Funciona até a conta chegar. Ou até o modelo começar a ignorar justamente a informação que importava, perdida no meio de milhares de linhas.

Quem entende do assunto separa três coisas que muita gente mistura. O estado é onde o processo está, que dados já foram coletados, o que já foi decidido. Ele mora no banco de dados e é controlado por código. O contexto é o que o modelo precisa ver agora, nesta chamada, e deve ser o mínimo necessário para a tarefa. A memória é o que vale guardar entre uma conversa e outra, com critério sobre o que salvar e o que descartar.

Com essa separação clara, o prompt fica pequeno, barato e previsível. Sem ela, vira um arquivo morto que cresce a cada interação.

6. “Como você investiga um comportamento estranho em produção?”

Um cliente reclama que a IA respondeu uma coisa absurda. E agora?

A resposta que eu não quero ouvir é “vou ajustar o prompt até parar”. Isso é tentativa e erro no escuro, e o problema geralmente volta.

O que eu quero ouvir é método. Primeiro, reproduzir o caso com o registro completo do que aconteceu: o que entrou, o que o sistema buscou, o que foi enviado ao modelo, o que ele respondeu, quais ferramentas chamou. Depois, descobrir em que camada o erro aconteceu. O documento certo foi encontrado? Ele chegou ao modelo ou foi cortado no caminho? O modelo tinha a informação e mesmo assim errou?

Essa última distinção é essencial. Muita gente troca de modelo quando o problema real era que a informação nunca chegou até ele.

E, no final, o caso vira um teste permanente. Aquele erro nunca mais passa despercebido.

7. “Como você explica custo, latência e risco para alguém de negócio?”

Essa pergunta é sobre maturidade, não sobre técnica.

Quem é de negócio não quer saber de tokens nem de benchmarks. Quer saber se vale a pena.

Então a pessoa sênior traduz. Em vez de “custa X por milhão de tokens”, ela diz “cada atendimento sai por quatro centavos, e a nossa margem aguenta até vinte”. Em vez de “latência de 3 segundos”, ela diz “no chat está ótimo, mas no checkout isso faria gente desistir da compra”. Em vez de “a acurácia é 98%”, ela diz “em 2 de cada 100 casos o sistema erra a categoria; quando o valor for alto, alguém revisa antes”.

E ela é honesta sobre o que ainda não sabe: “em duas semanas com dados reais eu te digo com segurança”.

Essa honestidade vale mais do que qualquer apresentação bonita.

E as perguntas que eu acrescentaria

Essas sete cobrem muito, mas eu ainda colocaria mais algumas na conversa.

A primeira é sobre segurança: como você se protege quando um documento, um e-mail ou uma página que o sistema lê contém instruções escondidas tentando manipular o modelo? Esse tipo de ataque está cada vez mais comum, e muita gente só pensa nele depois do estrago.

A segunda é sobre agentes: quando um fluxo fixo, passo a passo, é melhor do que um agente que decide tudo sozinho? A resposta honesta é “na maioria das vezes”, e gosto de quem tem coragem de dizer isso.

A terceira é sobre adaptação: quando vale a pena fazer fine-tuning e quando é dinheiro jogado fora, porque um bom prompt ou uma boa recuperação de documentos resolveria?

E a última, que para mim é a mais reveladora de todas: “Me conta um sistema de IA que você construiu e que deu errado.”

Quem tem experiência real tem histórias. Histórias específicas, com causa, consequência e o que aprendeu. Quem só estudou responde com generalidades. Essa pergunta não se decora.

No fim, é sobre saber decidir

AI Engineering não é saber montar um agente. Isso qualquer tutorial ensina numa tarde.

É entender por que aquela arquitetura faz sentido para aquele problema, como ela vai falhar e como ela pode evoluir sem quebrar o que já funciona.

Os frameworks vão continuar mudando, e tudo bem. Quem entende os fundamentos aprende qualquer ferramenta nova em poucos dias. Quem só conhece a ferramenta precisa recomeçar do zero toda vez que ela sai de moda.

Se você está construindo carreira ou produto com IA, meu conselho é investir no que dura: entender como os modelos funcionam, como montar contexto, como avaliar de verdade, como operar e proteger um sistema em produção.

Foi exatamente por isso que eu criei a coleção AI Engineering na Prática. São 10 ebooks em português que vão do fundamento de LLMs até avaliação, segurança, LLMOps e multimodalidade, sempre com foco em construir coisa real. Se quiser se aprofundar em cada uma dessas perguntas, é um bom lugar para começar. [em breve]

E você, que pergunta faria numa entrevista dessas? Me conta nos comentários.