Pitch: Criei uma plataforma adaptativa de avaliação técnica em 3 dias sem escrever uma linha de código
Spoiler
Se você lidera times técnicos, talvez isso te interesse
Especialmente se você:
monta trilhas de treinamento,
lidera squads,
trabalha com recrutamento técnico,
faz gestão de maturidade,
ou simplesmente quer entender onde estão os gaps reais do time.
A ferramenta está online gratuitamente para quem quiser usar com
equipes,
alunos,
bootcamps,
estudos,
comunidades,
ou laboratórios internos.
E honestamente? Estou muito curioso para descobrir quais usos outras pessoas vão encontrar para ela.
Porque a sensação que tive construindo isso foi:
eu comecei fazendo um quiz…
Versão longa do artigo?
Senta que lá vem história...
Tem uma coisa que sempre me incomodou em times de tecnologia:
a gente normalmente sabe quem é bom, mas quase nunca consegue identificar com precisão:
onde estão os silos de conhecimento,
quais ferramentas um time domina de verdade,
quais tópicos estão frágeis,
e principalmente:
No meu caso isso apareceu muito forte em DevOps.
Às vezes o time parecia “maduro”, mas quando você quebrava por assunto:
Kubernetes → excelente
Observabilidade → média
Terraform → fraco
Troubleshooting → muito inconsistente
Conceitos → fortes
Operação prática → fraca
E aí vinha o problema mais difícil:
como transformar isso em algo mensurável sem virar uma prova chata de faculdade corporativa?
Foi aí que nasceu o Mastery Tiers.
A ideia inicial era bem menor
Eu só queria um sistema simples para:
gerar perguntas,
enviar para os times,
e visualizar os gaps.
Mas durante o desenvolvimento comecei a perceber uma coisa:
questionários tradicionais são ruins para medir conhecimento técnico.
Porque normalmente:
são longos,
cansativos,
desbalanceados,
e tratam um senior e um iniciante exatamente da mesma forma.
Então comecei a pedir para os agentes criarem uma engine adaptativa.
E honestamente? Foi aí que o projeto começou a ficar interessante.
O sistema virou uma “engine adaptativa” sem eu perceber
Hoje a plataforma funciona mais ou menos assim:
- Ela faz uma pergunta inicial de descoberta
- Dependendo da resposta, estima um tier inicial
- A dificuldade vai se ajustando dinamicamente
- O sistema mistura: teoria, prática, troubleshooting, análise de código
- No final ele gera um mapa granular das habilidades
E o mais legal: isso funciona por foco específico.
Daí eu posso enviar as avaliações para cada membro de um time e então eu consigo ter:
- Visão micro → indivíduo
- Visão macro → time inteiro
E isso era exatamente o que eu precisava para conversar com o CTO da empresa.
Porque ao invés de dizer:
“acho que precisamos melhorar Kubernetes”
eu consigo dizer:
*“o time A domina operação, mas falha em troubleshooting avançado; o time B tem deficiência conceitual em observabilidade; e o time C está forte em IaC mas fraco em networking.” *
A conversa muda completamente.
A parte mais divertida: eu literalmente não escrevi o código
Esse talvez seja o detalhe mais absurdo do projeto.
Eu não escrevi. Eu não revisei. E até agora eu não li linha por linha do código.
O projeto inteiro foi feito usando agentes.
O fluxo foi:
comecei no AI Studio da Google,
depois baixei o código,
continuei usando OpenCode,
e finalizei refinando no Claude.
E o mais curioso: o produto foi evoluindo conforme as ideias surgiam.
Eu começava pedindo algo simples e ia percebendo:
“hmm… e se ele adaptasse o tier?”
E os agentes iam construindo incrementalmente.
Foram 3 dias intensos de trabalho. Mas não foi aquele tipo de projeto onde você refatora tudo 15 vezes.
Foi quase totalmente evolutivo.
Acho que ter bastante experiência prévia com software ajudou muito nisso. Mesmo sem codar diretamente, eu já sabia:
o que pedir,
como estruturar,
onde estavam os riscos,
e como transformar ideia em fluxo de produto.
A sensação foi menos “programar” e mais:
dirigir um time infinito de estagiários extremamente rápidos.
A plataforma ficou estranhamente séria
O mais engraçado é que eu achei que ia sair um protótipo meio improvisado.
Mas acabou virando algo relativamente robusto:
painel administrativo,
geração de perguntas via LLM,
revisão humana,
export/import,
sessões adaptativas,
radar de habilidades,
analytics por equipe,
contestação de perguntas,
deduplicação por sessão,
validação automática de integridade,
e uma matriz 2D de dificuldade.
Inclusive uma das coisas que mais gostei foi separar:
profundidade do conhecimento (tiers)
da natureza da habilidade
Porque alguém pode:
saber teoria,
mas não troubleshooting.
Ou:
operar bem,
mas não entender arquitetura.
Então as perguntas foram divididas em:
H1 → conceitual
H2 → prática
H3 → troubleshooting/avançado
Isso gerou análises muito mais interessantes do que eu imaginava.
Hoje ele está focado em DevOps… mas a engine serve para qualquer coisa
Nesse momento eu só alimentei a plataforma com perguntas de DevOps.
Porque era minha dor real.
Mas a arquitetura em si é completamente genérica.
Daria para usar para:
backend,
frontend,
segurança,
dados,
IA,
SRE,
suporte,
redes,
cloud,
ou literalmente qualquer domínio técnico.
A plataforma começa vazia. Você cria:
os domínios,
os focos,
os tiers,
e as questões.
Ela é muito mais uma “engine de avaliação adaptativa” do que um produto preso a DevOps.
O plano é abrir tudo como open source
Minha intenção é publicar o projeto inteiro open source.
Mas antes quero revisar algumas coisas com calma.
Principalmente:
possíveis falhas de segurança,
segredos expostos,
credenciais esquecidas,
lixo de desenvolvimento,
e decisões meio suspeitas que agentes adoram tomar quando você não está olhando.
Como tudo foi feito em vibe coding puro, achei melhor não fazer aquele deploy kamikaze de:
“subi no GitHub e seja o que Deus quiser”.
Então estou passando por uma etapa de saneamento antes de abrir o repositório.
O que mais me chamou atenção nisso tudo
Acho que a maior mudança foi perceber que:
a velocidade de transformar ideia em software ficou absurda.
Mas também ficou muito mais importante:
saber estruturar problemas,
entender produto,
pensar fluxo,
identificar gargalos,
e saber conversar com agentes.
Porque honestamente: o código virou quase um detalhe.
A parte difícil foi descobrir:
o que realmente medir,
como medir,
e como transformar conhecimento técnico em sinais úteis para tomada de decisão.
É isso aí rapaziada. Até mais...