Coding & Developer-Tooling Use Cases Basics

8 examples to get you started with coding-agent use cases - 5 basic and 3 intermediate.

You will walk a minimal read → edit → test loop, package a task for an agent, and see how review and stop conditions turn a demo into something a team can trust.

Prerequisites

• A small local repo you can break safely (or a throwaway clone)
• Ability to run your project's tests or a single unit-test file
• Comfort with diffs, branches, and basic shell commands
• Optional: any coding-agent CLI or IDE agent that can run tools in a workspace

# Example: work on a disposable branch
git switch -c agent-sandbox-demo
# Know how to run a narrow check, e.g.:
# pytest tests/test_math_utils.py -q
# npm test -- path/to/file

This section is concept-heavy.

Snippets below are patterns, not a full framework. Swap command names for your stack.

Basic Examples

1. Name the Goal as a Verifiable Outcome

Agents thrash when the goal is vibes.

Write the task the way you would write an acceptance check.

Goal: In math_utils.py, fix divide(a, b) so b == 0 raises ValueError("division by zero").
Done when: pytest tests/test_math_utils.py passes.
Out of scope: other modules, refactors, dependency upgrades.

• A good coding-agent task is a contract, not a chat prompt.
• Include path hints and the exact check command when you can.
• "Make it better" is not a use case; it is a wish.

Related: How Coding Agents Changed Day-to-Day Software Development

2. Give Read Tools Before Write Tools

Start the mental model with observe, not patch.

# Conceptual tool surface (host registers these for the model)
TOOLS = {
    "search": "find paths/symbols by regex",
    "read_file": "return file contents or a line range",
    "list_dir": "list a directory",
}
# No apply_patch / shell yet

• Most failures begin with wrong context, not wrong syntax.
• Force exploration first on unfamiliar code.
• Read-only runs are also a safe onboarding mode for new team members.

3. Apply a Small Patch, Not a Rewrite

Prefer surgical edits over regenerating whole files.

--- a/math_utils.py
+++ b/math_utils.py
@@ def divide(a, b):
-    return a / b
+    if b == 0:
+        raise ValueError("division by zero")
+    return a / b

• Multi-file agents still win by many small diffs, not one giant rewrite.
• Smaller patches are easier to review and revert.
• Teach the agent your repo's patch format (unified diff, apply tool, etc.).

4. Close the Loop with a Test Command

Without a verifier, you only have speculative code generation.

pytest tests/test_math_utils.py -q
# Agent treats exit code + stdout/stderr as the observation

def after_edit(run_shell):
    result = run_shell("pytest tests/test_math_utils.py -q")
    return {
        "exit_code": result.code,
        "output_tail": result.stdout[-2000:],  # truncate for context
    }

• The observation is data for the next decision.
• Truncate long logs so the context window stays usable.
• Prefer the narrowest suite that still proves the goal.

5. Bound the Run: Turns, Paths, and Stop Rules

Coding agents need the same stop discipline as any agent.

policy = {
    "max_turns": 12,
    "allowed_paths": ["src/math_utils.py", "tests/test_math_utils.py"],
    "allowed_commands": ["pytest tests/test_math_utils.py -q"],
    "stop_on": ["tests_passed", "max_turns", "path_violation"],
}

• Path allowlists prevent "helpful" drive-by refactors.
• Command allowlists reduce shell risk.
• Always return a controlled stop reason, not a hang.

Related: Autonomous Bug-Fixing Agents: From Issue to Verified Patch

Intermediate Examples

6. Package a Ticket the Agent Can Actually Own

Move from a toy function to a realistic issue shape.

Title: API returns 500 when page is negative
Repro: GET /items?page=-1
Expected: 400 with {"error": "page must be >= 1"}
Hints: src/api/items.py, tests/api/test_items.py
Verify: pytest tests/api/test_items.py -q
Do not: change auth, database migrations, or public URL paths

• Bug tickets with repro steps are among the best early coding-agent use cases.
• Explicit "do not" lists beat hoping the model guesses culture.
• Attach failing test output when you already have it.

7. Separate "Agent May Propose" from "Agent May Merge"

Day-to-day safety is a permissions ladder.

Level A: agent edits only; human runs tests and commits
Level B: agent edits + runs tests in sandbox; human opens PR
Level C: agent opens draft PR; human reviews and merges
Level D: auto-merge only for allowlisted chore classes (rare)

• Most teams should live in B/C for a long time.
• Merge rights are a product decision, not a model capability.
• Log who (human or bot) approved each step.

8. Review the Trace, Not Only the Diff

When something is wrong, the trajectory explains why.

turn 1: search "divide" -> math_utils.py
turn 2: read_file math_utils.py
turn 3: apply_patch (+ guard for b == 0)
turn 4: shell pytest ... -> FAIL (test expects message "division by zero")
turn 5: apply_patch (adjust message)
turn 6: shell pytest ... -> PASS
stop: tests_passed

• Traces teach you whether the agent explored well or guessed.
• Keep tool args and outputs redacted of secrets.
• Use traces in retrospectives the same way you use incident timelines.

Related: Code Review Agents: Automated PR Feedback at Scale

Related

• How Coding Agents Changed Day-to-Day Software Development - why the workflow shifted
• Code Review Agents: Automated PR Feedback at Scale - PR feedback use case
• Autonomous Bug-Fixing Agents: From Issue to Verified Patch - full fix loop
• Test-Generation and Coverage Agents - tests as agent work
• Coding & Developer-Tooling Use Cases Best Practices - scoping and review habits

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.