🤖 Explicar com IA

Casos de uso do AI Studio¶

Oito formas reais de equipes usarem o 4Geeks AI Studio, cada uma com as capacidades que ativa, o processo que o pod segue, o resultado que você obtém e os entregáveis que chegam ao seu repositório. Use esta página para escolher o resultado certo para o seu primeiro pod.

Casos de uso de relance¶

flowchart LR
    A[Escolha seu resultado] --> B[Intake curto de negócio]
    B --> C[O pod lead revisa o escopo]
    C --> D[Você aprova o plano]
    D --> E[O pod constrói em um branch]
    E --> F[O quality gate roda as checagens de QA]
    F --> G[Você revisa o merge request]

Os oito casos de uso do AI Studio¶

1. Construir um MVP novo¶

Playbook: greenfield · Tamanho típico: S a L

• Capacidades: Docs, Design e Quality. Adicione E2E quando a primeira fatia precisar ser provada em um navegador real.
• Processo: você responde o intake com o problema, os usuários e os três itens essenciais; o pod lead transforma isso em um plano com uma fatia declarada; você aprova; o pod constrói o fluxo em um sandbox no seu branch; o quality gate roda build e testes; você revisa o merge request.
• Resultado: uma primeira fatia do produto rodando no seu repositório, coberta por testes e pronta para o seu time implantar.
• Entregáveis: um merge request com o fluxo funcionando, os testes que o comprovam, o painel de operações se estava no escopo e documentação escrita a partir do código.

2. Adicionar uma funcionalidade ao seu app¶

Playbook: feature · Tamanho típico: S ou M

• Capacidades: Docs e Quality sempre; Design quando a funcionalidade muda a interface; E2E quando o fluxo é crítico, como checkout ou cadastro.
• Processo: você descreve o resultado em linguagem de negócio e escreve como vai saber que está pronto no intake; o plano chega com tarefas e critérios de aceite; você aprova; o pod constrói em um branch; os testes rodam no gate; você revisa e faz o merge.
• Resultado: a funcionalidade funcionando de ponta a ponta no seu código, com testes de regressão que a mantêm funcionando.
• Entregáveis: um merge request, os testes e a documentação atualizada quando a mudança afeta como o produto é usado.

3. Corrigir bugs na sua plataforma atual¶

Playbook: bugfix · Tamanho típico: S

• Capacidades: Docs e Quality.
• Processo: você reporta o sintoma e como reproduzi-lo; o pod reproduz a falha no sandbox e escreve um teste que falha; o pod lead confirma a causa; a correção entra; o teste fica verde; você revisa o merge request.
• Resultado: a causa explicada, provada por um teste que falha, e corrigida sem quebrar o que já funcionava.
• Entregáveis: o teste que falha e prova o bug, a correção, um teste de regressão e o merge request com a explicação.

4. Detectar erros novos e melhorar a qualidade¶

Playbook: qa · Tamanho típico: M

• Capacidades: Quality, mais E2E quando os fluxos de navegador importam.
• Processo: o pod roda sua suíte atual, reproduz as falhas que encontra, amplia a cobertura ao redor delas, adiciona testes de navegador com Playwright quando o E2E está ativo e roda tudo de novo sob o gate.
• Resultado: falhas reproduzidas com passos para ativá-las, mais cobertura de testes e uma corrida de navegador em verde para os fluxos críticos.
• Entregáveis: testes novos e atualizados, um relatório de falhas com passos de reprodução, o relatório E2E e o merge request.

5. Auditar o código antes de investir¶

Playbook: audit · Tamanho típico: S ou M

• Capacidades: Security para a própria revisão, Data quando o esquema importa, Docs para o relatório. O pod roda em modo read-only.
• Processo: você aponta o pod para o repositório; ele inspeciona o código, as dependências e o esquema; os achados são ordenados por risco e esforço; o pod lead revisa o relatório antes de você vê-lo.
• Resultado: uma lista priorizada de riscos e dívida técnica na qual você pode agir antes de comprometer orçamento.
• Entregáveis: o relatório com riscos, evidências e a ordem recomendada de trabalho. Nada no seu código é alterado.

6. Migrar meu banco de dados¶

Playbook: db-migration · Tamanho típico: M ou L

• Capacidades: Data e Quality. O pod recebe acesso read-only ao banco de dados de origem.
• Processo: o pod mapeia o esquema de origem e destino, escreve o DDL para revisão, roda uma validação shadow contra dados reais e prepara o plano de corte.
• Resultado: uma migração na qual você pode confiar, validada em uma corrida shadow, com um runbook que seu DBA pode executar.
• Entregáveis: o mapa de esquema, o DDL revisado, a evidência da validação shadow e o runbook. Mover os dados fica do seu lado.

