| # | Use case | Key integrations | Est. time saved About the estimate | | - | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Implement features |

Code repo

Code repo

Code repo

Code repo

Code repo

Code repo

Code repo

Observability

Code repo | **0.5** hr/wk |

Implement features

Best for well-scoped product work with clear acceptance criteria

3 hr/wkest. time saved How this estimate is calculated

How it's done today

You translate a ticket into code, find the relevant entry points, trace data flow, copy established patterns, update tests, and repeatedly move between the issue, editor, and terminal.

How AI helps

Given the repository and acceptance criteria, your agent finds the existing pattern, proposes a small plan, implements the change across the necessary files, and runs the focused checks before returning the diff.

Ticket is ready scope and acceptance are clear

Your AI agent

Locates the relevant code path, follows local conventions, implements the smallest complete change, and reports the tests and decisions.

Code change

Test results

Review summary

How to set it up

Step 1Connect your tools

Required

Code repo

Reads the code, history, contribution rules, and existing implementation patterns.

Writes a branch or patch containing the scoped change.

Recommended

CI/CD

Reads the required checks and prior failures.

Writes new or updated tests and the local check results.

Optional

IDE

Reads local diagnostics, language tooling, and runtime output while it works.

Issues

Reads the ticket, acceptance criteria, dependencies, and design decisions.

Writes a concise implementation and verification summary.

If the issue tracker is not connected, paste the complete ticket into the coding agent at the repository root. Repository access and executable checks matter far more than automatic ticket updates.

Step 2Build the workflow

Have a ready ticket, repository instructions, setup and test commands, and one similar implementation you trust. Start with changes that fit in one reviewable pull request.

```text Setup prompt theme={null} Help me build a repeatable feature-implementation workflow. For each ready engineering ticket, produce a small reviewable change in the repository. Never merge or deploy it. 1. Read the repository instructions and the ticket, then restate the requested behavior, constraints, acceptance criteria, and anything still ambiguous. 2. Find the relevant entry points, tests, data models, and one similar feature. 3. Propose the smallest implementation plan and name the files likely to change. 4. Implement the complete behavior using existing patterns; avoid unrelated refactors and new dependencies unless the ticket requires them. 5. Add or update focused tests for the acceptance criteria and important failure paths. 6. Run formatting, lint, type checks, and the smallest relevant test suite. 7. Return the diff, commands and results, assumptions, and manual verification. ```

What good looks like

The diff should satisfy every acceptance criterion, resemble nearby code, avoid unrelated edits, include meaningful tests, and arrive with reproducible check results and no hidden decision disguised as implementation detail.

Step 3Turn it on

Choose your trigger

Start manually from a Ready for development ticket or a specific repository comment. Exclude vague discovery work, security-sensitive changes, large migrations, and tickets with unresolved product decisions.

What runs without you

The agent can pick up a ready ticket, implement it, and open a draft pull request on its own - merging never stops being yours. Keep every diff human-reviewed; after five tasks that land with only normal review feedback, let it create branches and draft PRs automatically. Revisit the repository instructions whenever the stack or conventions change, or the agent will keep reproducing yesterday's patterns.

Pairs well with generate tests and review pull requests - the same ticket flows from change to coverage to first-pass review.

Investigate bugs

Best for reproducible failures that still require code tracing

2 hr/wkest. time saved How this estimate is calculated

How it's done today

You translate a vague report into reproduction steps, search logs and recent changes, trace the failing path through the codebase, form hypotheses, and manually assemble evidence for a fix.

How AI helps

Your agent reproduces the reported behavior, collects the relevant logs and stack traces, follows the code path, tests competing hypotheses, and proposes the smallest fix with a regression test.

Bug is reproducible steps and expected behavior supplied

Your AI agent

Runs the reproduction, traces the failure through logs and code, narrows the cause, and verifies a minimal patch against the same steps.

Root-cause note

Fix and test

Verification log

How to set it up

Step 1Connect your tools

Required

Code repo

Reads the implementation, recent history, tests, and repository instructions.

Writes a proposed patch and regression test on a branch.

Recommended

Observability

Reads the relevant logs, traces, errors, environment, and timestamps.

CI/CD

Reads existing failures and test commands.

Writes the regression-test result and focused verification.

Optional

Issues

Reads the report, reproduction, expected behavior, impact, and affected versions.

Paste the report, stack trace, and a narrow log export into the coding agent if observability is not connected. A precise reproduction and timestamp are more useful than a long general description.

Step 2Build the workflow

