🤖 Explain with AI

AI Studio use cases¶

Eight real ways teams use 4Geeks AI Studio, each with the capabilities it turns on, the process the pod follows, the result you get and the deliverables that land in your repository. Use this page to pick the right outcome for your first pod.

Use cases at a glance¶

flowchart LR
    A[Choose your outcome] --> B[Short business intake]
    B --> C[Pod lead reviews the scope]
    C --> D[You approve the plan]
    D --> E[Pod builds on a branch]
    E --> F[Quality gate runs QA checks]
    F --> G[You review the merge request]

The eight AI Studio use cases¶

1. Build a new MVP¶

Playbook: greenfield · Typical size: S to L

• Capabilities: Docs, Design and Quality. Add E2E when the first flow must be proven in a real browser.
• Process: you answer the intake with the problem, the users and the three must-haves; the pod lead turns it into a plan with one declared slice; you approve it; the pod builds the flow in a sandbox on your branch; the quality gate runs the build and tests; you review the merge request.
• Result: a first slice of the product running in your repository, covered by tests, ready for your team to deploy.
• Deliverables: a merge request with the working flow, the tests that prove it, the operations panel if it was in scope, and documentation written from the code.

2. Add a feature to your app¶

Playbook: feature · Typical size: S or M

• Capabilities: Docs and Quality always; Design when the feature changes the interface; E2E when the flow is critical, such as checkout or signup.
• Process: you describe the outcome in business language and write the definition of done in the intake; the plan arrives with tasks and acceptance criteria; you approve; the pod builds on a branch; tests run in the gate; you review and merge.
• Result: the feature working end to end in your codebase, with regression tests that keep it working.
• Deliverables: a merge request, the tests, and updated documentation when the change affects how the product is used.

3. Bug fixes on your current platform¶

Playbook: bugfix · Typical size: S

• Capabilities: Docs and Quality.
• Process: you report the symptom and how to reproduce it; the pod reproduces the failure in its sandbox and writes a test that fails; the pod lead confirms the cause; the fix goes in; the test turns green; you review the merge request.
• Result: the cause explained, proven by a failing test, and corrected without breaking what already worked.
• Deliverables: the failing test that proves the bug, the fix, a regression test and the merge request with the explanation.

4. Detect new errors and improve quality¶

Playbook: qa · Typical size: M

• Capabilities: Quality, plus E2E when browser flows matter.
• Process: the pod runs your current suite, reproduces the failures it finds, widens the coverage around them, adds browser tests with Playwright when E2E is on, and runs everything again under the gate.
• Result: reproduced failures with steps to trigger them, wider test coverage and a green browser run for the critical flows.
• Deliverables: new and updated tests, a failure report with reproduction steps, the E2E report and the merge request.

5. Audit your code before investing¶

Playbook: audit · Typical size: S or M

• Capabilities: Security for the review itself, Data when the schema matters, Docs for the report. The pod runs read-only.
• Process: you point the pod at the repository; it inspects the code, dependencies and schema; findings are ranked by risk and effort; the pod lead reviews the report before you see it.
• Result: a prioritised list of risks and technical debt you can act on before committing budget.
• Deliverables: the report with risks, evidence and recommended order of work. Nothing in your code is changed.

6. Migrate my database¶

Playbook: db-migration · Typical size: M or L

• Capabilities: Data and Quality. The pod gets read-only access to the source database.
• Process: the pod maps the source and target schema, writes the DDL for review, runs a shadow validation against real data and prepares the cut-over plan.
• Result: a migration you can trust, validated in a shadow run, with a runbook your DBA can execute.
• Deliverables: the schema map, the reviewed DDL, the shadow validation evidence and the runbook. Moving the data stays on your side.

7. Document my system¶

Playbook: docs · Typical size: S or M

• Capabilities: Docs, plus SCRUM when the output should become issues in Jira, Confluence or Notion.
• Process: the pod reads the real code, drafts the documents, the pod lead checks them against the code, and you choose where they are published.
• Result: documentation that matches the system as it is written, not as someone remembers it.
• Deliverables: a documentation set such as a README, architecture decision records and an API reference, published where you need it.

8. Upgrade dependencies or refactor a segment¶

Playbook: upgrade · Typical size: S or M

• Capabilities: Docs and Quality; E2E when the refactor touches a critical flow.
• Process: the pod takes a baseline of the build and tests, applies the upgrade or refactor, fixes what breaks, and runs the gate again before opening the merge request.
• Result: the upgrade applied, the breakage fixed and the existing behaviour preserved by the test suite.
• Deliverables: a merge request with a changelog, the updated tests and a note of any breaking change your team must handle.

Review and QA¶

Every use case above runs through the same two layers of quality. In the product they are both part of the Quality capability, and they answer different questions: QA asks “does it work?”, Review asks “should we merge it?”

What QA covers

• Build and tests run in the sandbox with your repository’s own scripts, so the check matches your project.
• Browser E2E with Playwright and Chromium runs when the E2E capability is on.
• A pod with Quality or E2E cannot be marked delivered without a green run; a failure blocks delivery with QUALITY_GATE_FAILED.
• A waiver can only accept a delivery with a written reason, and it is recorded in the audit trail.
• One failed attempt and one retry are absorbed by 4Geeks.

What Review covers

• The pod lead reviews the scope before you approve the plan and decides when a delivery is ready.
• The pod opens a merge request on a branch; it never pushes to your protected branch and never merges on its own.
• Your team reviews the diff, the tests and the evidence, and merges when satisfied. Deployment stays in your pipeline.
• The pod timeline records tasks, checks, approvals and messages and can be exported as JSON with credentials redacted.

See how the quality gate and deliverables work

Real customer stories¶

The same use cases, delivered for real customers:

• Database and infrastructure modernisation — Ketsin: cloud migration and regional operations (use case 1 and 6).
• Payments for e-commerce — Nandallo: seamless payments for growth (use case 2).
• A revenue platform — One Ticket: streamlining operations (use case 1).
• Health and wellness retail — Total Natural in Costa Rica (use case 2).

Learn the product in this order¶

The documentation is written so you can run the product yourself, in this sequence:

1. Create a pod step by step — the wizard, the intake, the repository, the plan and the pod room. Start here.
2. Understand usage, plans and the wallet — tasks, pod lead hours, budgets and what happens when the bag runs out.
3. Quality gate and deliverables — exactly what QA checks and what you receive.
4. Browse the AI Studio FAQ — scope, security, billing and limits.
5. Read the Private AI Gateway — how model traffic, budgets and audit work.
6. Getting started tutorial — the same flow from the console.

Verify you are ready¶

Before you create your first pod:

• You can describe the outcome in one business sentence.
• You wrote how you will know it is done.
• You know which use case above matches your need.
• Your repository is reachable and you have a token with write access.
• You know who on your team will review and merge the request.

Troubleshooting¶

Frequently asked questions¶

Next steps¶

• Create a pod step by step
• Understand usage, plans and the wallet
• Browse the AI Studio FAQ

Create your first pod

Still have questions? Ask on Discord or explore the tutorials.