313 lines
9.8 KiB
Markdown
313 lines
9.8 KiB
Markdown
|
# Portfolio IA: Desarrollo Inteligente de Principio a Fin
|
||
|
|
|
||
|
|
## El Problema
|
||
|
|
|
||
|
|
Los equipos de desarrollo enfrentan desafíos críticos al integrar IA en sus flujos de trabajo:
|
||
|
|
|
||
|
|
- **Conocimiento disperso**: Decisiones en Slack, patterns en wikis, guidelines en docs separados
|
||
|
|
- **Agentes IA sin contexto**: Generan código que ignora las convenciones del proyecto
|
||
|
|
- **Costos LLM descontrolados**: Sin visibilidad ni límites por equipo o tarea
|
||
|
|
- **Infraestructura manual**: Configuración repetitiva que consume tiempo valioso
|
||
|
|
- **Interfaces fragmentadas**: Una herramienta para CLI, otra para web, otra para TUI
|
||
|
|
|
||
|
|
## La Solución: Un Ecosistema Integrado
|
||
|
|
|
||
|
|
Cinco proyectos diseñados para trabajar juntos, cada uno resolviendo un problema específico.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Vapora: Orquestación Inteligente de Agentes
|
||
|
|
|
||
|
|
### Agentes que Aprenden de la Experiencia
|
||
|
|
|
||
|
|
Vapora no es otro framework de agentes. Es un sistema que **aprende qué agente es mejor para cada tarea** basándose en ejecuciones previas.
|
||
|
|
|
||
|
|
**Cómo funciona**:
|
||
|
|
|
||
|
|
- Cada ejecución construye un perfil de expertise por tipo de tarea
|
||
|
|
- Las últimas 7 días pesan 3x más que el histórico (recency bias)
|
||
|
|
- Los agentes nuevos no se sobreponen a los experimentados (confidence weighting)
|
||
|
|
|
||
|
|
**Control de costos real**:
|
||
|
|
|
||
|
|
- Presupuestos por rol (mensual/semanal)
|
||
|
|
- Tres niveles: normal → cerca del límite → excedido
|
||
|
|
- Fallback automático a proveedores más baratos sin intervención manual
|
||
|
|
|
||
|
|
**Para quién**:
|
||
|
|
|
||
|
|
- Equipos que usan múltiples agentes IA para desarrollo
|
||
|
|
- Organizaciones que necesitan controlar gastos LLM
|
||
|
|
- Proyectos con pipelines de código (architect → developer → reviewer → tester)
|
||
|
|
|
||
|
|
**Resultados esperados**:
|
||
|
|
|
||
|
|
- Reducción de costos LLM mediante routing inteligente
|
||
|
|
- Mejora en calidad de outputs al asignar agentes según expertise
|
||
|
|
- Visibilidad completa de gastos y rendimiento por agente
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Kogral: El Conocimiento del Equipo, Queryable
|
||
|
|
|
||
|
|
### Tu Base de Conocimiento con IA Integrada
|
||
|
|
|
||
|
|
Kogral captura las decisiones, patterns y guidelines de tu equipo en un formato que tanto humanos como agentes IA pueden consultar.
|
||
|
|
|
||
|
|
**Qué lo hace diferente**:
|
||
|
|
|
||
|
|
- **6 tipos de nodo especializados**: Notes, Decisions (ADRs), Guidelines, Patterns, Journals, Executions
|
||
|
|
- **Git-native**: Todo en markdown versionado, no en un SaaS externo
|
||
|
|
- **MCP para Claude Code**: Tus agentes consultan guidelines antes de generar código
|
||
|
|
|
||
|
|
**El flujo**:
|
||
|
|
```text
|
||
|
|
Desarrollador toma decisión → Captura en Kogral como ADR
|
||
|
|
↓
|
||
|
|
Claude Code consulta via MCP → "¿Hay guidelines para auth?"
|
||
|
|
↓
|
||
|
|
Kogral responde con contexto del proyecto
|
||
|
|
↓
|
||
|
|
Código generado sigue convenciones del equipo
|
||
|
|
```
|
||
|
|
|
||
|
|
**Para quién**:
|
||
|
|
|
||
|
|
- Equipos que pierden conocimiento cuando rotan miembros
|
||
|
|
- Organizaciones con multiple proyectos que necesitan guidelines consistentes
|
||
|
|
- Desarrolladores usando Claude Code que quieren contexto del proyecto
|
||
|
|
|
||
|
|
**Resultados esperados**:
|
||
|
|
|
||
|
|
- Onboarding de nuevos miembros en días, no semanas
|
||
|
|
- Código generado por IA que respeta convenciones
|
||
|
|
- Decisiones arquitectónicas preservadas y buscables
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## TypeDialog: Una Definición, Seis Interfaces
|
||
|
|
|
||
|
|
### Formularios que Funcionan en Todas Partes
|
||
|
|
|
||
|
|
Define un formulario una vez en TOML. Ejecútalo en CLI, TUI, Web, o deja que un agente IA lo complete.
|
||
|
|
|
||
|
|
**Backends disponibles**:
|
||
|
|
|
||
|
|
| Backend | Uso típico |
|
||
|
|
| --------- | ----------- |
|
||
|
|
| **CLI** | Scripts de automatización, CI/CD |
|
||
|
|
| **TUI** | Herramientas de administración, dashboards terminal |
|
||
|
|
| **Web** | Aplicaciones SaaS, formularios públicos |
|
||
|
|
| **AI** | Búsqueda semántica, RAG sobre documentación |
|
||
|
|
| **Agent** | Ejecución de agentes desde archivos .agent.mdx |
|
||
|
|
| **Prov-gen** | Generación de infraestructura multi-cloud |
|
||
|
|
|
||
|
|
**El flujo**:
|
||
|
|
|
||
|
|
```text
|
||
|
|
employee_onboarding.toml
|
||
|
|
↓
|
||
|
|
TypeDialog
|
||
|
|
↓
|
||
|
|
┌───────┬───────┬───────┐
|
||
|
|
CLI TUI Web Agent
|
||
|
|
│ │ │ │
|
||
|
|
▼ ▼ ▼ ▼
|
||
|
|
Mismo resultado validado con Nickel contracts
|
||
|
|
|
||
|
|
```
|
||
|
|
|
||
|
|
**Para quién**:
|
||
|
|
|
||
|
|
- Equipos que mantienen la misma lógica en CLI y Web
|
||
|
|
- DevOps que necesitan wizards de configuración
|
||
|
|
- Organizaciones con formularios multi-idioma
|
||
|
|
|
||
|
|
**Resultados esperados**:
|
||
|
|
|
||
|
|
- Una sola definición para todas las interfaces
|
||
|
|
- Validación tipada antes de runtime
|
||
|
|
- Formularios que ejecutan agentes LLM directamente
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Provisioning: Infraestructura con IA
|
||
|
|
|
||
|
|
### IaC Declarativo + Generación Asistida
|
||
|
|
|
||
|
|
Provisioning combina la precisión de configuración tipada (Nickel) con asistencia IA para generar y validar infraestructura.
|
||
|
|
|
||
|
|
**Capacidades únicas**:
|
||
|
|
|
||
|
|
- **Nickel IaC**: Configuración tipada con lazy evaluation, no YAML
|
||
|
|
- **MCP Server**: Consultas en lenguaje natural sobre infraestructura
|
||
|
|
- **RAG integrado**: 1,200+ documentos de dominio para respuestas contextuales
|
||
|
|
- **Multi-cloud**: AWS, UpCloud, local desde la misma definición
|
||
|
|
|
||
|
|
**Seguridad enterprise**:
|
||
|
|
|
||
|
|
- JWT + MFA (TOTP + WebAuthn)
|
||
|
|
- Cedar policy engine para RBAC
|
||
|
|
- 7 años retención de audit logs
|
||
|
|
- 5 backends KMS (RustyVault, Age, AWS KMS, Vault, Cosmian)
|
||
|
|
|
||
|
|
**El flujo**:
|
||
|
|
```text
|
||
|
|
"Necesito un cluster K8s en AWS con 3 nodos"
|
||
|
|
↓
|
||
|
|
MCP Server (NLP)
|
||
|
|
↓
|
||
|
|
RAG busca configuraciones similares
|
||
|
|
↓
|
||
|
|
Genera Nickel + valida tipos
|
||
|
|
↓
|
||
|
|
Orchestrator despliega con rollback
|
||
|
|
```
|
||
|
|
|
||
|
|
**Para quién**:
|
||
|
|
|
||
|
|
- Equipos DevOps que quieren IaC tipado, no YAML frágil
|
||
|
|
- Organizaciones multi-cloud (AWS + otros)
|
||
|
|
- Equipos que necesitan audit y compliance
|
||
|
|
|
||
|
|
**Resultados esperados**:
|
||
|
|
|
||
|
|
- Errores de configuración detectados en compilación, no en runtime
|
||
|
|
- Infraestructura generada desde lenguaje natural
|
||
|
|
- Rollback automático ante fallos
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## SECRETUMVAULT: Secretos con Criptografía Post-Cuántica
|
||
|
|
|
||
|
|
### El Primer Vault Rust con PQC en Producción
|
||
|
|
|
||
|
|
SecretumVault es un sistema de gestión de secretos que implementa **criptografía post-cuántica lista para producción** (ML-KEM-768, ML-DSA-65).
|
||
|
|
|
||
|
|
**Criptografía agnóstica**:
|
||
|
|
|
||
|
|
- **OpenSSL**: RSA, ECDSA, AES-256-GCM (compatibilidad clásica)
|
||
|
|
- **OQS (Post-Quantum)**: ML-KEM-768, ML-DSA-65 (NIST FIPS 203/204)
|
||
|
|
- **Backends conectables**: Cambia algoritmos sin modificar código
|
||
|
|
|
||
|
|
**Motores de secretos**:
|
||
|
|
|
||
|
|
| Motor | Capacidad |
|
||
|
|
| ------- | ----------- |
|
||
|
|
| **KV** | Almacenamiento versionado de secretos |
|
||
|
|
| **Transit** | Encryption-as-a-service con rotación de claves |
|
||
|
|
| **PKI** | Generación de certificados X.509 |
|
||
|
|
| **Database** | Credenciales dinámicas con TTL |
|
||
|
|
|
||
|
|
**Storage multi-backend**:
|
||
|
|
|
||
|
|
- Filesystem (desarrollo, single-node)
|
||
|
|
- etcd (Kubernetes, alta disponibilidad)
|
||
|
|
- SurrealDB (queries complejas, time-series)
|
||
|
|
- PostgreSQL (enterprise, ACID)
|
||
|
|
|
||
|
|
**Seguridad enterprise**:
|
||
|
|
|
||
|
|
- Shamir Secret Sharing para unsealing
|
||
|
|
- Cedar policy engine (ABAC)
|
||
|
|
- TLS/mTLS nativo
|
||
|
|
- Audit logging completo
|
||
|
|
|
||
|
|
**Para quién**:
|
||
|
|
|
||
|
|
- Equipos desplegando criptografía post-cuántica hoy
|
||
|
|
- Organizaciones con requisitos de agilidad criptográfica
|
||
|
|
- Plataformas multi-cloud que necesitan gestión de secretos Rust-native
|
||
|
|
|
||
|
|
**Resultados esperados**:
|
||
|
|
|
||
|
|
- Preparación para amenazas cuánticas sin cambiar arquitectura
|
||
|
|
- Gestión de secretos con garantías de memoria de Rust
|
||
|
|
- Integración nativa con el ecosistema (Provisioning, Vapora)
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## El Ecosistema en Acción
|
||
|
|
|
||
|
|
### Escenario: Nuevo Feature con IA
|
||
|
|
|
||
|
|
```text
|
||
|
|
1. Kogral proporciona guidelines y patterns a Claude Code via MCP
|
||
|
|
2. Vapora coordina agentes: Architect diseña → Developer implementa → Reviewer valida
|
||
|
|
3. TypeDialog captura configuraciones necesarias con validación Nickel
|
||
|
|
4. SecretumVault gestiona credenciales y secretos del feature
|
||
|
|
5. Kogral registra decisiones tomadas durante el desarrollo
|
||
|
|
6. Provisioning despliega cambios de infraestructura requeridos
|
||
|
|
```
|
||
|
|
|
||
|
|
### Escenario: Onboarding de Nuevo Desarrollador
|
||
|
|
|
||
|
|
```text
|
||
|
|
1. Kogral exporta knowledge graph del proyecto
|
||
|
|
2. TypeDialog presenta quiz interactivo sobre arquitectura
|
||
|
|
3. Vapora asigna tareas de onboarding progresivas
|
||
|
|
4. Provisioning configura entorno de desarrollo automáticamente
|
||
|
|
```
|
||
|
|
|
||
|
|
### Escenario: Migración Multi-Cloud
|
||
|
|
|
||
|
|
```text
|
||
|
|
1. Kogral documenta ADRs de la migración
|
||
|
|
2. TypeDialog valida parámetros de configuración
|
||
|
|
3. Provisioning ejecuta migración con checkpoints
|
||
|
|
4. Vapora orquesta agentes para monitoreo y reportes
|
||
|
|
```
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Por Qué Elegir Este Ecosistema
|
||
|
|
|
||
|
|
### Frente a Alternativas
|
||
|
|
|
||
|
|
| Nosotros | Alternativas |
|
||
|
|
| ---------- | -------------- |
|
||
|
|
| **Rust nativo**: Rendimiento, sin GC, type-safe | Python: GIL, typing opcional |
|
||
|
|
| **Nickel configs**: Validación pre-runtime | YAML/JSON: Errores en runtime |
|
||
|
|
| **Aprendizaje de ejecuciones**: Agentes mejoran | LangChain: Chains estáticos |
|
||
|
|
| **MCP integrado**: Contexto para Claude Code | Sin integración nativa |
|
||
|
|
| **Budget control**: Fallback automático | Control manual de costos |
|
||
|
|
| **Multi-tenant nativo**: SurrealDB scopes | Aislamiento manual |
|
||
|
|
|
||
|
|
### Inversión Técnica
|
||
|
|
|
||
|
|
| Métrica | Valor |
|
||
|
|
| --------- | ------- |
|
||
|
|
| Crates Rust | 40+ |
|
||
|
|
| Tests | 4,360+ |
|
||
|
|
| Líneas de código | ~206K |
|
||
|
|
| Proveedores LLM | Claude, OpenAI, Gemini, Ollama |
|
||
|
|
| MCP Tools | 14+ |
|
||
|
|
| Backends crypto | OpenSSL, OQS (PQC), AWS-LC |
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Comenzar
|
||
|
|
|
||
|
|
### Adopción Progresiva Recomendada
|
||
|
|
|
||
|
|
1. **Kogral**: Establece base de conocimiento (standalone, sin dependencias)
|
||
|
|
2. **TypeDialog**: Habilita inputs estructurados y validación
|
||
|
|
3. **SecretumVault**: Gestión de secretos con criptografía moderna
|
||
|
|
4. **Vapora**: Orquesta agentes con contexto de Kogral
|
||
|
|
5. **Provisioning**: Infraestructura informada por el ecosistema
|
||
|
|
|
||
|
|
Cada proyecto funciona de forma independiente. Las sinergias emergen al combinarlos.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Contacto
|
||
|
|
|
||
|
|
- **Repositorios**: GitHub (proyectos privados)
|
||
|
|
- **Stack**: Rust, Nickel, SurrealDB, Axum, Leptos
|
||
|
|
- **Licencia**: Propietaria / Por definir
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
*El desarrollo asistido por IA no debería requerir 10 herramientas desconectadas.*
|
||
|
|
*Un ecosistema. Cinco proyectos. Integración real.*
|