🤖 Explicar con IA

Casos de uso de AI Studio¶

Ocho formas reales en que los equipos usan 4Geeks AI Studio, cada una con las capacidades que activa, el proceso que sigue el pod, el resultado que obtienes y los entregables que llegan a tu repositorio. Usa esta página para elegir el resultado correcto para tu primer pod.

Casos de uso de un vistazo¶

flowchart LR
    A[Elige tu resultado] --> B[Entrevista breve de negocio]
    B --> C[El pod lead revisa el alcance]
    C --> D[Tú apruebas el plan]
    D --> E[El pod construye en una rama]
    E --> F[El quality gate corre los checks de QA]
    F --> G[Tú revisas el merge request]

Los ocho casos de uso de AI Studio¶

1. Construir un MVP nuevo¶

Playbook: greenfield · Tamaño típico: S a L

• Capacidades: Docs, Design y Quality. Agrega E2E cuando la primera rebanada deba probarse en un navegador real.
• Proceso: respondes la entrevista con el problema, los usuarios y los tres imprescindibles; el pod lead la convierte en un plan con una rebanada declarada; tú lo apruebas; el pod construye el flujo en un sandbox sobre tu rama; el quality gate corre build y pruebas; tú revisas el merge request.
• Resultado: una primera rebanada del producto funcionando en tu repositorio, cubierta por pruebas y lista para que tu equipo la despliegue.
• Entregables: un merge request con el flujo funcionando, las pruebas que lo demuestran, el panel de operaciones si estaba en alcance y documentación escrita del código.

2. Agregar una funcionalidad a tu app¶

Playbook: feature · Tamaño típico: S o M

• Capacidades: Docs y Quality siempre; Design cuando la funcionalidad cambia la interfaz; E2E cuando el flujo es crítico, como checkout o registro.
• Proceso: describes el resultado en lenguaje de negocio y escribes cómo sabrás que está terminado en la entrevista; llega el plan con tareas y criterios de aceptación; lo apruebas; el pod construye en una rama; las pruebas corren en el gate; tú revisas y mergeas.
• Resultado: la funcionalidad funcionando de punta a punta en tu código, con pruebas de regresión que la mantienen funcionando.
• Entregables: un merge request, las pruebas y la documentación actualizada cuando el cambio afecta cómo se usa el producto.

3. Corregir bugs en tu plataforma actual¶

Playbook: bugfix · Tamaño típico: S

• Capacidades: Docs y Quality.
• Proceso: reportas el síntoma y cómo reproducirlo; el pod reproduce el fallo en su sandbox y escribe una prueba que falla; el pod lead confirma la causa; entra la corrección; la prueba se pone en verde; tú revisas el merge request.
• Resultado: la causa explicada, probada con una prueba que falla, y corregida sin romper lo que ya funcionaba.
• Entregables: la prueba que falla y demuestra el bug, la corrección, una prueba de regresión y el merge request con la explicación.

4. Detectar errores nuevos y mejorar la calidad¶

Playbook: qa · Tamaño típico: M

• Capacidades: Quality, más E2E cuando los flujos de navegador importan.
• Proceso: el pod corre tu suite actual, reproduce los fallos que encuentra, amplía la cobertura alrededor de ellos, agrega pruebas de navegador con Playwright cuando E2E está activo y vuelve a correr todo bajo el gate.
• Resultado: fallos reproducidos con pasos para activarlos, más cobertura de pruebas y una corrida de navegador en verde para los flujos críticos.
• Entregables: pruebas nuevas y actualizadas, un informe de fallos con pasos de reproducción, el informe E2E y el merge request.

5. Auditar el código antes de invertir¶

Playbook: audit · Tamaño típico: S o M

• Capacidades: Security para la revisión en sí, Data cuando el esquema importa, Docs para el informe. El pod corre en modo read-only.
• Proceso: apuntas al pod a tu repositorio; inspecciona el código, las dependencias y el esquema; los hallazgos se ordenan por riesgo y esfuerzo; el pod lead revisa el informe antes de que lo veas.
• Resultado: una lista priorizada de riesgos y deuda técnica sobre la que puedes actuar antes de comprometer presupuesto.
• Entregables: el informe con riesgos, evidencia y el orden recomendado de trabajo. No se modifica nada en tu código.

6. Migrar mi base de datos¶

Playbook: db-migration · Tamaño típico: M o L

• Capacidades: Data y Quality. El pod recibe acceso read-only a la base de datos de origen.
• Proceso: el pod mapea el esquema de origen y destino, escribe el DDL para revisión, corre una validación en shadow contra datos reales y prepara el plan de corte.
• Resultado: una migración en la que puedes confiar, validada en una corrida shadow, con un runbook que tu DBA puede ejecutar.
• Entregables: el mapa de esquema, el DDL revisado, la evidencia de la validación shadow y el runbook. Mover los datos queda de tu lado.

