o problema
Quem chega em LLM vindo de backend não sofre por falta de material, sofre por falta de ordem. A referência da API responde qual campo mandar no corpo do request. Os papers respondem por que a coisa funciona. Os posts respondem uma técnica de cada vez, cada um assumindo que você já leu os outros três. Nada disso responde a pergunta que a pessoa realmente tem no primeiro dia: em que sequência eu aprendo isso, e o que eu preciso saber antes de cada passo.
O sintoma dessa falta é previsível. A pessoa aprende a chamar o endpoint, lê um post sobre tool use, monta um agente que chama três funções — e trava, porque não tem nenhum jeito de saber se o prompt que está no meio disso melhorou ou piorou depois da última mudança. Ela escreve um prompt de duzentas linhas e o defende por intuição. Depurar um sistema desses é caro justamente porque a etapa que daria o sinal, medir, ficou de fora do caminho que ela percorreu.
a ideia
O repositório empacota o assunto como currículo, não como coleção. São cinco cursos, e o README declara a ordem sugerida: fundamentos da API, tutorial interativo de prompt engineering, prompting no mundo real, avaliação de prompt, tool use. A ordem é a parte que carrega opinião.
O primeiro curso é deliberadamente mundano: chave de API, parâmetros do modelo, prompt multimodal, streaming. Depois vem prompting como técnica, e só então prompting como ele aparece em produção — um curso separado, o que é uma admissão de que a distância entre saber a técnica e escrever o prompt que vai para o ar é grande. A avaliação vem em quarto lugar, antes de tool use. É a inversão em relação ao caminho que a maioria toma sozinha: mede-se primeiro, dá-se ferramenta ao modelo depois. Tool use fecha, porque é onde o erro fica mais difícil de enxergar sem instrumento.
Duas escolhas laterais dizem para quem o material foi feito. O texto avisa que os cursos favorecem o modelo mais barato da linha, Claude 3 Haiku, para segurar o custo de quem está seguindo os exercícios, e libera trocar. E o tutorial de prompting tem versão para AWS Workshop, enquanto o de prompting real tem versão para Google Vertex: o currículo não amarra o aluno a um jeito de acessar o modelo.
o que isso custou
Calibrar tudo no modelo mais fraco tem um preço que o README não paga. Uma técnica que rende muito em Haiku pode ser desnecessária num modelo maior, e um prompt que só funciona porque foi espremido contra o modelo pequeno pode estar carregando andaime inútil. O texto diz que você pode usar outro modelo se preferir, mas não diz o que muda quando você troca — e essa é exatamente a pergunta de quem vai levar o material para produção.
O currículo também é uma foto. Ele termina em tool use, e tool use foi só o começo do que veio depois: protocolos de conexão a ferramenta externa, orquestração de subagentes, engenharia de contexto, raciocínio explícito. Nada disso está no escopo dos cinco cursos, que somam poucas dezenas de commits. Um repositório de ensino com pouco churn é honesto sobre estabilidade e opaco sobre atualidade: ele não avisa quais partes envelheceram.
E há o limite de gênero. Curso não é contrato. Quando o material educacional diverge da documentação da plataforma, quem manda é a documentação — o repositório existe para formar intuição, não para ser citado como especificação.
onde isso aparece hoje
Os cinco assuntos do currículo reaparecem, um a um, como páginas de referência da plataforma: a visão geral de prompt engineering e as boas práticas de prompt cobrem o que aqui são dois cursos; definir critérios de sucesso e demystifying evals continuam a linha de avaliação; tool use e implementar tool use fecham o mesmo arco no registro de documentação.
A divisão de trabalho entre esse acervo e os cookbooks é clara na prática: o cookbook entrega receita para copiar, o curso entrega sequência para percorrer. Quem já sabe o que quer construir vai ao primeiro. Quem ainda não sabe em que ordem aprender continua indo ao segundo.