Levei 9 dias para lançar o bkamp.ai com Claude Code, e transformei esse know-how no plugin bkit.
(bkit.ai)bkit — Usando o Claude Code “do jeito certo” com Context Engineering
Em dezembro de 2025, lancei um serviço chamado bkamp.ai.
- 11 microsserviços
- Portal baseado em Next.js
- AWS EKS + GitOps (ArgoCD)
- Infraestrutura com Terraform
E coloquei tudo isso em produção em apenas 9 dias.
O único desenvolvedor era eu,
e para IA usei o Claude Code.
Este texto não é sobre “construí rápido”
Muitos casos de desenvolvimento com IA são explicados assim:
- “Fiz com IA em N dias”
- “Basta saber escrever bons prompts”
Mas o que senti de fato ao desenvolver durante 9 dias foi completamente diferente.
É verdade que a IA escreve código bem.
Mas a IA não decide o que deve ser escrito.
Quem decide isso, no fim, é:
- arquitetura
- regras
- unidade de trabalho
- forma de validação
Eu defini isso como Context Engineering.
O que é Context Engineering
Em termos simples:
não é escrever bem o prompt,
e sim projetar o próprio ambiente em que a IA trabalha
Por exemplo:
- criar primeiro a documentação de arquitetura
- dividir as unidades de trabalho com base na documentação
- criar regras para validar os resultados
- criar um ciclo repetível
Ou seja,
a IA deixa de ser uma “autora”
e passa a ser um motor que renderiza um contexto definido
Como isso foi feito na prática no bkamp
1. Day 0 — criar regras antes de escrever código
No primeiro commit não havia código.
Em vez disso, criei:
.claude/CLAUDE.md(cerca de 150 linhas)- documento de requisitos
- documento de estratégia
Ali estavam definidos:
- ciclo PDCA (Plan → Do → Check → Act)
- todo resultado é validado por humano
- planejamento em coreano, código em inglês, commit em coreano
- unidades de trabalho e forma de execução
Essas cerca de 100 linhas de regras determinaram todo o desenvolvimento dali em diante.
2. A unidade de trabalho não é “funcionalidade”, e sim “documento”
Normalmente o pedido seria assim:
- “Crie uma funcionalidade de chat”
Mas, na prática, trabalhei assim:
- “Implemente a seção 3.2 do documento 7”
Essa diferença é enorme.
Do ponto de vista da IA:
- funcionalidade → exige interpretação (incerteza)
- documento → implementar como está (determinístico)
Como resultado:
a variabilidade da saída praticamente desaparece
3. Um dia = um ciclo PDCA
O desenvolvimento avança assim:
- Plan (arquitetura)
- Do (implementação)
- Check (análise de gap)
- Act (correção)
E esse ciclo é repetido diariamente.
As vantagens dessa abordagem são:
- o contexto se mantém sempre atualizado
- o escopo do trabalho fica claro
- a IA entende claramente “o que precisa fazer agora”
4. Criar checkpoints e refatorar sem medo
No quarto dia, reestruturei completamente o frontend.
Mas antes disso, há algo que sempre faço:
- criar um checkpoint que permita rollback
Assim:
mesmo se falhar, continua seguro
→ torna possível fazer mudanças estruturais ousadas
5. A infraestrutura entra toda de uma vez no final
No oitavo dia, em um único dia:
- Terraform
- Kubernetes
- CI/CD
- ArgoCD
foram integrados de uma só vez.
O motivo de isso ser possível é simples:
porque toda a estrutura já estava alinhada antes disso
O padrão central obtido aqui
O padrão repetido durante esses 9 dias foi o seguinte:
- definir primeiro as regras
- criar primeiro a arquitetura
- trabalhar com base na documentação
- iterar com o ciclo PDCA
- criar checkpoints
- resolver inconsistências na documentação
- o código vem por último
Mas será que dá para manter isso no longo prazo?
É aqui que surge o problema.
Essa abordagem é poderosa, mas:
é cansativa demais para uma pessoa manter continuamente
- é preciso lembrar das regras o tempo todo
- é preciso manter a documentação sempre alinhada
- é preciso seguir o PDCA em toda rodada
Por isso criei o bkit.
O que é o bkit
O bkit é um plugin do Claude Code.
Mas não é apenas uma ferramenta simples.
é a transformação direta em sistema
da forma de trabalhar usada no bkamp
O conceito mais importante: PDCA = máquina de estados
No bkit, implementei o PDCA assim:
- estados: plan, design, do, check, act etc.
- transições: regras de movimentação entre estados
- guards: verificação de condições
Por exemplo:
- taxa de aderência entre arquitetura e implementação acima de 90% → aprovado
- caso contrário → execução automática do loop de correção
Ou seja,
“revisar → corrigir” se repete automaticamente
A estrutura que transformou Context Engineering em sistema
O bkit é composto pelos seguintes elementos:
- Skills (conhecimento de domínio)
- Agents (comportamento baseado em papéis)
- máquina de estados PDCA
- sistema de injeção de contexto
- Quality Gate (validação)
- Audit Log (registro)
- Feedback Loop (repetição automática)
Se resumir isso em uma frase:
não se trata de usar IA,
e sim de construir o sistema em que a IA trabalha
Resultado
Os resultados obtidos com essa abordagem foram os seguintes:
- compatibilidade contínua com 79 versões do Claude Code
- 4.000+ testes, 0 falhas
- 200+ regras de validação em CI
- sincronização completa entre Docs e Code
Conclusão
Esta não é uma história sobre a IA ter ficado mais inteligente.
é uma história sobre o trabalho humano ter sido trazido para mais cedo no processo
- arquitetura primeiro
- regras primeiro
- validação primeiro
Depois disso:
- a IA executa
- o sistema valida
- o humano aprova
TL;DR
- só prompt tem limite
- Context Engineering é o ponto central
- a IA não é autora, é renderizadora
- o workflow é mais importante que o modelo
Links
Se você tiver opiniões ou feedback sobre essa abordagem, serão muito bem-vindos.
Ainda não há comentários.