🤖 Explicar con IA

Pods de AI Studio¶

Un pod es la unidad de trabajo, equipo y facturación en 4Geeks AI Studio. Tiene un objetivo, un playbook, un repositorio, herramientas conectadas, un plan, tareas, una billetera y un pod lead humano. Esta página explica cómo crear uno, qué hace cada parte y cómo sacarle el máximo provecho.

¿Qué es un pod?¶

Un pod es un entorno de entrega autocontenido:

Un pod no es una sesión de chat. Mantiene estado, ejecuta jobs, registra evidencia y se pausa para las decisiones que necesitan un humano.

Tamaños y alcance del pod¶

El asistente estima el tamaño del brief a partir de su contenido. Tú nunca declaras el tamaño.

Un pod L guarda su lista out_of_scope y sus phases restantes en el plan, para que todos vean qué no incluye esta entrega. Un programa XL es una conversación comercial con un pod lead, no un pod automático.

Crear un pod paso a paso¶

1. Abre el asistente¶

En AI Studio, haz clic en Nuevo pod. El asistente tiene cuatro pasos: qué necesitas, unas preguntas, el repositorio y la confirmación.

Elige el resultado más cercano:

• Primera rebanada de mi producto
• Agregar una funcionalidad a mi app
• Encontrar y corregir un bug
• Auditar mi código antes de invertir
• Migrar mi base de datos
• Documentar mi sistema
• Mejorar la calidad y las pruebas
• Actualizar mis dependencias
• Un producto o una plataforma

Si ninguno encaja, elige Otra cosa y describe el objetivo tú mismo. Si prefieres una persona, elige No estoy seguro, quiero ayuda.

2. Responde la entrevista¶

La entrevista son cinco preguntas en lenguaje de negocio. Solo las marcadas son obligatorias; el resto puede quedar vacío.

Tus respuestas se convierten en el brief que revisa el pod lead y que usa el planner. Las respuestas crudas quedan en los metadatos del pod; no se pegan en el prompt de cada tarea.

3. Conecta el repositorio¶

Un pod trabaja en una rama y abre un merge request. Nunca hace push a tu rama protegida.

