🤖 Explicar com IA

Pods do AI Studio¶

Um pod é a unidade de trabalho, time e cobrança no 4Geeks AI Studio. Ele tem um objetivo, um playbook, um repositório, ferramentas conectadas, um plano, tarefas, uma wallet e um pod lead humano. Esta página mostra como criar um pod, o que cada parte faz e como aproveitar ao máximo.

O que é um pod?¶

Um pod é um ambiente de entrega autocontido:

Um pod não é uma sessão de chat. Ele mantém estado, executa jobs, registra evidências e pausa para as decisões que precisam de uma pessoa.

Tamanhos e escopo do pod¶

O assistente estima o tamanho do brief a partir do que ele contém. Você nunca declara o tamanho.

Um pod L armazena sua lista out_of_scope e as phases restantes no plano, para que todos vejam o que essa entrega não inclui. Um programa XL é uma conversa comercial com um pod lead, não um pod automático.

Crie um pod passo a passo¶

1. Abra o assistente¶

Em AI Studio, clique em Novo pod. O assistente tem quatro etapas: o que você precisa, algumas perguntas, o repositório e a confirmação.

Escolha o resultado mais próximo:

• Primeira fatia do meu produto
• Adicionar uma funcionalidade ao meu app
• Encontrar e corrigir um bug
• Auditar meu código antes de investir
• Migrar meu banco de dados
• Documentar meu sistema
• Melhorar a qualidade e os testes
• Atualizar minhas dependências
• Um produto ou uma plataforma

Se nenhum se encaixar, escolha Outra coisa e descreva o objetivo você mesmo. Se preferir falar com uma pessoa, escolha Não tenho certeza, quero ajuda.

2. Responda ao formulário inicial¶

O formulário tem cinco perguntas em linguagem de negócio. Apenas as marcadas são obrigatórias; as demais podem ficar em branco.

Suas respostas se tornam o brief que o pod lead revisa e que o planner usa. As respostas brutas ficam nos metadados do pod; elas não são coladas no prompt de cada tarefa.

3. Conecte o repositório¶

Um pod trabalha em um branch e abre um merge request. Ele nunca faz push no seu branch protegido.

