AI-Native Product Studio · Playbook
Playbook
Cómo operamos: el pipeline, los agentes, las barandas, las métricas. Esta es la documentación pública de nuestro modelo de estudio — transparente por diseño.
Filosofía operativa
Delegar, Revisar, Asumir
Tres palabras que definen cada interacción entre humanos y agentes en nuestro estudio. El modelo es simple; la disciplina que requiere, no.
Delegar
Toda tarea bien definida va a un agente especializado. Si una tarea puede expresarse como un prompt claro con criterios de aceptación, un humano no debería ejecutarla.
- → Generación de código, escritura de tests, documentación
- → Investigación, análisis competitivo, evaluación de riesgos
- → Refactoring, escaneo de seguridad, monitoreo de costos
Revisar
El humano valida cada output contra criterios técnicos y de negocio. Ningún output de agente llega a producción sin aprobación humana explícita.
- → ¿Cumple los criterios de aceptación?
- → ¿Se alinea con las decisiones de arquitectura?
- → ¿Introduce riesgo que el agente no puede ver?
Asumir
El humano firma el merge. La responsabilidad siempre es humana. Los agentes son herramientas con capacidades extraordinarias, pero la responsabilidad no se puede delegar a un modelo.
- → El humano mergea a main, siempre
- → El humano es dueño de la decisión, no el agente
- → El humano se comunica con el cliente, siempre
El Pipeline
De idea a producción en cuatro fases
Cada proyecto sigue el mismo pipeline. Las fases se superponen, los agentes cambian, pero la estructura es constante.
Discovery
Días 1–3
Rol humano
Client Partner conduce las conversaciones de discovery, entiende el espacio del problema, captura restricciones y criterios de éxito. Esta es la fase más intensiva en humanos — matices, empatía y contexto de negocio no se pueden delegar.
Agentes en acción
Research Agent escanea el panorama competitivo, Domain Agent mapea terminología específica de la industria y modelos de datos, Risk Agent señala riesgos técnicos y regulatorios tempranamente.
Especificación
Días 3–7
Roles humanos
Product Architect define la forma del producto y los flujos de usuario. Systems Engineer define la arquitectura técnica, el modelo de datos y los puntos de integración. Juntos traducen la intención de negocio en especificaciones legibles por máquina.
Agentes en acción
Spec Generator produce historias de usuario con criterios de aceptación desde conversaciones. Architecture Agent propone diagramas de sistema y límites de componentes. Estimator Agent desglosa historias en tareas con puntajes de complejidad y proyecciones de costo de tokens.
Build
Semanas 2–N
Roles humanos
Systems Engineer orquesta la flota de agentes, revisa PRs y toma decisiones de arquitectura. Quality Curator valida cobertura de tests, consistencia UX y criterios de aceptación. Aquí es donde el apalancamiento de agentes es máximo — 7+ agentes trabajando en paralelo, humano revisando outputs.
Agentes en acción
Los agentes trabajan en ramas paralelas. Backend genera endpoints API y lógica de negocio. Frontend construye componentes y vistas. Database escribe migraciones y seeds. Test Agent genera tests unitarios, de feature e integración. Doc Agent mantiene la documentación sincronizada. Security Agent ejecuta Trivy, checks OWASP en cada push. Refactor Agent identifica y resuelve code smells.
Deploy & Operate
Continuo
Rol humano
Reliability Engineer es responsable del uptime, aprueba deploys, gestiona escalamiento de incidentes y revisa tendencias de costos. El objetivo es entrega zero-downtime con observabilidad total.
Agentes en acción
Deploy Agent gestiona pipelines CI/CD y estrategias de rollout. Observer Agent monitorea métricas, logs y traces en tiempo real. Incident Agent triagea alertas, propone root cause y redacta reportes de incidentes. Cost Agent rastrea gasto de tokens, costos de cloud y alerta anomalías antes de que se conviertan en problemas.
Los números
Modelo tradicional vs. Modelo estudio
Comparación lado a lado para un producto SaaS típico de complejidad media. Los números se basan en proyectos reales.
| Métrica | Tradicional | Modelo estudio |
|---|---|---|
| Tamaño del equipo (humanos) | 7 | 4 |
| Agentes en flota | 0 | 10 – 25 |
| Velocidad | 30 – 40 sp/sprint | 60 – 100 sp/sprint |
| Lead time (historia a deploy) | 3 – 5 days | Hours |
| Costo mensual | Alto (equipo grande) | Menor (equipo reducido + agentes) |
Los story points son ilustrativos. La velocidad real depende de la complejidad del codebase, requisitos de cobertura de tests y especificidad del dominio. Los costos de tokens asumen Anthropic Claude como modelo principal; los costos varían con la mezcla de modelos y la eficiencia del prompt engineering.
Barandas
Lo que nunca delegamos
Velocidad sin barandas es caos. Estas son las reglas duras que ningún agente, sin importar cuán capaz sea, puede evadir.
Decisiones de arquitectura
Cualquier cambio que afecte más de 3 archivos requiere revisión humana explícita antes del merge. Los cambios estructurales nunca se auto-mergean.
Schemas de DB en producción
Las modificaciones de schema en producción siempre son revisadas y ejecutadas por humanos. Los agentes pueden proponer migraciones; no pueden ejecutarlas.
Credenciales y secretos
Ningún agente tiene acceso a credenciales de producción, API keys o secretos. Los agentes trabajan solo con stubs de entorno y valores mock.
Comunicaciones con clientes
Todas las comunicaciones hacia clientes son escritas y enviadas por humanos. Los agentes pueden redactar borradores, pero un humano siempre revisa y envía.
Legal, comercial y pricing
Decisiones legales, términos contractuales, estructuras de precios y acuerdos comerciales son dominio exclusivamente humano. Sin excepciones.
Merge a main
Ningún agente puede mergear a la rama principal. Cada merge requiere un reviewer humano que asume responsabilidad total por el cambio.
Cumplimiento — Estas barandas no son lineamientos. Se aplican mediante reglas de protección de ramas, gates en pipelines CI, permisos de herramientas MCP y pasos obligatorios de aprobación humana. Violar una baranda detiene el pipeline.
Nuestro stack
home.stack.title
Somos opinionados con nuestras herramientas. Elegimos pocas, las aprendemos profundamente y les sacamos cada gramo de apalancamiento.
home.stack.we_master
home.stack.we_use
home.stack.we_explore
Contanos qué estás construyendo.
Leíste el playbook. Sabés cómo trabajamos. Si esto resuena con cómo querés que se construya tu próximo producto, hablemos.