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/fileThis 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 observationdef 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
- 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.