Have one deterministic reproduction, expected versus actual behavior, environment details, a recent failure timestamp, and the commands needed to run the affected service or test.

```text Setup prompt theme={null} Help me build a bug-investigation workflow. Given a bug report, reproduce the failure, identify the supported root cause, and prepare a minimal fix for review. Never deploy it. 1. Ask for exact reproduction steps, expected and actual behavior, environment, frequency, impact, timestamps, and known recent changes. 2. Reproduce before editing. Capture the failing output, logs, trace, or test. 3. Trace the execution path and list plausible causes with evidence for and against each one. 4. Make the smallest change that addresses the supported cause without changing public behavior elsewhere. 5. Add a regression test that fails before the fix and passes after it. 6. Rerun the original reproduction, focused tests, lint, and type checks. 7. Report cause, patch, evidence, commands, results, and remaining uncertainty. ```

What good looks like

The original failure must be demonstrated, the claimed cause must explain it, the regression test must protect the behavior, and the same reproduction must pass after a minimal diff without unrelated cleanup.

Step 3Turn it on

Choose your trigger

Run manually when a report has clear reproduction steps or automatically when a known deterministic test fails. Exclude intermittent production incidents without a bounded evidence pack; those belong in incident investigation.

What runs without you

Every fix stays human-reviewed - what graduates is the investigation itself. After five cases where the root cause held up, let the agent start on new reports automatically and post its reproduction and evidence as a ticket note before anyone picks the bug up. Check monthly that it still has access to the logs and test fixtures it relies on; a silent permissions change turns good investigations into guesses.

Pairs well with generate tests and investigate incidents - a confirmed root cause hands the regression test and the incident timeline their starting evidence.

Generate tests

Best for closing clear coverage gaps around important behavior

2 hr/wkest. time saved How this estimate is calculated

How it's done today

You read the implementation and existing test style, identify meaningful behavior gaps, build fixtures and mocks, write assertions, and repeatedly tune brittle tests until they pass reliably.

How AI helps

Your agent maps important behavior and failure paths, follows the nearest test pattern, creates focused cases, and runs them both independently and inside the relevant suite.

Coverage gap identified behavior and boundary are known

Your AI agent

Derives cases from observable behavior, reuses local fixtures, and proves each test can fail for the intended reason before returning it.

Test cases

Coverage note

Suite results

How to set it up

Step 1Connect your tools

Required

Code repo

Reads the implementation, nearest tests, fixtures, helpers, and behavior contract.

Writes focused test files or additions.

Recommended

CI/CD

Reads test commands, coverage output, and flaky-test history.

Writes the focused and suite-level results.

Optional

IDE

Reads language diagnostics and local runtime output while the tests are built.

A local coding agent with repository access is enough. Supply the exact behavior to protect; a percentage coverage target by itself tends to produce low-value tests.

Step 2Build the workflow

Have the target behavior, relevant files, test command, and one nearby test that represents the preferred style. Decide whether the goal is regression protection, edge cases, or a missing contract.

```text Setup prompt theme={null} Help me build a focused test-generation workflow. For each named behavior or coverage gap, add tests that protect observable behavior rather than implementation trivia. 1. Read the target code, public contract, closest test files, fixtures, and repository test instructions. 2. State the behaviors, boundaries, and failure paths worth testing, and skip cases already covered. 3. Reuse existing helpers and realistic fixtures; avoid snapshots or mocks that merely duplicate the implementation. 4. Add the smallest set of normal, boundary, error, and regression cases that provide distinct protection. 5. Demonstrate that each regression test fails for the intended reason when the protection is absent, then restore the code. 6. Run the focused tests and the nearest relevant suite, and flag any flakiness. 7. Summarize what is now protected and what remains intentionally untested. ```

What good looks like

The tests should exercise observable behavior, fail for a meaningful reason, match local style, avoid unnecessary mocks, run reliably, and add protection not already present in the suite.

Step 3Turn it on

Choose your trigger

Run from a review comment, a bug fix, or an explicit coverage-gap task. Do not auto-generate tests for every changed line; require a named behavior or risk.

What runs without you

Test diffs stay reviewed like any other code change. Once five additions in a row have landed without rework, let the agent push updates to a draft PR on its own - the red-green proof inside each test is what keeps this safe. Watch the flaky-test signals weekly; a generated test that flakes erodes trust in the whole suite faster than a missing one.

Pairs well with implement features and investigate bugs - both produce the changes that need exactly this protection.

Review pull requests

Best for a consistent first pass before a human reviewer

1.5 hr/wkest. time saved How this estimate is calculated