1. Escolha GitLab ou GitHub.
2. Informe a URL da instância (por exemplo, https://gitlab.com).
3. Informe o caminho do projeto e o branch a partir do qual o pod deve começar.
4. Cole um token de acesso com permissão de escrita nesse projeto. O token é armazenado criptografado no vault e usado apenas pelo sandbox do pod.
5. Escolha a imagem de runtime: Base, Web, JVM ou Android. O assistente sugere uma a partir do repositório quando consegue inspecioná-lo.

4. Confirme o pod¶

A tela de confirmação mostra o tamanho, o brief, o playbook, o repositório, a imagem de runtime, as capacidades, as ferramentas, o saldo disponível e a primeira estimativa.

• Tamanho e escopo: S, M, L ou XL. Um pod L mostra a primeira fatia e as fases seguintes.
• Capacidades: o que o pod pode executar. Você pode alterá-las até o plano ser aprovado.
• Ferramentas: Jira, Confluence, Notion ou um banco de dados. Você pode conectar credenciais depois; o plano dirá o que falta.
• Estimativa: a estimativa da primeira entrega e o saldo da wallet. Se o saldo estiver baixo, faça uma recarga antes de criar o pod.
• Criar pod: inicia o provisionamento. O pod aparece na lista e o plano é gerado em seguida.

5. Aprove o plano¶

Quando o plano estiver pronto, o pod aparece em Precisamos de você. Abra-o e revise:

• O resumo e a abordagem.
• As tarefas e seus critérios de aceitação.
• As premissas e os riscos.
• O que não está incluído nesta entrega.
• As fases seguintes de um pod L.

Clique em Aprovar e iniciar para mover o pod para a construção, ou em Solicitar mudanças para devolvê-lo com feedback. O plano é aprovado em exatamente um lugar: a linha de aprovação. Aprovar o plano é o que inicia a construção.

6. Acompanhe a construção e revise o merge request¶

A sala do pod é organizada de cima para baixo:

Quando o trabalho termina, o pod abre um merge request com testes e evidências. Seu time revisa e faz o merge. O pod não faz deploy em produção.

O pod lead¶

Cada pod tem um pod lead humano da 4Geeks. Ele é a pessoa responsável pelo pod:

• Revisa o escopo e o plano antes de você aprová-los.
• Responde perguntas na sala do pod e por e-mail.
• Desbloqueia um pod travado e decide quando escalar.
• É responsável pela conversa comercial de um brief L ou XL.

Tempo e cobrança: o Starter inclui 2 h de pod lead por mês e o Pro inclui 6 h. O Lite tem pod lead sob demanda a $75/h. Os minutos dentro do plano são gratuitos; o excedente é cobrado da wallet a $75/h.

Peça ajuda: use Falar com meu pod lead no composer, ou escolha Não tenho certeza, quero ajuda no assistente. Uma solicitação de ajuda precisa de:

1. Um plano ativo para o workspace.
2. Minutos de pod lead disponíveis no período atual (o Lite não inclui nenhum, então é sob demanda).
3. Um cartão cadastrado para garantir o tempo.

Uma solicitação de ajuda não é um ticket de suporte. É um formulário curto que um pod lead lê antes de entrar em contato.

Capacidades¶

As capacidades definem o que um pod pode realmente executar. Cada uma ativa skills, toolchains, tipos de tarefa e artefatos esperados. O plano é validado contra elas, então uma capacidade é um compromisso, não um selo.

As capacidades podem mudar antes da aprovação do plano. Depois que o plano é aprovado, elas ficam bloqueadas, porque o plano, a imagem de runtime e as tarefas foram construídos em torno delas. preview é entregue inativo até que o gateway de preview esteja configurado para o workspace.

Quality é a capacidade por trás de Review e QA: as checagens automáticas que precisam passar antes de um pod poder entregar, e o merge request com evidências que o seu time revisa antes do merge. Veja como funcionam Review e QA.

Playbooks e imagens de runtime¶

O playbook decide o time padrão, os tipos de tarefa e os alvos de saída. Normalmente você escolhe um resultado e o assistente escolhe o playbook; você pode alterá-lo em Opções avançadas.

Um pod roda uma imagem, escolhida antes de seu sandbox ser criado:

A imagem é imutável depois que o sandbox existe, então um projeto nunca troca de toolchain no meio do caminho. Se as capacidades precisarem de duas imagens ao mesmo tempo, o assistente avisa e instala um toolchain em runtime.

Ciclo de vida do pod e sala do pod¶

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

• Draft: criado, mas não iniciado.
• Provisioning / planning: o sandbox e o plano estão sendo preparados.
• Awaiting plan: o plano está pronto para sua aprovação.
• Building / reviewing: o pod está executando tarefas e rodando checagens.
• Awaiting review: o merge request está pronto para seu time.
• Delivering / done: os entregáveis são publicados e o pod é encerrado.
• Paused / blocked / failed: uma decisão ou uma falha interrompeu o progresso; a sala do pod explica o motivo.

Você pode pausar um pod em execução, retomá-lo e excluí-lo apenas quando ele estiver pausado, concluído ou com falha. Excluir um pod remove seu plano, tarefas, timeline, mensagens, entregáveis e sandbox; o repositório, as ferramentas e o histórico de cobrança permanecem.

Quality gate e entregáveis¶

Um pod com Quality ou E2E não pode ser marcado como entregue sem um build e uma execução de testes verdes. As checagens rodam os próprios scripts do cliente no sandbox e são armazenadas com o pod. O E2E de navegador adiciona uma execução do Playwright e um relatório.

• Uma checagem com falha bloqueia a entrega com QUALITY_GATE_FAILED.
• Uma waiver aprovada pode aceitar uma entrega sem uma execução verde, com justificativa por escrito e um registro de auditoria.
• Os entregáveis incluem o merge request, documentos, relatórios, artefatos de migração, links de preview e páginas publicadas.
• Editar um artefato marca sua cópia publicada como stale; o pod pode atualizá-la no lugar em vez de duplicar a página.

Boas práticas¶

1. Um resultado por pod. Divida o trabalho do tamanho de um produto em um pod L ou um programa.
2. Escreva a definição de pronto no formulário inicial. “Um cliente paga com um cartão salvo” é melhor que “melhorar o checkout”.
3. Conecte o branch certo. O pod começa do branch que você fornece e abre seu MR contra ele.
4. Mantenha o quality gate ativo. Build e testes são o seguro mais barato contra um merge ruim.
5. Revise o plano, não só as tarefas. As premissas e os itens fora de escopo são onde as surpresas se escondem.
6. Responda rápido a “Precisamos de você”. Um pod pausado em uma decisão não está fazendo progresso.
7. Use o pod lead para escopo e risco. Ele está incluído para manter a entrega honesta.
8. Anexe referências quando o design importa. Um mockup mais um brief escrito é melhor que qualquer um dos dois sozinho.
9. Faça uma recarga antes de a wallet secar. Uma pausa por orçamento custa mais tempo que uma recarga.
10. Arquive pods concluídos. Isso mantém a lista focada e libera uma vaga de concorrência.

Solução de problemas¶

Perguntas frequentes¶

Próximos passos¶

• Ver os casos de uso do AI Studio
• Entender o uso, os planos e a wallet
• Ler sobre o Private AI Gateway
• Explorar as perguntas frequentes do AI Studio

Ainda tem dúvidas? Pergunte no Discord ou explore os tutoriais.