Disclaimer
Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de um vídeo do canal Dev Eficiente, apresentado por Alberto Souza. Se preferir acompanhar por vídeo, é só dar o play.
Introdução
Neste post eu quero mostrar como você pode construir um treinamento sob medida para alcançar um objetivo de aprendizagem que você tenha, independente da complexidade, usando apenas a documentação ou uma referência que você entenda como fonte da verdade daquele conhecimento.
Os cenários de uso são muitos. Você quer entender melhor um módulo específico de um framework, como o Spring AI, para construir as suas aplicações. Quer se aprofundar em LangChain para montar sistemas que usam LLM como componente. Quer saber como usar Kafka em um ambiente de alta volumetria de mensagens e como lidar com perda ou não processamento de mensagem. Ou está começando no mundo de infraestrutura e quer ficar mais confortável configurando o seu ambiente via Docker. Para todos esses casos, o framework que vou apresentar serve, e você pode aplicar hoje mesmo, com o tema que quiser.
A execução é feita por um agente de código. No meu caso, uso o Claude Code, mas qualquer ferramenta com um loop mais autônomo funciona: eu dou a entrada, ele itera e monta o material. O que importa aqui é o framework, não a ferramenta.
O framework para criar o treinamento
Eu mantenho um arquivo que descreve o framework e sirvo esse arquivo como contexto para o agente. Ele tem algumas partes.
1. As referências que formam a fonte da verdade
Primeira parte: definir o conjunto de referências que representa a fonte da verdade do conhecimento que você quer conquistar. Quando o tema é uma tecnologia, a referência geralmente é a documentação oficial, ou um conjunto de links dela.
Mas o tema pode ser mais aberto. Se você quer entender como construir sistemas realmente resilientes, não existe uma entidade dona da explicação de como se faz isso. Nesse caso, você precisa fazer uma curadoria: montar uma referência bibliográfica que, por algum motivo, faz sentido para você. E aí o treinamento é construído em cima daquele objetivo e daquela bibliografia.
2. Inspiração para os exercícios
Segunda parte, opcional: um dataset com exemplos do nível que você quer alcançar. Imagine que você trabalha em um conjunto de serviços com queries SQL realmente complexas, e o seu conhecimento hoje não é suficiente para escrevê-las com confiança. Ou que o sistema onde você atua tem muita generalização e você quer ser capaz de construir componentes generalizáveis seguindo as práticas que já existem na empresa. Você pode fornecer ao agente um conjunto de repositórios com exemplos do que você quer ser capaz de fazer. Eu falei código, mas pode ser exemplo de qualquer coisa que represente o nível que você quer atingir.
Se você não tem esse dataset, está tudo bem. O agente deriva os exercícios a partir das fontes teóricas que você referenciou.
3. Progressão com variabilidade
A minha principal inspiração para criar treinamentos vem do esporte. Se você olhar o histórico de qualquer treino físico, sempre há progressão. Pense em treino de força: você quer agachar, tem uma progressão de carga ao longo do tempo, e dentro daquela progressão existem outros exercícios, muitas vezes auxiliares, para que você agache melhor.
Quando o assunto é conquistar um conhecimento para aplicá-lo, geralmente existe variabilidade de cenários de aplicação. Por isso é importante pensar na progressão e, dentro de cada estágio, pensar em variabilidade de exercícios: aplicar o mesmo conhecimento em situações diferentes treina a sua mente para reconhecer padrões e escolher o que precisa ser feito em cada momento.
Essa costuma ser a parte mais difícil para quem está mais distante da engenharia da aprendizagem: como pensar a progressão. Então isso faz parte do framework, e é a partir dela que os exercícios são construídos.
O meu número de variabilidade é três exercícios por estágio. Não é resultado de pesquisa; é totalmente empírico. A minha experiência diz que, se você fez a mesma coisa em três cenários diferentes, geralmente fica em condições de lidar com o quarto, o quinto e o sexto cenário, porque a cada repetição refina as heurísticas de qual caminho seguir em função do que aparece.
4. Leitura, tentativa e proposta de solução para cada exercício
Uma abordagem que eu acho interessante, dependendo do quão confortável você está com jornadas de estudo, é organizar tudo em torno dos exercícios. Para cada exercício, o treinamento traz os links das referências que você deveria ler para conseguir resolvê-lo. Você lê, volta e tenta fazer. Fica nesse pingue-pongue entre teoria e prática.
Se você prefere tentar antes de ler, também não tem problema, porque cada exercício vem com uma proposta de solução para você comparar o que fez com o que deveria ter sido feito. Isso é o feedback possível quando você não tem acesso a uma pessoa especialista, o que a gente chama de automonitoramento no processo de aprendizagem. Você fez, ficou diferente da solução, e aí pergunta por quê. Não necessariamente está errado. Em uma tecnologia bem específica como Docker, se você não fez de determinado jeito talvez nem funcione. Mas quando o assunto é design de código, existem variações válidas, e a ideia é que você compare e reflita. Ter múltiplos momentos de reflexão é o que faz o conhecimento entrar e ficar armazenado de um jeito que facilita a recuperação depois.
5. O objetivo de aprendizagem
Aqui está o elemento mais importante da jornada, e é a entrada principal do agente. Falo isso no Máquina de Aprender, o treinamento que temos dentro do Dev + Eficiente para você construir a sua jornada de aprendizagem de maneira autônoma. O objetivo de aprendizagem é o pino no mapa: é onde você quer chegar. Sem ele, você corre o risco de ficar estudando um monte de coisa aberta sem necessariamente chegar aonde queria.
Descreva o que você quer ser capaz de fazer, em que tipo de situação vai usar aquilo e, se souber com nitidez, qual é o seu ponto de parada.
A demonstração: um treinamento de Docker para ambiente de desenvolvimento
Para mostrar o framework funcionando, escolhi um tema em que eu mesmo não sou forte. Não sou a pessoa que monta infraestrutura com Docker; costumo seguir o que já está feito ou pedir para um LLM gerar o que preciso quando estou em uma empreitada solo. Então montei um treinamento chamado Docker Dev Essencial.
O objetivo de aprendizagem que dei como entrada foi algo assim: quero ser capaz de montar um ambiente de desenvolvimento onde tudo que tem a ver com infraestrutura roda em containers. Se precisa de banco de dados, é via Docker. Se precisa de broker de mensageria, é via Docker. Tudo isso deve ser acessível para as minhas aplicações. Para determinadas situações, como banco de dados, preciso de persistência dos dados entre as execuções. E, se possível, quero também estar capacitado para configurar isso de maneira otimizada, minimizando o tempo de espera enquanto subo tudo.
Como fontes teóricas, apenas a documentação oficial do Docker. Nada além disso. Se quero aprender estritamente sobre Docker, é lá que está a fonte mais confiável.
Rodei o agente pedindo para ler o arquivo do framework e o meu objetivo, e deixei ir direto, sem confirmações intermediárias a cada progressão. O resultado ficou assim:
- Nível 1, fundamentos de container. Um README com o objetivo do nível (rodar serviços em containers com confiança, entender o que é imagem e container, dominar o ciclo de vida), os conceitos-chave (imagem, container, efemeridade), referências de leitura apontando para a documentação oficial (o que é um container, o que é uma imagem, o que é um registro, como rodar e como sobrescrever o padrão) e três exercícios: o seu primeiro serviço em um container, um Postgres descartável e "o que sobrevive?". Cada um com a sua proposta de solução: rodar em foreground, rodar em modo detached, listar, pegar log, testar se o serviço está no ar, verificar o ciclo de vida, limpar.
- Nível 2, expondo serviços ao host. Mesmo esquema: objetivo do nível, conceitos-chave, referências e três exercícios. Como eu não dei um dataset de referência, o agente criou os cenários: abrir portas, um banco para uma API, um broker com painel, containers que conversam entre si.
- Nível 3, persistência de dados. O objetivo do nível é resolver de vez o problema descoberto no nível 1: dados de banco precisam sobreviver à recriação de containers. Conceitos-chave: volumes nomeados, bind mount, volume anônimo. As referências de leitura levam direto para a página da documentação sobre persistência de dados, onde você pode ler a explicação ou assistir ao vídeo, como preferir.
- Projeto final. Consolidar tudo em uma entrega única e realista: construir do zero, sem consultar os composes dos níveis anteriores, consultando a documentação oficial à vontade, como no mundo real, o ambiente de desenvolvimento completo de uma empresa fictícia. E uma frase que eu achei importante: este é o nível de atuação descrito no objetivo de aprendizagem do treinamento; se você completa o projeto com os critérios de aceite verdes, o objetivo foi atingido.
O marco que fecha a jornada
Essa última parte merece destaque. Você não quer fazer um conjunto de cursos; você quer conquistar um conhecimento. Estou pensando aqui no que costumo chamar de aprendizagem transacional, ou utilitária: você não está estudando só porque quer, está estudando porque tem um objetivo, que é ser capaz de fazer alguma coisa.
Então é importante que exista esse marco. Não necessariamente na forma de um projeto final, mas a sua jornada de estudo precisa te levar até o objetivo de aprendizagem. Tudo faz muito mais sentido quando você entende o porquê do esforço, e isso costuma ter um papel importante na sua motivação.
Sobre fontes: confiabilidade e facilidade de consumo
No treinamento de Docker eu deixei apenas fontes de confiabilidade máxima. Mas vale um comentário. Quando eu seleciono fontes de estudo, olho por duas dimensões: confiabilidade e facilidade de consumo. No início de uma jornada, quando você tem pouco background, textos mais densos e menos organizados para facilitar o entendimento pesam mais. Nesses casos, dá para misturar fontes mais palatáveis, mesmo que menos confiáveis, desde que a referência bibliográfica contenha as fontes mais confiáveis. Aqui, escolhi manter só a documentação.
E isso conecta com uma escolha nossa dentro do Dev + Eficiente: em geral, não construímos treinamentos ensinando algo que já está documentado. Um treinamento de Spring AI, no formato "como usar Spring AI", seria um desserviço para um público que quer ser crítico e ter autonomia para aprender o que precisa, porque a documentação já cumpre esse papel, escrita por quem construiu a ferramenta. Quando temos um treinamento envolvendo uma tecnologia, ele é sobre as práticas que consideramos interessantes com aquela tecnologia, que vão além do que está lá. É o caso do treinamento que lançamos sobre as nossas práticas usando um agente de código no dia a dia: é a minha história, o meu jeito de organizar, os cenários que eu uso, e nada disso está documentado porque tem a ver com a minha opinião. É por isso que dizemos que os nossos cursos são opinionados.
Conclusão
O framework é simples: defina o objetivo de aprendizagem, aponte as referências que formam a fonte da verdade, forneça exemplos do nível que você quer alcançar se tiver, e deixe o agente montar uma progressão com variabilidade de exercícios, cada um com as leituras necessárias e uma proposta de solução para comparar. Feche com um marco que corresponda ao objetivo. Depois é só executar, no formato e no ritmo que a sua vida permite.
Espero que você explore esse framework para criar o treinamento que quiser, dado o objetivo que você tem. E se quiser se aprofundar em como estruturar jornadas de aprendizagem de maneira autônoma, esse é o tema do Máquina de Aprender, disponível dentro do Dev + Eficiente.
Dev + Eficiente
Desenvolva software de alta qualidade e domine Engenharia de IA com o Dev + Eficiente. Cursos práticos, acesso vitalício, comunidade ativa e acesso a vagas remotas exclusivas em diversas empresas de tecnologia. Sua jornada para se tornar um dev mais eficiente pode começar agora.
Top comments (0)