How it's done today

You open the ticket, inspect the diff, trace changed call paths, cross-check conventions and tests, and write review comments while trying to separate real defects from style preferences.

How AI helps

When a pull request is ready, your agent compares it with the stated intent, inspects affected code and tests, runs relevant checks, and leaves a short list of evidence-backed findings for the reviewer.

Pull request ready draft status removed

Your AI agent

Checks behavior, correctness, security, tests, and repository conventions, then reports only actionable findings with exact locations.

Review findings

Check results

Risk summary

How to set it up

Step 1Connect your tools

Required

Code repo

Reads the pull request, base branch, ticket, surrounding code, and review rules.

Writes review comments or a draft review for the engineer.

Recommended

CI/CD

Reads required check results, coverage changes, and failure logs.

Optional

Issues

Reads acceptance criteria and linked design decisions.

Run the coding agent against the pull-request branch locally if repository review integration is unavailable. Ask for a review report rather than copying the raw diff into a general chatbot.

Step 2Build the workflow

Have repository review guidance, the ticket, required checks, and examples of useful versus noisy review comments. Define focus areas such as correctness, security, migrations, or backward compatibility.

```text Setup prompt theme={null} Help me build a pull-request review workflow. When a pull request leaves draft, perform a first-pass review and return only actionable, evidence-backed findings. Never approve or merge it. 1. Read the ticket, acceptance criteria, repository instructions, diff, and surrounding code before commenting. 2. Trace the changed behavior through callers, data boundaries, and tests. 3. Check correctness, failure handling, security, compatibility, migrations, concurrency where relevant, and whether the tests protect the new behavior. 4. Run the smallest relevant checks when the environment allows it. 5. For each finding, cite the exact file and line, explain the concrete failure scenario, and distinguish blocking defects from suggestions. 6. Suppress style comments already enforced by tooling and do not restate the diff. 7. End with a short risk and verification summary. ```

What good looks like

Comments should identify a real failure or maintainability risk, point to the exact code, explain how to reproduce or reason about it, and avoid noise that a formatter or human preference would settle.

Step 3Turn it on

Choose your trigger

Run when a pull request leaves draft or when a reviewer explicitly requests it. Skip generated files, dependency-lock-only changes, and repositories without review instructions until those rules exist.

What runs without you

Approval and merge are permanently human - the agent's review is a first pass, not a gate. Keep its comments in draft for the first ten pull requests and compare them with what your reviewers caught. When the overlap is consistently useful, let non-blocking comments post automatically. Once a month, sample merged PRs for defects it missed; the agent's silence should never be read as approval.

Pairs well with implement features - both work from the same repository rules, on opposite sides of the diff.

Understand codebases

Best for onboarding to an unfamiliar service or tracing one feature

1.5 hr/wkest. time saved How this estimate is calculated

How it's done today

You search folders and symbols, jump between callers and data models, read stale architecture pages, and ask teammates to explain how one request or feature moves through the system.

How AI helps

Your agent maps the relevant files, traces the execution and data flow, explains project-specific terms, and gives you a source-linked walkthrough you can challenge with follow-up questions.

New area to understand service or feature named

Your AI agent

Starts broad, narrows to the requested path, and supports every explanation with files, symbols, and the current implementation.

Architecture map

Execution trace

Glossary

How to set it up

Step 1Connect your tools

Required

Code repo

Reads the current code, tree, symbols, history, and repository instructions.

Recommended

Docs

Reads architecture decisions, runbooks, diagrams, and product terminology.

Writes a source-linked walkthrough or onboarding note.

Optional

IDE

Reads language intelligence and runtime commands for confirming the execution path.

Run the agent at the repository root and point it at a specific feature or service. Broad requests such as “explain everything” are less useful than tracing one user action end to end.

Step 2Build the workflow

Have the repository instructions, setup commands, any current architecture docs, and three questions a new engineer genuinely needs answered.

```text Setup prompt theme={null} Help me build a codebase-understanding workflow. For a named service or feature, create a source-linked walkthrough of how it works in the current repository. 1. Read the repository instructions and produce a short map of packages, entry points, tests, data stores, and external dependencies relevant to the area. 2. Ask what I need to understand: architecture, a user flow, a data model, an operational path, or where to make a change. 3. Trace one concrete request from entry point through important calls, state changes, persistence, and response. 4. Cite files and symbols for every material statement and label uncertain or apparently stale documentation. 5. Explain project-specific terms and the conventions a new engineer must follow. 6. Identify the safest extension points and the tests that protect the path. 7. Test the workflow on three different areas of the repository. ```

