Lanzar bkamp.ai con Claude Code me tomó 9 días, y encapsulé ese know-how en el plugin bkit.
(bkit.ai)bkit — Usar Claude Code “como se debe” con Context Engineering
En diciembre de 2025, lancé un servicio llamado bkamp.ai.
- 11 microservicios
- Un portal basado en Next.js
- AWS EKS + GitOps (ArgoCD)
- Infraestructura con Terraform
Y puse todo esto en producción en solo 9 días.
Yo era el único desarrollador,
y para la IA usé Claude Code.
Este artículo no trata de “lo hice rápido”
Muchos casos de desarrollo con IA se explican así:
- “Lo hice con IA en N días”
- “Solo hay que escribir buenos prompts”
Pero lo que sentí realmente durante esos 9 días de desarrollo fue completamente distinto.
Es cierto que la IA programa bien.
Pero la IA no decide qué es lo que hay que programar.
Eso lo determinan, al final:
- el diseño
- las reglas
- las unidades de trabajo
- la forma de validación
A eso yo lo definí como Context Engineering.
Qué es Context Engineering
Dicho de forma simple:
no se trata de escribir buenos prompts,
sino de diseñar el entorno mismo en el que trabaja la IA
Por ejemplo:
- primero crear documentos de diseño
- dividir las unidades de trabajo con base en los documentos
- crear reglas para validar los resultados
- crear un ciclo repetible
Es decir:
la IA deja de ser el “autor”
y se convierte en un motor que renderiza un contexto definido
Cómo lo hice realmente en bkamp
1. Day 0 — Crear reglas antes de escribir código
En el primer commit no había código.
En cambio, creé lo siguiente:
.claude/CLAUDE.md(unas 150 líneas)- documento de requisitos
- documento de estrategia
Ahí quedaron definidas estas cosas:
- ciclo PDCA (Plan → Do → Check → Act)
- todos los resultados se validan por una persona
- planificación en coreano, código en inglés, commits en coreano
- unidades de trabajo y forma de avance
Estas aproximadamente 100 líneas de reglas terminaron determinando todo el desarrollo posterior.
2. La unidad de trabajo no era una “función”, sino un “documento”
Normalmente se pide algo así:
- “Haz una función de chat”
Pero en la práctica trabajé así:
- “Implementa la sección 3.2 del documento 7”
La diferencia es enorme.
Desde la perspectiva de la IA:
- función → requiere interpretación (incertidumbre)
- documento → se implementa tal cual (determinístico)
Como resultado:
la variabilidad de la salida casi desaparece
3. Un día = un ciclo PDCA
El desarrollo avanzaba así:
- Plan (diseño)
- Do (implementación)
- Check (análisis de brechas)
- Act (corrección)
Y este ciclo se repite cada día.
Las ventajas de este enfoque son:
- el contexto siempre se mantiene actualizado
- el alcance del trabajo es claro
- la IA tiene claro “qué debe hacer ahora”
4. Crear checkpoints y rehacer sin miedo
En el día 4 reestructuré por completo el frontend.
Pero antes de eso, hay algo que siempre hago:
- crear un checkpoint al que se pueda volver
Así:
incluso si falla, sigue siendo seguro
→ y es posible hacer cambios estructurales drásticos
5. Integrar la infraestructura al final, de una sola vez
En el día 8, durante un solo día, integré de una vez:
- Terraform
- Kubernetes
- CI/CD
- ArgoCD
La razón por la que esto fue posible es simple:
porque toda la estructura ya estaba alineada desde antes
El patrón clave que saqué de aquí
El patrón que se repitió durante estos 9 días fue el siguiente:
- primero definir las reglas
- primero crear el diseño
- trabajar con base en documentos
- iterar con el ciclo PDCA
- crear checkpoints
- resolver las inconsistencias en los documentos
- el código va al final
Pero, ¿esto se puede mantener en el tiempo?
Y aquí aparece el problema.
Este enfoque es poderoso, pero:
es demasiado pesado para que una persona lo mantenga de forma continua
- hay que seguir recordando las reglas
- hay que seguir manteniendo alineados los documentos
- hay que cumplir PDCA cada vez
Por eso creé bkit.
Qué es bkit
bkit es un plugin para Claude Code.
Pero no es solo una herramienta.
Es la forma de trabajo usada en bkamp convertida tal cual en un sistema
El concepto más importante: PDCA = máquina de estados
En bkit implementé PDCA así:
- estados: plan, design, do, check, act, etc.
- transiciones: reglas para moverse entre estados
- guards: validación de condiciones
Por ejemplo:
- si la tasa de coincidencia entre diseño e implementación es de 90% o más → pasa
- si no → se ejecuta automáticamente un loop de corrección
Es decir:
“revisión → corrección” se repite automáticamente
La estructura que convirtió Context Engineering en un sistema
bkit está compuesto por los siguientes elementos:
- Skills (conocimiento de dominio)
- Agents (comportamiento basado en roles)
- máquina de estados PDCA
- sistema de inyección de contexto
- Quality Gate (validación)
- Audit Log (registro)
- Feedback Loop (iteración automática)
Si hubiera que resumirlo en una sola frase:
no se trata de usar IA,
sino de construir el sistema en el que trabaja la IA
Resultados
Los resultados obtenidos con este enfoque fueron los siguientes:
- compatibilidad continua con 79 versiones de Claude Code
- 4,000+ pruebas, 0 fallas
- 200+ reglas de validación de CI
- sincronización total entre Docs y Code
Conclusión
Esta no es una historia sobre una IA más inteligente.
Es una historia sobre haber adelantado el trabajo humano.
- primero el diseño
- primero las reglas
- primero la validación
Y después:
- la IA ejecuta
- el sistema valida
- la persona aprueba
TL;DR
- solo con prompts hay límites
- Context Engineering es la clave
- la IA no es autora, es renderizadora
- el workflow importa más que el modelo
Enlaces
Si tienes opiniones o feedback sobre este enfoque, serán más que bienvenidos.
Aún no hay comentarios.