7. Documentar mi sistema¶

Playbook: docs · Tamaño típico: S o M

• Capacidades: Docs, más SCRUM cuando la salida debe convertirse en issues de Jira, Confluence o Notion.
• Proceso: el pod lee el código real, redacta los documentos, el pod lead los verifica contra el código y tú eliges dónde se publican.
• Resultado: documentación que coincide con el sistema tal como está escrito, no como alguien lo recuerda.
• Entregables: un set de documentación como README, registros de decisiones de arquitectura y una referencia de API, publicados donde los necesites.

8. Actualizar dependencias o refactorizar un segmento¶

Playbook: upgrade · Tamaño típico: S o M

• Capacidades: Docs y Quality; E2E cuando el refactor toca un flujo crítico.
• Proceso: el pod toma una línea base del build y las pruebas, aplica la actualización o el refactor, corrige lo que se rompe y vuelve a correr el gate antes de abrir el merge request.
• Resultado: la actualización aplicada, la rotura corregida y el comportamiento existente preservado por la suite de pruebas.
• Entregables: un merge request con changelog, las pruebas actualizadas y una nota de cualquier cambio disruptivo que tu equipo deba manejar.

Review y QA¶

Cada uno de los casos de uso anteriores pasa por las mismas dos capas de calidad. En el producto ambas forman parte de la capacidad Quality y responden preguntas distintas: QA pregunta “¿funciona?” y Review pregunta “¿debemos mergearlo?”

Qué cubre QA

• Build y pruebas corren en el sandbox con los scripts de tu repositorio, así que el check coincide con tu proyecto.
• E2E de navegador con Playwright y Chromium corre cuando la capacidad E2E está activa.
• Un pod con Quality o E2E no se puede marcar como entregado sin una corrida en verde; un fallo bloquea la entrega con QUALITY_GATE_FAILED.
• Solo una excepción (waiver) puede aceptar una entrega, con un motivo escrito, y queda registrada en el audit trail.
• Un intento fallido y un reintento corren por cuenta de 4Geeks.

Qué cubre Review

• El pod lead revisa el alcance antes de que apruebes el plan y decide cuándo una entrega está lista.
• El pod abre un merge request en una rama; nunca hace push a tu rama protegida y nunca mergea por su cuenta.
• Tu equipo revisa el diff, las pruebas y la evidencia, y mergea cuando queda conforme. El despliegue sigue en tu pipeline.
• El timeline del pod registra tareas, checks, aprobaciones y mensajes, y se puede exportar como JSON con las credenciales redactadas.

Cómo funcionan el quality gate y los entregables

Casos reales de clientes¶

Los mismos casos de uso, entregados a clientes reales:

• Modernización de base de datos e infraestructura — Ketsin: migración a cloud y operaciones regionales (casos 1 y 6).
• Pagos para e-commerce — Nandallo: pagos sin fricción para crecer (caso 2).
• Una plataforma de ingresos — One Ticket: operaciones simplificadas (caso 1).
• Salud y bienestar — Total Natural en Costa Rica (caso 2).

Aprende el producto en este orden¶

La documentación está escrita para que puedas operar el producto tú mismo, en esta secuencia:

1. Crear un pod paso a paso — el asistente, la entrevista, el repositorio, el plan y la sala del pod. Empieza aquí.
2. Entender el uso, los planes y la billetera — tareas, horas de pod lead, presupuestos y qué pasa cuando se acaba la bolsa.
3. Quality gate y entregables — exactamente qué revisa QA y qué recibes.
4. Explorar las preguntas frecuentes de AI Studio — alcance, seguridad, facturación y límites.
5. Leer sobre el Private AI Gateway — cómo funcionan el ruteo de modelos, los presupuestos y la auditoría.
6. Tutorial de primeros pasos — el mismo flujo desde la consola.

Verifica que estás listo¶

Antes de crear tu primer pod:

• Puedes describir el resultado en una frase de negocio.
• Escribiste cómo sabrás que está terminado.
• Sabes cuál de los casos de uso anteriores coincide con tu necesidad.
• Tu repositorio es accesible y tienes un token con permiso de escritura.
• Sabes quién de tu equipo revisará y mergeará la solicitud.

Solución de problemas¶

Preguntas frecuentes¶

Siguientes pasos¶

• Crear un pod paso a paso
• Entender el uso, los planes y la billetera
• Explorar las preguntas frecuentes de AI Studio

Crea tu primer pod

¿Aún tienes dudas? Pregunta en Discord o explora los tutoriales.