What good looks like

A new engineer should be able to navigate from the explanation to the exact code, follow the real execution path, distinguish current implementation from stale docs, and know where changes and tests normally belong.

Step 3Turn it on

Choose your trigger

Run manually when onboarding, picking up a ticket in an unfamiliar area, or preparing a design. Require a named feature, service, or path so the output stays useful.

What runs without you

This workflow is read-only, so the risk is staleness, not damage. After three accurate walkthroughs, let it save its output automatically as onboarding notes - but treat them as snapshots until an engineer confirms them, not as durable documentation. Regenerate after any major architecture change; an outdated walkthrough misleads more than no walkthrough at all.

Pairs well with update documentation - a verified walkthrough is halfway to the documentation page.

Refactor code safely

Best for mechanical improvements with behavior that must stay fixed

1.5 hr/wkest. time saved How this estimate is calculated

How it's done today

You inventory references, characterize current behavior, make repetitive changes across files, repair tests and types, and inspect the diff for accidental behavior changes.

How AI helps

Your agent maps every affected call site, establishes a behavior-preserving test baseline, applies the refactor in small steps, and reruns focused and broader checks after each stage.

Refactor scoped behavior must remain unchanged

Your AI agent

Builds a reference map and test baseline, performs staged edits, and stops when checks reveal a behavior change outside the agreed scope.

Refactor diff

Reference map

Check report

How to set it up

Step 1Connect your tools

Required

Code repo

Reads all definitions, references, tests, generated boundaries, and repository rules.

Writes the staged refactor on a branch.

Recommended

CI/CD

Reads the behavior baseline and required checks.

Writes focused and full-suite results.

Optional

IDE

Reads symbol references, type errors, and runtime verification.

A local coding agent can do this with repository and terminal access. Do not paste isolated files into chat for a cross-cutting refactor; the reference map is part of the work.

Step 2Build the workflow

Have the exact boundary to change, the behavior that must not change, known public APIs, test commands, and a rollback-friendly branch. Split migrations from cleanup where possible.

```text Setup prompt theme={null} Help me build a behavior-preserving refactor workflow. For a scoped refactor, change structure without changing external behavior. 1. Ask for the target, motivation, in-scope and out-of-scope areas, public APIs, performance constraints, and required checks. 2. Find every definition, reference, test, configuration, and generated boundary affected by the change. 3. Establish a passing baseline and add characterization tests where behavior is important but unprotected. 4. Propose small reversible stages and apply one stage at a time. 5. After each stage run focused tests, type checks, and lint; stop on an unexplained behavior or performance change. 6. Avoid opportunistic cleanup and preserve compatibility unless explicitly told otherwise. 7. Return the staged diff, reference map, commands, results, and rollback note. ```

What good looks like

The external behavior and public interfaces should remain unchanged, all references should be accounted for, the diff should contain only the agreed structural change, and tests should pass before and after each stage.

Step 3Turn it on

Choose your trigger

Start manually from an approved technical task. Exclude emergency production fixes, broad “clean up the codebase” requests, and migrations that intentionally change behavior.

What runs without you

Refactors never graduate to autonomy - every stage stays reviewed and merges small. What the agent earns over time is scope: start with renames and extractions before trusting it with module boundaries. Recheck how it finds references whenever the language tooling changes; a refactor that misses one dynamic call site is worse than no refactor.

Pairs well with generate tests and review pull requests - characterization tests and a careful first pass are what make staged refactors safe.

Update documentation

Best for keeping reference and runbook changes beside the code change

1 hr/wkest. time saved How this estimate is calculated

How it's done today

After code changes, you locate every affected README, reference page, example, runbook, and diagram, then rewrite them while checking that commands and names still match the implementation.

How AI helps

Your agent reads the diff, finds documentation that describes the changed behavior, updates examples and commands, and flags pages that appear stale or need a product decision.

Code change ready behavior or interface changed

Your AI agent

Maps the diff to affected reader tasks, updates the nearest sources of truth, and validates commands, links, names, and examples.

Docs changes

Example updates

Stale-page list

How to set it up

Step 1Connect your tools

Required

Code repo

Reads the code diff, tests, examples, changelog, and documentation references.

Writes documentation changes stored with the code.

Recommended

Docs

Reads external guides, runbooks, architecture pages, and style guidance.

Writes reviewable updates or an affected-page list.

Optional

CI/CD

Reads documentation link, snippet, and example-validation results.