7. Documentar meu sistema¶

Playbook: docs · Tamanho típico: S ou M

• Capacidades: Docs, mais SCRUM quando a saída precisa virar issues no Jira, Confluence ou Notion.
• Processo: o pod lê o código real, redige os documentos, o pod lead confere contra o código e você escolhe onde eles são publicados.
• Resultado: documentação que corresponde ao sistema como ele está escrito, não como alguém o recorda.
• Entregáveis: um conjunto de documentação como README, registros de decisão de arquitetura e uma referência de API, publicados onde você precisa.

8. Atualizar dependências ou refactorar um segmento¶

Playbook: upgrade · Tamanho típico: S ou M

• Capacidades: Docs e Quality; E2E quando o refactor toca um fluxo crítico.
• Processo: o pod pega uma linha de base do build e dos testes, aplica a atualização ou o refactor, corrige o que quebra e roda o gate de novo antes de abrir o merge request.
• Resultado: a atualização aplicada, a quebra corrigida e o comportamento existente preservado pela suíte de testes.
• Entregáveis: um merge request com changelog, os testes atualizados e uma nota de qualquer mudança disruptiva que seu time precise tratar.

Review e QA¶

Cada um dos casos de uso acima passa pelas mesmas duas camadas de qualidade. No produto, as duas fazem parte da capacidade Quality e respondem perguntas diferentes: QA pergunta “funciona?” e Review pergunta “devemos fazer o merge?”

O que o QA cobre

• Build e testes rodam no sandbox com os scripts do seu repositório, então a checagem combina com o seu projeto.
• E2E de navegador com Playwright e Chromium roda quando a capacidade E2E está ativa.
• Um pod com Quality ou E2E não pode ser marcado como entregue sem uma corrida verde; uma falha bloqueia a entrega com QUALITY_GATE_FAILED.
• Uma waiver só aceita uma entrega com motivo escrito, e fica registrada na trilha de auditoria.
• Uma tentativa falhada e um retry são absorvidos pela 4Geeks.

O que o Review cobre

• O pod lead revisa o escopo antes de você aprovar o plano e decide quando uma entrega está pronta.
• O pod abre um merge request em um branch; nunca faz push para o seu branch protegido e nunca faz o merge sozinho.
• Seu time revisa o diff, os testes e a evidência, e faz o merge quando aprova. A implantação continua no seu pipeline.
• A timeline do pod registra tarefas, checagens, aprovações e mensagens e pode ser exportada como JSON com credenciais redigidas.

Veja como funcionam o quality gate e os entregáveis

Histórias reais de clientes¶

Os mesmos casos de uso, entregues para clientes reais:

• Modernização de dados e infraestrutura — Ketsin: migração para cloud e operações regionais (casos 1 e 6).
• Pagamentos para e-commerce — Nandallo: pagamentos sem atrito para crescimento (caso 2).
• Uma plataforma de receita — One Ticket: operações simplificadas (caso 1).
• Saúde e bem-estar — Total Natural na Costa Rica (caso 2).

Aprenda o produto nesta ordem¶

A documentação foi escrita para que você consiga operar o produto sozinho, nesta sequência:

1. Criar um pod passo a passo — o wizard, o intake, o repositório, o plano e a sala do pod. Comece aqui.
2. Entender uso, planos e carteira — tarefas, horas de pod lead, orçamentos e o que acontece quando a bolsa acaba.
3. Quality gate e entregáveis — exatamente o que o QA verifica e o que você recebe.
4. Navegue pelas perguntas frequentes do AI Studio — escopo, segurança, cobrança e limites.
5. Leia sobre o Private AI Gateway — como funcionam o roteamento de modelos, os orçamentos e a auditoria.
6. Tutorial de primeiros passos — o mesmo fluxo a partir do console.

Verifique se você está pronto¶

Antes de criar o seu primeiro pod:

• Você consegue descrever o resultado em uma frase de negócio.
• Você escreveu como vai saber que está pronto.
• Você sabe qual dos casos de uso acima combina com sua necessidade.
• Seu repositório está acessível e você tem um token com permissão de escritura.
• Você sabe quem no seu time vai revisar e fazer o merge da solicitação.

Solução de problemas¶

Preguntas frequentes¶

Próximos passos¶

• Criar um pod passo a passo
• Entender uso, planos e carteira
• Navegue pelas perguntas frequentes do AI Studio

Crie seu primeiro pod

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