Parte V · 7 — Estudo de caso: construindo o Kode
Um exemplo trabalhado de tudo nesta parte aplicado a um produto real: o Kode, o assistente de IA de programação da Koder Stack. Mostra o roadmap de fronteira (alavancas → dados → fine-tuning → RLVR → agente) aterrissado num caso concreto.
🎨 Figura
F-V.7— O flywheel do Kode. Brief: roda de fluxo (data flywheel): uso do Kode → aceites/rejeições → dados de preferência → fine-tuning → Kode melhor → mais uso. Paleta do Compêndio.
7.1 Por que programação é a posição certa
A programação é o melhor domínio para equipe pequena (recompensa verificável, dados filtráveis, feedback curto — ver 06-ia-para-codigo.kmd) mais um ativo que labs generalistas não têm: dados proprietários de interação. Cada sugestão do Kode aceita, rejeitada ou editada é um sinal de preferência de RL "quase grátis" — o mesmo que alimenta Cursor/Codeium contra labs bilionários.
7.2 Pipeline aplicado (segue o roadmap da fronteira)
| Fase | Ação no Kode |
|---|---|
| 0 — Domínio | Go, FlutterDart, TypeScript, NASM + KMDKoder Koda. Diferencial: linguagens com cobertura escassa nos datasets públicos (NASM, KMD) |
| 1 — Baseline | Medir ClaudeGPT-5Qwen2.5-Coder-32B no monorepo Koder; benchmark privado de 50–200 problemas reais |
| 2 — API máxima | Antes de treinar: prompt engineering + RAG sobre a base de código + tool use (já supera modelos menores fine-tunados) |
| 3 — Data flywheel | Coletar aceitesrejeiçõesedições; gerar sintéticos do monorepo (bug→fix de commits reais, Q&A do código, CoTs de arquitetura); filtrar por build+testes |
| 4 — Fine-tuning | SFT → DPO com feedback de devs → RLVR com build/test como recompensa; começar QLoRA de 32B |
| 5 — RLVR de raciocínio | Aplicar o paradigma DeepSeek-R1 ao código Koder (2× RTX 4090/5090, 2–4 semanas) |
| 6 — Multimodalidade | Visão de screenshots de código/UI; diagramas de arquitetura |
| 7 — Agente | Kode como agente: tool use completo, memória de repositório, loop ReAct + sandbox |
7.3 Stack técnico do Kode
| Componente | Escolha |
|---|---|
| Modelo base | Qwen2.5-Coder-32B (ou DeepSeek-Coder-V2-Lite p/ iteração) |
| SFT | Axolotl / LLaMA-Factory · DPO/GRPO TRL · 1 GPU Unsloth |
| Inferência | vLLM (alta concorrência) |
| Sandbox | Docker com limites (nunca fora de sandbox) |
| Eval | SWE-bench runner + benchmark privado Koder |
| Observabilidade | W&B (experimentos), LangFuse (produção) |
7.4 Benchmarks privados — a vantagem defensável
| Benchmark | Conteúdo | Por que vale |
|---|---|---|
| Kode-bench-go | 50–100 problemas Go do monorepo | bugsrefactorsfeatures reais com solução conhecida |
| Kode-bench-flutter | equivalente em Flutter/Dart | — |
| Kode-bench-kmd | geração/edição de KMD | formato proprietário — nenhum modelo público tem dados |
| Kode-bench-agent | tarefas de agente longo-horizonte | issue → implementar → PR → passar CI |
O benchmark KMD é o mais defensável: nenhum modelo público foi treinado com Koder Koda. É onde o Kode pode genuinamente superar GPT-5/Claude Opus 5+ no domínio proprietário.
7.5 PT-BR
Comentários e docs em pt-BR no monorepo são dados de treino valiosos: o Kode deve raciocinar em inglês mas entender e gerar pt-BR naturalmente. Voz: XTTS v2 / Fish Speech cobrem PT-BR. Fine-tuning leve de pt-BR sobre base sólida de código basta — não treinar separado.
7.6 As três mensagens centrais (válidas além do Kode)
- Domínio importa mais que técnica. Os problemas mais valiosos não são de
arquitetura — são onde especialista de domínio + engenheiro de IA constroem algo que nenhum faria sozinho.
- Dados proprietários são a vantagem defensável. Modelos e compute viram
commodity.
- Modelos abertos + fine-tuning + domínio específico é a fórmula vencedora
para equipe pequena. Escolha um nicho, domine-o, deixe os labs cuidarem da fundação.