Point the agent at the diff and documentation roots. If external docs are not connected, have it produce a precise patch list with old and replacement text for each page.

Step 2Build the workflow

Have the final diff, docs style guide, ownership map, link and snippet checks, and an example of a good release-linked documentation update.

```text Setup prompt theme={null} Help me build a documentation-update workflow. When a code change affects reader-visible behavior, find and prepare every necessary documentation update for review. 1. Read the diff and state what changed for users, operators, integrators, and developers. 2. Search documentation, examples, READMEs, runbooks, changelogs, and diagrams for the changed names, commands, behavior, and concepts. 3. Classify each match as update, verify, or unaffected; do not rewrite pages that merely share a word. 4. Update procedures, examples, expected output, links, and version notes using the documentation style guide. 5. Run available link, snippet, and example checks and manually verify commands that can run locally. 6. Flag uncertain ownership or product wording instead of inventing it. 7. Return the docs diff and a checklist mapped to the code change. ```

What good looks like

Every affected reader task should remain accurate, examples and commands should work, stale names and links should be gone, and the documentation diff should explain the behavior rather than repeat implementation details.

Step 3Turn it on

Choose your trigger

Run when a pull request changes a public interface, command, workflow, configuration, or operational procedure. Skip internal-only refactors that do not affect documented behavior.

What runs without you

Documentation changes stay reviewed alongside the code change they belong to. After five accurate change-to-page mappings, let the agent attach its docs checklist to qualifying pull requests automatically - the author confirms it instead of reconstructing it. Audit for stale pages quarterly; this workflow only catches drift for changes that go through review.

Pairs well with implement features and understand codebases - both create the change context the docs update needs.

Investigate incidents

Best for assembling the timeline and evidence while responders stay focused

0.5 hr/wkest. time saved How this estimate is calculated

How it's done today

Responders jump between alerts, logs, traces, deployments, chat, and code while someone manually reconstructs the timeline and tries to separate symptoms from the likely change.

How AI helps

Your agent gathers the bounded evidence pack, correlates alerts with deployments and code paths, maintains a timestamped timeline, and prepares hypotheses and follow-up work for the incident lead.

Incident declared service and time window set

Your AI agent

Builds a live evidence timeline, links symptoms to recent changes and affected paths, and updates hypotheses without taking production action.

Incident timeline

Evidence links

Follow-up tasks

How to set it up

Step 1Connect your tools

Required

Observability

Reads alerts, logs, traces, dashboards, service health, and the incident time window.

Recommended

Code repo

Reads recent deployments, commits, runbooks, ownership, and relevant code paths.

Optional

Chat

Reads incident-channel decisions and timestamps.

Writes concise evidence updates for the incident lead to review.

Issues

Writes approved remediation and prevention follow-ups after the incident.

Export the relevant logs, deploy history, and incident chat for the defined time window. Do not give the agent unrestricted production action; its default role here is evidence and coordination.

Step 2Build the workflow

Have the affected service, start time, impact, incident channel, dashboard links, deployment history, runbooks, and a named incident lead who decides actions.

```text Setup prompt theme={null} Help me build an incident-investigation workflow. When an incident is declared, maintain an evidence-backed timeline and support the incident lead. Never change production or communicate externally. 1. Ask for affected services, impact, start time, known symptoms, incident lead, evidence window, dashboards, deployments, and runbooks. 2. Collect alerts, logs, traces, deploy events, and decisions with exact timestamps and links; keep observed facts separate from hypotheses. 3. Correlate the first symptoms with recent changes and the relevant code paths. 4. Maintain ranked hypotheses with supporting and contradicting evidence, and state the next observation that would distinguish them. 5. Update a concise timeline and surface material changes to the incident lead. 6. After resolution, draft the impact summary, root-cause evidence, and follow-ups. 7. Test the workflow on three past incidents before enabling it live. ```

What good looks like

The timeline should use exact timestamps and source links, hypotheses should never be reported as facts, evidence should stay within the incident scope, and follow-ups should map to observed failure modes.

Step 3Turn it on

Choose your trigger

Run when an incident record is created with an affected service, lead, and time window. Exclude low-priority alerts and automated flapping unless a human declares an incident.

What runs without you

Evidence collection can run automatically from the moment an incident is declared - that is the point of the workflow. Remediation and every external or company-wide message stay with the incident lead, permanently. After each incident, spend five minutes on what the agent missed or mis-linked; that review is what makes the next timeline trustworthy.

Pairs well with investigate bugs and update documentation - the incident evidence pack becomes the bug reproduction, and the postmortem becomes the runbook update.