1. Elige GitLab o GitHub.
2. Escribe la URL de la instancia (por ejemplo https://gitlab.com).
3. Escribe la ruta del proyecto y la rama desde la que debe empezar el pod.
4. Pega un token de acceso con permiso de escritura en ese proyecto. El token se guarda cifrado en la bóveda y solo lo usa el sandbox del pod.
5. Elige la imagen de runtime: Base, Web, JVM o Android. El asistente sugiere una a partir del repositorio cuando puede inspeccionarlo.

4. Confirma el pod¶

La pantalla de confirmación muestra el tamaño, el brief, el playbook, el repositorio, la imagen de runtime, las capacidades, las herramientas, el saldo disponible y la primera estimación.

• Tamaño y alcance: S, M, L o XL. Un pod L muestra la primera rebanada y las fases posteriores.
• Capacidades: lo que el pod puede ejecutar. Puedes cambiarlas hasta que el plan se apruebe.
• Herramientas: Jira, Confluence, Notion o una base de datos. Puedes conectar credenciales después; el plan dirá qué falta.
• Estimación: la estimación de la primera entrega y el saldo de la billetera. Si el saldo es bajo, recarga antes de crear el pod.
• Crear pod: inicia el aprovisionamiento. El pod aparece en la lista y el plan se genera a continuación.

5. Aprueba el plan¶

Cuando el plan está listo, el pod aparece en Te necesitamos. Ábrelo y revisa:

• El resumen y el enfoque.
• Las tareas y sus criterios de aceptación.
• Los supuestos y riesgos.
• Lo que no está incluido en esta entrega.
• Las fases posteriores de un pod L.

Haz clic en Aprobar y empezar para mover el pod a construcción, o en Pedir cambios para devolverlo con feedback. El plan se aprueba en un solo lugar: la fila de aprobación. Aprobar el plan es lo que inicia la construcción.

6. Sigue la construcción y revisa el merge request¶

La sala del pod está organizada de arriba hacia abajo:

Cuando el trabajo termina, el pod abre un merge request con pruebas y evidencia. Tu equipo revisa y mergea. El pod no despliega a producción.

El pod lead¶

Cada pod tiene un pod lead humano de 4Geeks. Es la persona responsable detrás del pod:

• Revisa el alcance y el plan antes de que lo apruebes.
• Responde preguntas en la sala del pod y por email.
• Desbloquea un pod estancado y decide cuándo escalar.
• Es dueño de la conversación comercial de un brief L o XL.

Tiempo y facturación: Starter incluye 2 h de pod lead al mes y Pro incluye 6 h. Lite tiene pod lead bajo demanda a $75/h. Los minutos dentro del plan son gratis; el exceso se cobra a la billetera a $75/h.

Pedir ayuda: usa Hablar con mi pod lead en el compositor, o elige No estoy seguro, quiero ayuda en el asistente. Una solicitud de ayuda necesita:

1. Un plan activo para el workspace.
2. Minutos de pod lead disponibles en el periodo actual (Lite no incluye, así que es bajo demanda).
3. Una tarjeta registrada para garantizar el tiempo.

Una solicitud de ayuda no es un ticket de soporte. Es una entrevista breve que un pod lead lee antes de contactarte.

Capacidades¶

Las capacidades definen lo que un pod puede ejecutar realmente. Cada una activa skills, toolchains, tipos de tarea y artefactos esperados. El plan se valida contra ellas, así que una capacidad es un compromiso, no una insignia.

Las capacidades pueden cambiar antes de aprobar el plan. Una vez aprobado quedan bloqueadas, porque el plan, la imagen de runtime y las tareas se construyeron alrededor de ellas. preview se entrega inactiva hasta que el gateway de preview esté configurado para el workspace.

Quality es la capacidad detrás de Review y QA: los checks automáticos que deben pasar antes de que un pod pueda entregar, y el merge request con evidencia que tu equipo revisa antes de mergear. Mira cómo funcionan Review y QA.

Playbooks e imágenes de runtime¶

El playbook decide el equipo por defecto, los tipos de tarea y los destinos de salida. Normalmente eliges un resultado y el asistente elige el playbook; puedes cambiarlo en Opciones avanzadas.

Un pod corre una imagen, elegida antes de crear su sandbox:

La imagen es inmutable una vez que existe el sandbox, así que un proyecto nunca cambia de toolchain a mitad de vuelo. Si las capacidades necesitan dos imágenes a la vez, el asistente te avisa e instala un toolchain en runtime.

Ciclo de vida y sala del pod¶

stateDiagram-v2
    [*] --> draft
    draft --> provisioning
    provisioning --> planning
    planning --> awaiting_plan
    awaiting_plan --> building: plan aprobado
    building --> reviewing
    reviewing --> awaiting_review
    awaiting_review --> delivering
    delivering --> done
    building --> paused
    building --> blocked
    building --> failed

• Draft: creado pero no iniciado.
• Provisioning / planning: se preparan el sandbox y el plan.
• Awaiting plan: el plan está listo para tu aprobación.
• Building / reviewing: el pod ejecuta tareas y corre checks.
• Awaiting review: el merge request está listo para tu equipo.
• Delivering / done: los entregables están publicados y el pod se cierra.
• Paused / blocked / failed: una decisión o un fallo detuvo el avance; la sala del pod explica por qué.

Puedes pausar un pod mientras corre, reanudarlo y eliminarlo solo cuando está pausado, terminado o fallido. Eliminar un pod borra su plan, tareas, timeline, mensajes, entregables y sandbox; el repositorio, las herramientas y el historial de facturación se conservan.

Quality gate y entregables¶

Un pod con Quality o E2E no puede marcarse como entregado sin build y pruebas en verde. Los checks ejecutan los scripts del cliente en el sandbox y se guardan con el pod. E2E agrega una corrida de Playwright y un reporte.

• Un check fallido bloquea la entrega con QUALITY_GATE_FAILED.
• Una excepción aprobada puede aceptar una entrega sin corrida verde, con un motivo escrito y una entrada de auditoría.
• Los entregables incluyen el merge request, documentos, informes, artefactos de migración, enlaces de preview y páginas publicadas.
• Editar un artefacto marca su copia publicada como desactualizada; el pod puede actualizarla en el mismo lugar en vez de duplicar la página.

Buenas prácticas¶

1. Un resultado por pod. Divide el trabajo del tamaño de un producto en un pod L o un programa.
2. Escribe la definición de terminado en la entrevista. “Un cliente paga con una tarjeta guardada” es mejor que “mejorar el checkout”.
3. Conecta la rama correcta. El pod empieza desde la rama que le das y abre su MR contra ella.
4. Mantén el quality gate activo. Build y pruebas son el seguro más barato contra un merge malo.
5. Revisa el plan, no solo las tareas. Los supuestos y el fuera de alcance esconden las sorpresas.
6. Responde rápido a “Te necesitamos”. Un pod pausado en una decisión no avanza.
7. Usa al pod lead para alcance y riesgo. Está incluido para mantener la entrega honesta.
8. Adjunta referencias cuando el diseño importa. Un mockup más un brief escrito es mejor que cualquiera de los dos solo.
9. Recarga antes de que la billetera se vacíe. Una pausa por presupuesto cuesta más tiempo que una recarga.
10. Archiva los pods terminados. Mantiene la lista enfocada y libera un cupo de concurrencia.

Solución de problemas¶

Preguntas frecuentes¶

Siguientes pasos¶

• Ver los casos de uso de AI Studio
• Entender el uso, los planes y la billetera
• Leer sobre el Private AI Gateway
• Explorar las preguntas frecuentes de AI Studio

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