AI

I rewrote this post because the first version aged badly. The 2023 cut was a list of prompts you typed into a chat box: ask, copy, paste, repeat. That is still how most of us drive a 2026 model: one tab open in the corner, an endless wall of paste, the model never once looking at the code we are actually in. The models got an order of magnitude better. The way we use them mostly did not.

So this version climbs instead of sprawling. It is 101 uses arranged as a seven-rung ladder, least effort at the bottom, most autonomy at the top. Rung one is a single prompt with zero setup: the git incantation you look up for the hundredth time, the timezone math you always get subtly wrong, the shell one-liner you would otherwise spend ten minutes assembling. Each rung up adds one thing the rung below it could not do: eyes, then your own context, then a job to run, then hands to run it with. By the top, the model is not answering you. It is standing infrastructure you maintain. These are the durable workhorses a working engineer reaches for daily, not the demo-day party tricks.

One caveat holds at every rung: none of it ships on its own. You still read the diff. You still run the tests. You still own whatever merges with your name on it.

Contents

1. Tier 1: One-Line Magic
2. Tier 2: See, Hear, Speak
3. Tier 3: Bring Your Own Context
4. Tier 4: Make It Do a Job
5. Tier 5: Give It Hands
6. Tier 6: Set It Loose
7. Tier 7: Higher Dimensions

Tier 1: One-Line Magic

One prompt, no setup, no config file. These are the muscle-memory lookups, the error you would have pasted into a search box, the regex you would have gotten wrong twice, the cron string you can never remember the field order on, all answered in the window you are already typing in.

1. Explain a Stack Trace and Trace It to the Root Cause

Paste the full error, or let the agent read it, and get a plain-English account of what failed, where, and why, plus a ranked list of likely causes before anyone touches code. The win is that the model reads the frame, the line, and your surrounding code together, instead of you matching the message to the nearest Stack Overflow answer and hoping the versions line up. Run it inside a CLI coding agent (Gemini CLI, Claude Code, Codex, Cursor) and analyze-first, fix-second: the agent opens the files named in the frames itself rather than guessing from a bare string, and practitioners have formalized this as a two-step gather-narrow-fix method. It proposes a cause, not a verified one, so confirm before you change anything.

Prompt

"Here's the full stack trace and the function it points into. Explain in plain English what failed and why, rank the two or three most likely root causes, and propose the smallest fix. Don't change anything yet."

2. Generate a Regex From English and Decode One You Inherited

Describe the pattern in words and get a working regex plus a token-by-token breakdown, or paste a cryptic one and get it annotated in place. Regex is write-once, read-never, nobody remembers lookahead syntax, and the inherited pattern is pure archaeology. Staying in your editor is what makes this stick: an inline assistant writes the pattern, annotates an existing one on hover, and a coding agent runs it against real sample data in your repo and self-corrects. Testing the output is the one thing you can't outsource, so treat the result as a draft.

Prompt

"Write a regex that matches a US phone number with optional country code and any of dot/dash/space separators, and give me a one-line explanation of each group."

3. Write SQL From an English Question Against Your Schema

Hand the model your table definitions and a plain question, get a runnable query in your dialect. Gone: the hand-written joins, the GROUP BY and window-function boilerplate, the date math you re-derive every single time, and on an unfamiliar schema the spelunking through column names. Wire text-to-SQL to the live schema and the model writes against actual primary and foreign keys instead of guessing: paste DDL for a one-off, or let a coding agent introspect the real database, then run and validate. Review it before you point it at prod.

Prompt

"Given these CREATE TABLE statements, write a Postgres query for the top 10 customers by total order value in the last 30 days, with their order count."

4. Explain and Rewrite an Inherited SQL Query

You inherited a 200-line query and you have to change one thing in it without breaking the other 199 lines. Get a step-by-step plain-English breakdown of what each CTE and window function does, then a cleaner rewrite that returns identical results, so the cleanup is about behavior equivalence, not comprehension alone. Run it inside the IDE or CLI agent (Cursor, Claude Code, Gemini Code Assist, DataGrip's AI Assistant) with the schema already in context, so the explanation and the rewrite reference your real table and column names rather than generic placeholders. Diff the two outputs against the same data before you trust the rewrite.

Prompt

"Explain what this query does step by step, flag anything that looks wrong, then rewrite it more readably and prove the result set is identical (same rows, same order) on this sample data: <paste SQL>."

5. Write or Decode a Cron Expression in English

Say when you want it to run, get the five-field cron string plus the next few fire times. Paste a cryptic schedule, get it explained. No more crontab.guru round-trip, no more recurring "is field four month or day-of-week?" doubt. Cron is the cleanest case where a model beats a lookup tool: it does "last Friday of the month" or "every weekday except holidays" in one shot, and inside an agent it writes the entry straight into your crontab or a Kubernetes CronJob with the schedule explained inline. Confirm the next runs match what you meant.

Prompt

"Give me a cron expression for every weekday at 6:30am, and tell me the next five times it fires."

6. Write the jq, awk, or sed One-Liner From a Description

Describe the JSON reshape or text transform in English and get the exact jq, awk, or sed pipeline back, already run against your data. Re-learning jq's syntax, awk's field semantics, and sed escaping every few weeks is the canonical "I know it's a one-liner but I'll lose 15 minutes" tax. Foundation models are unusually fluent here because shell text-processing is heavily represented in training data; reach for a terminal-native tool like Simon Willison's llm-jq, which pipes your file in, generates the program, and executes it so you see the output before it lands in a script.

Prompt

llm jq 'group by status and give me the count of each'

7. Turn Plain English Into the Exact Shell Command

Describe the ops task and get the precise command (find, tar, ffmpeg, kubectl, aws), staged in your prompt for you to review and run. No more context-switch to a man page for the tar, find, and ffmpeg flags you use twice a year, and the command lands ready to edit instead of buried three paragraphs into a chat answer. Reach for a terminal-native wrapper like llm-cmd, which pre-fills the command inline so you press Enter to run, edit, or Ctrl-C to cancel, never auto-running. That review-before-run beat is the entire safety model on anything destructive, so don't skip it.

Prompt

llm cmd 'find every file over 100MB modified in the last week and show sizes human-readable'

8. Translate a Snippet Between Languages, Idiomatically

Paste a function in one language and get an idiomatic port that respects the target's conventions, not a transliteration. You stop manually mapping idioms (Python comprehensions to Go loops, callbacks to async/await, dicts to structs) and re-looking-up the target's stdlib equivalents, which comes up whenever you port an algorithm, share logic across services, or read code in a language you don't write. Models beat rule-based transpilers handily on idiomaticity; run it through a coding agent that ports the code and writes a quick test to prove behavior matches, since idiomaticity degrades past around 100 lines.

Prompt

"Port this Python function to idiomatic Go: use error returns instead of exceptions, and a struct instead of a dict."

9. Learn a New Language or Framework by Translating What You Know

Hand the model code in a language you know and ask for the idiomatic equivalent in the one you're learning, with the reasoning for each change. You learn just-in-time by mapping concepts you already hold onto new syntax, which is the fastest on-ramp when you're a polyglot picking up the team's stack, and it beats reading a whole tutorial before you can write a line. Ground the loop in current docs ("is this idiomatic, or am I writing Rust like a Python dev?") by pairing it with Context7, an MCP server that feeds version-specific library docs into the agent, so the idioms reflect the live API instead of a 2022 pattern the model half-remembers.

Prompt

"I know Python well. Show me the idiomatic Rust equivalent of this script, and call out where my Python instincts will lead me to non-idiomatic Rust."

10. Explain an Unfamiliar Code Snippet

A dense function lands in front of you, or a clever one-liner, or your own code from six months ago, and you have no idea what it does. Get a line-by-line walkthrough in plain English with anything surprising called out, instead of tracing it by hand or hunting the author on Slack. Beyond a chat paste, a one-key "Explain" inside the agent reads the symbol in its file context (callers, types, imports) rather than the isolated snippet, so the explanation reflects how the code is actually used, not how it looks in a vacuum. It notices what you miss and misses what you notice, so verify.

Prompt

"Explain what this does, line by line, and call out anything surprising or non-obvious: <paste snippet>."

11. Explain What a Command or Flag Actually Does

Paste a gnarly invocation (the tar spell, the ffmpeg flags, the docker run args) and get each flag explained, or get the command you need from a description. CLI tools carry hundreds of flags, man pages are a wall, and you hit the same "what does -z do again" lookup constantly. This pulls the explain-and-generate loop in-terminal: llm-cmd-style tools generate the command and pre-fill your prompt for review, never auto-running, so it lives where you type instead of in a tldr/cheat.sh browser tab.

Prompt

"Explain every flag in `tar -xzvf archive.tar.gz -C /opt`, then give me the version that lists contents without extracting."

12. Name the Pattern or Smell and Suggest the Fix

Paste a chunk of code and ask what design pattern it is, or what smell it carries, and what the idiomatic refactor would be. Putting a name to a structure ("this is a visitor", "this is a god object") unblocks the refactor conversation and saves you flipping through Refactoring or the GoF book to guess the vocabulary in review. Use it to generate the candidate vocabulary and refactor direction, then check the work yourself: models can misidentify and fail to conform to design patterns, so don't apply the suggested rewrite blind.

Prompt

"What design pattern is this, what code smells does it have, and what's the cleaner idiomatic version? <paste>"

13. Generate the Unit Tests You Keep Avoiding

Point the agent at a function and get a passing, conventions-matching test file in one shot. This is the single most common reason devs reach for an agent during normal feature work: it kills the slow, dreaded ritual of hand-writing boilerplate setup, arrange/act/assert blocks, and the obvious-but-tedious cases for code you already understand. Use an in-editor or CLI agent (Cursor, Claude Code, Gemini CLI, Gemini Code Assist) that reads the surrounding test file, copies its conventions, and actually executes the suite to confirm green before handing it back, not a paste-into-chat snippet you fix by hand. Read the tests: a green suite that asserts the wrong thing is worse than none.

Prompt

"Write unit tests for the functions in src/auth/token.ts. Match the style and fixtures already used in the existing tests, cover the happy path and the error branches, and run them until they pass."

14. Surface the Edge Cases You Missed

The cases that bite in prod are the ones you didn't think of. Have the model enumerate the boundary, null, overflow, unicode, concurrency, and error-path inputs your tests skipped, then write one for each; a model is unusually good at brainstorming the off-nominal inputs a tired human glosses over, which is the exact gap between a passing suite and a solid one. Ask for both concrete edge cases and invariants: a 2025 study found example-based and property-based prompting each caught about 69% of injected bugs alone, but combining them hit 81%.

Prompt

"Here is my function and its current tests. List the input edge cases I'm not testing (boundaries, empty/null, unicode, very large inputs, concurrent calls, partial failures) and write a test for each."

15. Translate a Technical Change for a Non-Engineer Audience

Devs constantly re-pitch their work upward: a release note for support, a "what shipped" line for a PM, a status for a customer. Rewrite a diff or PR summary into plain English that leads with user-facing impact, and you stop rewriting the same explanation three ways by hand. This is the one classic chatbot use that stayed a daily driver, because every engineer still has to explain technical work to people who don't read diffs, and the agentic version pulls the facts from the diff itself rather than you typing the bullets. Lead with the business problem, swap jargon for outcomes.

Prompt

"Rewrite this PR summary for a non-technical PM: lead with the user-facing impact, drop the jargon, and state it in terms of what changes for customers and any risk. Keep it to four sentences."

16. Replace the Search-Engine-and-Stack-Overflow Loop With a Direct Answer

Ask "how do I do X in this language or framework" and get one worked, version-aware answer with the reasoning attached, instead of the open-five-tabs ritual: search query, skim the answers, reconcile stale and contradictory replies, adapt to your version. This is the default first move for most devs now, not the exception. The 2025 Stack Overflow survey puts it at 84% using or planning to use AI tools (up from 76% in 2024), and 51% of professional developers daily. Ask inside the IDE or CLI agent so it sees your file, your version, and your actual symbols.

Prompt

"In Go, what's the idiomatic way to run N HTTP requests concurrently with a bounded worker pool and collect results? Show the code and explain the gotchas."

17. Generate the Commit Message From Your Diff

Stage your changes and get a clean Conventional Commits message written from the actual diff, not a "fix stuff" placeholder. Every commit needs a message, "eh, fix stuff" is the daily temptation, and you stop staring at the diff trying to summarize your own change a dozen times a day. A terminal tool reads git diff --staged and emits Conventional Commits in a couple of seconds via a prepare-commit-msg hook (aicommits, gptcommit), no manual copy-paste. Diff-only context can miss the why, so edit before committing.

Prompt

"Wire it up once: `aicommits`, or pipe `git diff --staged` to an llm command, then accept or tweak the generated message."

Tier 2: See, Hear, Speak

Now the model gets eyes and a voice. A screenshot of a broken layout, a stack trace you can't even select, the console and network panel mid-failure, a whiteboard photo, a bug you'd rather just say out loud: all of it becomes input the model reads off the pixels and reasons about against your actual code.

18. Screenshot a Broken UI and Get the Fix

Writing five paragraphs to describe a visual bug is its own special torture, and so is poking at DevTools guessing which rule wins the cascade. Drop in a screenshot instead: the model reads the padding, the overflow, the z-index off the pixels, and one image carries spacing and stacking and color that you'd otherwise transcribe by hand. Paste it straight into a coding agent that already has your files open (Cursor's chat panel, Gemini Code Assist, or Claude Code via Ctrl+V (Alt+V on Windows/WSL)), so the model sees the busted layout and the actual stylesheet together rather than a disembodied chatbox that can't see your code. It guesses wrong sometimes, so confirm the fix in the browser before you commit it.

Prompt

"[screenshot] this card overflows its container on mobile and the badge sits behind the title. here's the JSX and the Tailwind classes. what's the fix?"

19. Screenshot an Uncopyable Error Dialog or Terminal Stack Trace to the Root Cause

Some errors won't let you copy them: a GUI modal with no select handle, a wrapped multiline trace that reflows into garbage when you drag across the terminal. Point your phone or the screenshot key at it. Multimodal models read the text out of the image, so the red wall of pixels becomes a debuggable input, and the better move is asking for the category and the origin, not just a restatement: what is this trying to do, what kind of failure is it, and where did it actually start. Pairing it with a coding agent that then opens the offending file and proposes the patch is the upgrade over a read-only explanation. Practitioners now paste the trace and ask the model to trace it to the root cause before fixing anything, and the same idea works on a cryptic error you can only photograph off the screen.

Prompt

"[screenshot of stack trace] explain what this is actually trying to do, what category of error it is, and trace it to the root cause before suggesting a fix."

20. Screenshot the DevTools Console and Network Panel and Let the Model See the Runtime State

One image of the console errors and the network tab carries more than you could type: the thrown error, the failing XHR, the red status code, and the broken UI, all at the runtime moment they coincided. The model correlates the symptom with the code instead of you transcribing each line and describing browser state in prose. The part that's new is that this happens inside the coding loop: Claude Code, Cursor, and ChatGPT all accept a pasted or dropped screenshot, and Claude Code reads an image straight off the clipboard in the terminal, so a console error and a failing request become a first-class debug input rather than something you retype. It reads the symptom off the pixels; confirm the failing request in the browser before you commit the fix.

Prompt

Paste a screenshot into your coding agent showing the misrendered component plus the DevTools console and network tab, and ask: what's causing this, which request failed, and which component is responsible?

21. Talk Through a Bug by Voice

Typing a long, rambling bug description is slower than just saying it, and the typing is what knocks you out of flow when you're rubber-ducking something gnarly. So narrate the symptom the way you'd explain it to a colleague and let the agent reason about causes against your codebase, ranking what to test next. Claude Code shipped a built-in /voice (push-to-talk, around 20 languages, recognizes technical jargon), and the mbailey/voicemode MCP runs local Whisper plus Kokoro for fully offline speech. This is real speech-to-text inside the agent loop, not dictating into a chatbox, though it still mishears the occasional symbol name, so glance at the transcript before it acts.

Prompt

"the checkout button works locally but 500s in staging only when the cart has more than ten items. walk me through likely causes."

22. Turn a Design Mockup Into a Working UI

Hand-translating a static design into markup and utility classes is the slow first pass, and it's where the afternoon used to go. Drop a high-res mockup or a Figma frame and you get a real component that replicates the layout, colors, and hierarchy: an 80% starting point in seconds, then you refine it conversationally. v0 by Vercel takes screenshots and wireframes and emits Next.js plus Tailwind plus shadcn/ui, and in 2026 it scaffolds multi-page apps with routing; the agentic part over a raw vision call is that it keeps project context so you iterate on the generated code instead of re-one-shotting HTML. It nails the look long before it nails the behavior, so the wiring and the edge states are still yours to finish.

Prompt

"build this mockup as a responsive React component with shadcn/ui; the cards are clickable and the right rail is sticky on desktop."

23. Turn a Whiteboard Photo Into a Diagram or Scaffold

Redrawing a whiteboard from memory into a diagramming tool after every design session is the chore everyone avoids, which is why the diagram never gets made. Photograph it once instead: current multimodal models read the hand-drawn boxes, arrows, and labels and emit diagram-as-code (Mermaid) you can commit, or hand the parsed structure to a coding agent to scaffold the services. You get an editable, version-controllable artifact out of a phone snap. Ask it to flag any arrow whose direction is ambiguous, because that's exactly where it'll quietly invent an answer.

Prompt

"[photo of whiteboard] convert this system sketch into Mermaid; label the queues and the data stores, and flag any arrow that's ambiguous about direction."

24. Threat-Model a Design From a Diagram or a Whiteboard Photo

Security review is cheapest before the first commit and the meeting you skip when no security engineer is free. Hand the model your architecture diagram, the Mermaid source, or a phone photo of the whiteboard and it reasons over the actual topology, not a generic "list me some threats" prompt: for each trust boundary it names the realistic threats, the data crossing it, and a concrete mitigation, mapped to STRIDE. Modern tools ingest the diagram directly, whether it's draw.io, Threat Dragon, or a whiteboard screenshot, and 2025 extensions like ASTRIDE add LLM-specific categories such as prompt injection and unsafe tool invocation for agentic systems. It reasons over your real boundaries, so check the mitigations against your actual stack before you act on them.

Prompt

"[photo of the whiteboard / mermaid diagram] Threat-model this design with STRIDE. For each trust boundary list the realistic threats, the data that crosses it, and a concrete mitigation. Call out auth, secrets, and any untrusted input."

25. Paste a Failing Chart and Ask Why It Looks Wrong

A chart's defect is visual: a clipped label, a squished category axis, a swapped series, a log scale that renders with linear-looking gridlines. None of that is obvious in the plotting code alone, so you end up eyeballing the figure and the source at the same time. Show the model the rendered plot and it connects the symptom to the offending line. GPT-4o, Gemini, and Claude read axes, legends, and data patterns straight off the image; the better loop hands the diagnosis to a coding agent with code execution so it reruns the script and regenerates the figure to confirm the fix instead of guessing at it.

Prompt

"[screenshot of matplotlib chart] the y-axis is log but the gridlines look linear and the legend covers the trend line. here's the plotting code, what's off?"

Tier 3: Bring Your Own Context

One screenshot was the ceiling a tier ago. Now you hand the model the whole repo, the git history, a stack of design docs, a SAST dump, and it reasons across all of it, answering questions you couldn't have aimed at any single file.

26. Ask Questions Across an Entire Repo Without Picking the Files

The grep-guess-grep-again ritual only works once you know the project's vocabulary, and you don't yet. Ask "where do we handle X?" in your own words and a coding agent (Gemini CLI, Cursor, Claude Code, Codex) finds the files even when your search term appears in none of them, because it matches meaning instead of strings. Cursor reports that semantic search plus grep answered codebase questions 12.5% more accurately than grep alone, with the gap widest on repos past 1,000 files. It still occasionally points at the wrong module, so confirm the files it names before you trust the map.

Prompt

"@codebase Where do we handle authentication, and what's the full list of files involved from the login route to the session store?"

27. Onboard to an Unfamiliar Codebase by Asking It Questions

Joining a project, inheriting a service, or cracking open a dependency's source all start the same way: an hour of grep, jump-to-definition, and reading scattered modules to build a mental model. Point an agent at the tree and ask where the auth flow lives, what calls a function, or how a checkout request travels from the HTTP handler down to the database write. The agent traverses the repo itself, follows call graphs, reads implementations, and can emit a structured onboarding map plus a starter CLAUDE.md, none of which a chatbox full of pasted files can do. Treat the map as a lead: it'll confidently describe a path that one refactor ago stopped being true.

Prompt

"In this repo: where is payment status updated, what calls that function, and trace a checkout request from the HTTP handler down to the database write."

28. Turn Any Public Repo Into a Browsable Wiki and Chat With It

Before you adopt or debug an unfamiliar dependency, you usually clone it just to understand how it works. Swap github.com for deepwiki.com on any public repo and get an auto-generated wiki with architecture diagrams, source links, and a Q&A box over the code, no clone required. DeepWiki pre-indexed 50,000+ of the top public repos, so for popular libraries the architecture overview and a grounded "which file implements retries?" answer are there in seconds. The generated docs can drift from a fast-moving repo, so check the source links it cites rather than the prose alone.

Prompt

"Open deepwiki.com/<org>/<repo>, skim the generated architecture overview, then ask: How does this library handle retries and backoff, and which file implements it?"

29. Ask Why a Piece of Code Exists Across Git History

The move before you "clean up" code that looks weird but turns out to be holding something together: blame the line, find the PR, read the linked issue, reconstruct the intent nobody remembers. Agents now run git themselves, and tools like git-why turn raw blame plus commit history into a readable narrative of why a line is there and whether the original reason still holds. The history only tells you what the messages recorded, so a terse "fix tests" commit yields a confident guess, not a fact.

Prompt

"Run git log/blame on this function and read the relevant commit messages and diffs. Explain why this code exists, what bug or requirement it was responding to, and whether the original reason still holds."

30. Catch Up on a Long Issue, RFC, or PR Thread in 30 Seconds

A 120-comment GitHub issue holds exactly one thing you need: the decision that got made. Have the model compress the sprawl into what was decided, what's still contested, who owns the next step, and the handful of links and code refs actually worth opening. This is its own job, distinct from summarizing a PR's diff (that reads code) or citing across a doc set (that reads static docs): here the model reasons over a long, branching human conversation. GitHub is shipping native AI summaries of issues and discussions, and devs also wire an agent at the source so the summary is grounded in the real thread and the linked code, not a copy-paste. A terse thread yields a confident guess, so check the linked decision before you act on it.

Prompt

"Summarize this 120-comment GitHub issue: what was decided, what's still contested, who owns the next step, and the 3 links/code refs I actually need to read."

31. Summarize a Pull Request So You Can Review It

Reading a 600-line diff cold to work out the shape of a change, before you can judge any of it, is most of what review costs. A summary gives you a prose overview plus a per-file breakdown and a risk flag first, so you arrive at the diff already knowing where to look. Copilot PR summaries shipped with Copilot Enterprise's GA in February 2024 and generate the prose-plus-impacted-files writeup from the diff on demand; from there a Copilot or CodeRabbit review reads the full change with whole-repo context and posts inline comments. The summary orients you, it doesn't review the code for you.

Prompt

"Summarize this PR: a prose overview of what it changes and why, then a bulleted list of the impacted files and what each change does. Flag anything that looks risky or out of scope."

32. Diff Two Versions Semantically, Ignoring the Line Noise

A textual diff buries the one logic change that matters under whitespace, renames, and reorders, and you squint past all of it to find it. Hand a long-context model both whole files and ask only where behavior changed: what the old behavior was, the new behavior, and what breaks for callers. Because it reasons over the whole repo, not only the two files, it surfaces how the change ripples through callers, the cross-cutting read a plain git diff and a human skim can't express. It can also wave off a subtle behavioral shift it judged cosmetic, so this narrows where you look rather than ending the read.

Prompt

"Compare these two versions of the payments module. Ignore formatting and renames. Tell me only where the actual behavior changed, what the old behavior was, the new behavior, and what could break for callers."

33. Review Your Own Diff With a CLI Agent Before a Human Sees It

The last eyeball pass over your own diff before you push is exactly where you reliably miss the dumb stuff: a leftover console.log, an unhandled error branch, a name that doesn't match the file's conventions. Run a local agent command over your working tree (Claude Code's /review, Cursor's review, or a CLI plugin like sun-praise/opencode-review that runs the review on your laptop with auto-fix) and it reads the diff plus the surrounding files, catching things a static linter can't. It also raises non-issues and the occasional confident-but-wrong flag, so you triage its list; it doesn't approve your own PR for you.

Prompt

"Review my staged changes (git diff --staged). Flag correctness bugs, missed edge cases, leftover debug/console code, and anything that doesn't match the surrounding conventions. Be terse; only real issues."

34. Pin Legacy Behavior With Characterization Tests Before Refactoring

The real risk in refactoring untested code isn't that it's messy, it's that you change behavior and nobody notices for a quarter. Characterization tests are the net: golden-master tests that capture what the code does today across representative inputs, without judging whether that's correct. Generating them by hand is the chore that stops people refactoring at all, so let the agent baseline first, then refactor in small PRs gated by those tests in CI. Sanity-check the generated cases, since a test that pins a bug as "correct" will happily block the fix.

Prompt

"This module has no tests. Generate characterization (golden-master) tests that capture its current behavior across representative inputs so I can refactor it safely. Don't judge correctness, just pin what it does today."

35. Get a First Draft of a Design Doc, RFC, or ADR

The structure of a design doc (context, goals and non-goals, alternatives with trade-offs, rollout, open questions) is half the work and the part people skip. Hand the model your team's template and the relevant code and it fills the scaffolding, so your time goes to technical judgment instead of formatting. A repo-aware agent writes the "current state" and constraints from the actual code rather than generic best practices, which a blank chat can't. The decision stays yours; it'll happily propose an "alternative" that doesn't fit your system, so you cut.

Prompt

"Draft an RFC for adding rate limiting to this service. Use our template: context, goals/non-goals, proposed design, alternatives considered with trade-offs, rollout, open questions. Ground the current-state section in this code: <repo/files>."

36. Generate a Dockerfile and CI Workflow From Your Repo

Every new service needs the same containerization and pipeline boilerplate, and the usual move is copying the last service's Dockerfile and hand-editing it. Point a whole-repo agent at the manifests and existing config and it writes a multi-stage Dockerfile and a CI workflow matched to your real runtime, keeping the base image and the test runtime on the same version. Agents now go further and draft the pipeline config from a ticket: GitLab's Duo Agent Platform turns an issue straight into a draft merge request, generating the code and the CI/CD config. Read the generated YAML closely, because a wrong base tag or an over-broad cache key passes CI and bites later.

Prompt

"Read this repo. Write a multi-stage Dockerfile (slim base, prod-only deps, non-root) and a GitHub Actions workflow that lints, runs pytest, builds the image, and pushes to GHCR."

37. Critique a Schema Before You Commit to It

This is the design review you can't always get from a senior engineer or a DBA on demand. Paste your CREATE TABLE statements and ask what's missing: the foreign key you forgot, the VARCHAR that should be an enum, the index you'll wish you had, the type that'll hurt at 10M rows, before the data lands and the change gets expensive. Feed the whole schema at once, or let the agent introspect the live DB via MCP, so the critique reasons across all the tables and their relationships rather than one table in isolation. It doesn't know your access patterns, so weigh its index advice against your real queries.

Prompt

"Review this schema for normalization problems, missing foreign keys/indexes, and column-type choices. What will hurt at 10M rows? <paste DDL>"

38. Answer Across a Whole Doc Set With Citations

Ctrl-F across a dozen PDFs, wiki pages, and an API reference, then reconciling them by hand, is what reasoning over more docs than you can hold in your head costs you. Load the pile and ask grounded questions; the answer cites back to the exact doc and section, so you can verify instead of trust. NotebookLM does this and keeps every answer tied to your uploaded sources across a growing list of source types, and Claude Projects or a docs-MCP setup give you the same citations over a private corpus. The leap is million-token whole-corpus ingestion instead of brittle manual chunking, and those inline citations are what let you catch the answer that confidently points at a section that doesn't say that.

Prompt

"I've added our 6 internal design docs and the vendor API reference. What does our auth flow assume about token refresh, and which doc and section says so?"

39. Triage Scanner Findings to Kill the False-Positive Flood

A SAST dump is mostly noise, and each false positive costs you 15 to 30 minutes to clear by hand. Feed the findings back through the model with the relevant source files and it sorts true-positive from false-positive from needs-human, reasoning over the actual data flow and input validation instead of the severity score alone. Datadog's Bits AI does exactly this, classifying findings against surrounding code context with OWASP Benchmark results to back it. It's a triage layer, not a verdict: the "needs-human" bucket is the point, and you still confirm the ones it calls real before filing them.

Prompt

"Here are 200 SAST findings plus the relevant source files. For each, decide true-positive / false-positive / needs-human, with one sentence of reasoning grounded in the actual data flow, then sort by exploitability."

40. Triage Dependency and CVE Alerts by Reachability, Not Severity

Reflexively upgrading on every red badge lets the weekly alert pile own your sprint, and most of it doesn't matter: fewer than 9.5% of dependency vulnerabilities are actually reachable from your code. Before you scramble, ask whether your code ever reaches the vulnerable function, get the call chain if it does, and a verdict of upgrade-now or safe-to-defer. The current pattern layers reachability analysis on top of Dependabot/Renovate PRs, so reachable updates get priority review and the rest get batched. Reachability analysis isn't perfect, so a "defer" on anything internet-facing still deserves a human glance.

Prompt

"This Dependabot/Renovate alert flags a CVE in <package>. Trace whether my code ever reaches the vulnerable function/path, show the call chain if it does, and tell me if this is upgrade-now or safe-to-defer."

41. Get a Plain-English, Stack-Matched Read of a CVE Advisory

Deciding whether you have to care about one CVE today usually means a 20-minute tab-storm across the NVD entry, the GitHub advisory, and three blog posts. Drop the advisory and ask what the flaw is, whether your version is actually affected given your dependencies, the realistic exploit path, and the smallest fix. The workflow matches the advisory against your actual technology stack, so you're told "this affects your version" rather than handed a boilerplate summary. With a record 48,000-plus CVEs published in 2025, the triage-to-relevance step is the whole value, and you verify the affected-version call against your lockfile before you act on it.

Prompt

"Here's a CVE advisory. Explain in plain English what the flaw is, whether MY stack/version is affected given these dependencies, the realistic exploit path, and the smallest change that fixes it."

Tier 4: Make It Do a Job

Here the model stops describing work and starts producing it: schema-valid JSON a downstream service will accept, migrations that run, scripts that execute against your actual files. What comes back is an artifact you commit, not a snippet you retype.

42. Emit Guaranteed-Shape JSON for Your Pipeline

Feed model output to a downstream service and "please respond in JSON" plus a defensive regex parser is the part that breaks at 3am. Define a schema instead and the response provably matches it: Anthropic's structured outputs and OpenAI's strict:true both use constrained decoding to force the reply into your JSON Schema, Zod, or Pydantic shape, so the parse can't fail. Generate the schema from your existing types and wire it straight into the API call.

Prompt

"Extract {title, author, published_date, tags[]} from this article as JSON conforming to this schema; reject anything that doesn't fit."

43. Extract Structured Rows From Messy Text

The recurring "I have this blob, I need clean rows" job used to mean hand-tuned regex and a pile of try/catch. Point the model at logs, support emails, or scraped pages with a strict schema and you get typed rows you load straight into a table. Simon Willison's llm schemas, plus OpenAI and Anthropic structured outputs, constrain decoding so the shape is locked under OpenAI strict mode and Anthropic structured outputs. The shape is guaranteed; the field values are still a model's best guess, so spot-check the ones that matter.

Prompt

"Extract every order into {order_id:string, total_cents:int, status:enum[paid,refunded,pending]} from these support emails. Enforce the schema."

44. Turn Raw Logs Into Structured JSON Without Regex

Half of log work is reshaping inconsistent multi-format lines into something queryable, and maintaining a grok pattern for every new format is the part that never pays off. Hand the model the lines and a target shape and you skip straight to fields you can filter on. Pair it with schema-constrained output so the JSON holds, and the advice scales: Splunk's own guidance is literally to instruct the model to return JSON rather than write regex parsers. High-volume ingestion still wants a deterministic parser; this is the ad-hoc reshape.

Prompt

"Parse these nginx error lines into JSON with fields {ts, level, client_ip, upstream, status, message}. Return one object per line, nothing else."

45. Generate and Run a Database Migration

Hand-writing up/down migrations means remembering the ORM's exact DSL and quietly hoping the down is reversible. Connect the agent to the database and it generates the migration, applies it in a sandbox, and reports what happened, so you're not running SQL text blind. Prisma Postgres exposes an MCP server for exactly this, and django-migrations-mcp wraps Django migrations with CI/CD guards. Let it run against dev; read the generated migration before it goes near prod.

Prompt

"Add a nullable deleted_at timestamp to the orders table and a partial index on non-deleted rows; generate the migration and run it against the dev DB."

46. Generate Realistic Seed and Fixture Data

Inventing plausible names, emails, and dates for local dev recurs on every feature that touches a new table. The trick is to ask for an executable generator, not raw rows. In practice the generator wins because a Faker or SQL script keeps foreign keys and distributions consistent at volume in a way inline rows don't, and research on prompting LLMs for test data confirms the models can write those generator programs well. Let the model own the text fields and a deterministic RAND/SEQUENCE handle the numbers and dates, then run the script.

Prompt

"Generate 200 rows of seed data for these three related tables (users, orders, items) that preserves foreign keys and realistic distributions. Emit a runnable Python Faker script."

47. Generate a Property-Based Test Suite From an Invariant

Property tests find bugs example tests never will, but writing the input strategies and inferring the right invariants is the part most people skip. State the property in English and the model does the inference while Hypothesis or fast-check does the search. Anthropic's January 2026 work shipped a Claude Code command that infers properties from docstrings and types, writes the tests, runs them, and files bug reports; it turned up verified bugs in NumPy's numpy.random.wald, AWS Lambda Powertools, and the CloudFormation CLI. Read the inferred invariant before you trust the green.

Prompt

"Write Hypothesis property tests for this serializer: the key property is that deserialize(serialize(x)) == x for all valid x. Generate the input strategy, run it, and minimize any failing case you find."

48. Generate the PR Description and Changelog Entry From the Diff

The PR body and the changelog line are what everyone rushes or skips, which is why so many read "various fixes." Generate both from the actual diff and the writeup matches what shipped. GitHub's "Generate with Copilot" button writes the PR body straight from the diff, and a CI Action can append the CHANGELOG entry on each push. A diff shows the what, never the why, so add the rationale the code can't carry.

Prompt

"From this branch's diff vs main, write a PR description: one-paragraph summary, bulleted list of notable changes, and any migration/breaking notes. Then append a matching entry to CHANGELOG.md."

49. Turn Your Git Activity Into a Standup or Status Update

Every dev writes the same "what I did" line daily for standup and weekly for a manager, and reconstructing it from memory is exactly the low-value recall worth handing off. Pull it from git log and gh pr list and the update is accurate rather than vibes. Tools like Gitmore read the history directly, sort commits into features/fixes/refactors, and post the summary to Slack; the grouping is computed from real activity, which is what makes it a deliverable instead of a guess. Piping the log into any coding agent does the same job.

Prompt

"Here are my commits and merged PRs since yesterday: <paste git log / gh pr list>. Write my standup as Yesterday / Today / Blockers, grouped by feature, no fluff."

50. Use Code Interpreter as a Disposable Analytical Tool

"Just look at this file" used to mean spinning up a throwaway notebook. Now a code-interpreter agent writes, runs, and debugs the pandas, polars, or DuckDB in a sandbox and hands back numbers and a chart, plus the code it ran. ChatGPT's Advanced Data Analysis executes Python server-side in a stateful sandbox, and Gemini and Claude both do the same; Claude Code's csv-data-wrangler skill auto-picks the engine by file size so it scales past chat upload limits. The same machine handles the one-time chore: hand it a folder of files and it parses, dedupes, and merges them into a finished artifact, the arithmetic executed rather than narrated and hallucinated. Simon Willison hands Claude a SQLite DB and an XLSX and gets a generated PDF back, treating the whole thing as disposable. Read the code before you quote the number in a meeting.

Prompt

"Here's a 40MB orders.csv. Find revenue by month, flag anomalies, and plot the trend. Show me the pandas code you ran."

"Here's a folder of 200 inconsistently-named log files. Parse the timestamps, dedupe, sort chronologically, and give me one merged CSV. Write and run the code; just hand me the file."

51. Vibe-Code a Single-Purpose Tool the Moment You Need One

A focused utility now costs minutes and cents, so you build the exact thing instead of hunting for a sketchy web tool and pasting your data into it. Describe the converter, diff viewer, or weird-edge-case calculator you wish existed and get a self-contained file back. Simon Willison's tools colophon lists 78 of these single-file apps built this way, and a16z's "disposable software" thesis argues small throwaway apps no longer have to justify their ROI. Review anything that touches real data before you feed it any.

Prompt

"Build me a single-file HTML tool: paste in a crontab line, render a plain-English schedule and the next 5 fire times. No build step, no dependencies."

52. Scaffold the Boilerplate Config a New Project Needs

The .gitignore, Dockerfile, CI workflow, linter config, and pre-commit hooks gate every new repo, and the usual move is copying the last project and hand-editing. A coding agent writes them for your exact stack in one pass and explains the non-obvious choices. A scaffolding skill like hmohamed01/Claude-Code-Scaffolding-Skill covers 70+ project types with DevOps-ready Docker, docker-compose, and GitHub Actions CI/CD baked in, and a Gitignore Builder skill merges verified templates from the official github/gitignore repo instead of a generic dump you wire together yourself.

Prompt

"New TypeScript + Vite project. Generate a .gitignore, a multi-stage Dockerfile, a GitHub Actions workflow that lints/tests/builds on PRs to main, an eslint + prettier config, and Husky pre-commit hooks. Explain each non-obvious choice."

53. Turn Your Git History Into a Brag Doc Before Review Season

Most "what did I even do this half" panic at 11pm is answered by the log, if something reads it for you. Point it at your commits and merged PRs and get a categorized, impact-framed accomplishment list ready to paste into a self-review; run it weekly and review season is a copy-edit, not an archaeology dig. Privacy is the reason to keep this local: your commit history and your employer are sensitive. BragDoc's CLI analyzes commits on-box and never sends your code off-device, and BragLog leans on on-device models. Piping git log plus gh pr list into a local agent works too.

Prompt

"Here are my merged PRs and commits for Q2 (git log + gh pr list output). Group them into themes, write each as an accomplishment with impact, and flag where I should add a metric I can go find."

54. Run a Deep-Research Report on a Tech Decision or Build-vs-Buy

A datastore, framework, or vendor choice that actually matters used to cost a day of twenty tabs, vendor pages, and HN threads stitched together by hand. Agentic Deep Research front-loads that into a cited report: OpenAI's Deep Research, plus the Gemini and Perplexity equivalents, plan, browse, evaluate sources, and synthesize, and ChatGPT's GitHub connector can scope the question to your codebase. The citations are only as good as your fact-check, so verify the claims the decision rests on before you commit to it.

Prompt

"Deep research: compare Postgres logical replication vs. Debezium vs. a managed CDC service for our use case (Postgres -> Kafka, <5s lag, on-call team of 3). Give a cited recommendation with tradeoffs and failure modes."

55. Generate a Typed API Client From an OpenAPI Schema

Hand-written fetch wrappers and request/response interfaces drift every time the backend renames a field. Generate the client from the spec and the frontend is checked against the contract instead. hey-api's openapi-ts, the maintained successor to openapi-typescript-codegen, emits a typed TypeScript SDK plus validators and mocks. Run it in CI and the client can't go stale against the spec.

Prompt

npx @hey-api/openapi-ts -i http://localhost:8000/openapi.json -o src/client

56. Mock an API From Its Spec So the Frontend Doesn't Wait on the Backend

Building the UI before the API exists usually means hand-writing fixtures and stubbing fetch. Generate network-level mocks from the OpenAPI spec instead and the app can't tell them from the real backend, reusable in both the browser and Node tests. MSW intercepts at the Service Worker layer, and generating the handlers plus faker-backed data straight from the spec keeps the mocks aligned with the contract as it changes.

Prompt

"From this OpenAPI spec, generate MSW handlers with faker-backed realistic data for every endpoint, including a few error responses."

57. Write Terraform and Kubernetes Manifests From a Description

HCL and K8s YAML are verbose and easy to get subtly wrong, and the scaffold (variables, locals, dependencies, provider blocks) eats the first hour of any infra change. Describe what you want and Copilot or Cursor writes it with your existing modules as context, structured output enforcing valid shape. The 2026 warning is sharp: models emit syntactically valid but semantically dead config, hallucinated arguments like a deprecated count in a module that pass parsing and fail an apply. Plan plus validate, never blind apply.

Prompt

"Terraform for an AWS VPC with 3 public + 3 private subnets across AZs, a NAT gateway, and an S3 bucket with versioning and encryption. Use variables, not hardcoded values."

58. Explain a terraform plan Before You Apply

A long plan diff is where prod gets wrecked: the dangerous line is a single -/+ replace on a database buried in 200 lines of churn. Have the model surface the destroys and replaces up front, every time, before you apply. The reliable form pipes the machine-readable terraform show -json plan to the agent rather than the pretty text, so it reasons over the structured change set and lists create/update/destroy per resource instead of eyeballing the output.

Prompt

"Here's `terraform plan -out=tf.plan` then `terraform show -json tf.plan`. Summarize what changes, flag anything that destroys or replaces a stateful resource."

Tier 5: Give It Hands

Wire an IDE or CLI agent to MCP and it stops handing you snippets to paste: it edits the files, runs the suite, drives the browser, and queries the database itself. Every new capability here is a new key on the keyring, so the discipline that scales is access discipline, scope the token, keep the role read-only, gate the writes.

59. Pull Current, Version-Specific Library Docs Into the Agent

The single most common way an agent burns a turn is inventing a method that got renamed three releases ago. Wire up a docs MCP and it fetches the exact docs for the version pinned in your package.json instead. You reach for this on almost any task that touches an unfamiliar dependency, and the newer setups auto-trigger so you don't even type "use context7". It reads docs; it doesn't validate your usage, so the code it writes around them gets the normal review.

Prompt

"use context7 for the Next.js 15 App Router docs and show the current way to set up a route handler with streaming, matching the version in my package.json"

60. Describe a Feature, Let the Agent Plan Then Make the Multi-File Edit

State the goal, point at an existing pattern directory, and the agent reads the repo, creates the six-to-twelve files, wires the routes, adds the test stubs, and runs the build. That kills the "new file, copy the neighbor, rename, register, import everywhere" loop. Pointing at a pattern dir is the move that makes it match your conventions instead of generic scaffolding. It stops at a working diff, which you read end to end before it goes anywhere.

Prompt

"Add a user settings page with email preferences, notification toggles, and a delete-account flow. Follow the patterns in app/settings/, wire the routes, add test stubs, and run the build."

61. Plan Mode: Make the Agent Write the Plan Before It Touches a File

The expensive failure in agentic coding is watching it confidently execute the wrong approach across a dozen files. A structurally-enforced plan mode blocks the write tools until you approve the numbered plan, so you read and fix the plan once instead of unwinding a bad twenty-minute run. This is the Explore, Plan, Code, Commit loop, enforced by the tooling rather than a polite request to outline first. On anything non-trivial it earns its keep.

Prompt

"Plan how to add optimistic locking to the orders table without breaking the existing API. Plan only, don't touch any files yet."

62. Rename a Symbol Across the Codebase With Its Full Blast Radius

The IDE rename follows the type graph and stops. It can't see the string literals, the JSDoc, the test names, or the config keys. An agent that renames a symbol understands its role and reaches all of it, then shows you the diff before applying, which retires the grep-and-pray you do after every "real" rename. Read the diff: it will occasionally rewrite a string that happened to match but shouldn't change.

Prompt

"Rename getUserData to fetchUserProfile across the entire codebase: imports, type references, JSDoc, string literals, test names and assertions, and config keys. Show me the diff before applying."

63. Extract a Component or Module Out of a Bloated File

Carving a god-component into named pieces is cut, paste, re-wire the imports, fix the ten call sites, and break something mid-surgery, which is exactly why nobody does it. The agent does the whole move atomically across files with a plan-mode preview first, so the extraction is one reviewable step instead of an afternoon of churn. Behavior should stay identical; the way you confirm that is the test suite, not the agent's word.

Prompt

"This file is doing too much. Extract the data-fetching and the form logic into separate modules with clear names, update all imports and call sites, and keep behavior identical. Plan first, then apply."

64. Write the README and Onboarding Docs From the Repo

The README is perpetually stale because writing it means re-deriving the project's shape, so it stays a blank page you avoid. A repo-aware agent indexes the tree, traces the entry points, and writes the setup steps from the real build files, giving you a draft to edit rather than nothing. It will get the install steps slightly wrong if your build is unusual, so run them once before you commit the doc.

Prompt

"Read this repo and write a README: what it does, how to install and run it, the main modules and how they fit together, and a quickstart. Base it on the actual code, not assumptions."

65. Backfill Docstrings and Comments for the Diff

Docstrings are the comment everyone means to write and never does. Have the editor agent fill in parameter, return, and behavior docs in your repo's existing format as part of the change, so the docs ship with the code instead of becoming a backlog ticket. Or let a CI bot like @coderabbitai generate docstrings scan the PR and open a follow-up. Skim them: a model will happily document what the code looks like it does rather than what it does.

Prompt

"Add docstrings to every public function in these files, following the existing docstring format in this repo."

66. Query Your Database in Plain English Over MCP

Connect the agent to a read-only Postgres or MySQL MCP server and ask in English. It pulls the live catalog first, writes the SQL, runs it, and retries on errors, which kills the write-run-read-rewrite loop and stops it hallucinating table names. Anthropic's original reference Postgres server was deprecated in 2025, so the maintained replacements are what you wire up now. Keep it on a read-only role and have it show the SQL it ran.

Prompt

claude mcp add postgres -- npx -y @modelcontextprotocol/server-postgres $DATABASE_URL_READONLY

67. Query a Loose CSV Set With DuckDB on the Fly

Someone hands you three CSVs and a question. The old answer was either standing up a database or hand-writing pandas merges. Point an agent at the files with DuckDB as the local engine: natural language in, DuckDB SQL out, run in-process over CSV/Parquet directly, no server. It chews through 100k-plus rows in seconds and feeds the result back for the follow-up, so the whole analysis stays SQL-shaped. Sanity-check the join keys before you trust the totals.

Prompt

"Using DuckDB over these three CSVs, join orders to customers and give me churned customers by region. Generate and run the SQL."

68. Generate Playwright E2E Tests From a Plain-English User Flow

Hand-authoring E2E selectors and waits is the most flake-prone test category devs write. Connect Playwright MCP, describe the flow, and the agent clicks through the live app and emits the spec, driving it over accessibility snapshots rather than CSS selectors so the tests survive a refactor. The Planner can explore the app and produce the plan first. The generated spec is a starting point; you still review the assertions, since a test that passes for the wrong reason is worse than no test.

Prompt

"Log in, add an item to the cart, check out with the test card, and assert the order confirmation. Save it as a Playwright spec."

69. Drive a Real Browser to Verify Your UI Change

Point a coding agent at your running app over Playwright MCP and it navigates, fills the form, reads the resulting DOM, and tells you what it saw, closing the build-it/check-it loop without you alt-tabbing to the browser after every front-end edit. Because it works off structured accessibility snapshots, not pixels or vision, it's deterministic and far less prone to making something up than screenshot-clicking. It confirms the happy path; it won't catch the visual nuance you'd notice at a glance.

Prompt

"open localhost:3000, log in as the test user, add an item to the cart, and confirm the total updates"

70. Iterate on a Component With an IDE Agent Until It Matches the Target

The agent makes the multi-file UI edits, screenshots its own render, diffs it against the target, and refines, which replaces the save-reload-squint loop and "looks fine on my machine." The capability that makes this real is tool use, Playwright or Chrome DevTools MCP, not the model pretending it can see your screen; it actually observes the rendered page while the app hot-reloads. Spacing it can match; whether the result is good design is still on you.

Prompt

"load localhost:3000/settings, screenshot it, compare to the Figma export, and fix the spacing until it matches"

71. Inspect Live Console, Network, and Performance via Chrome DevTools MCP

This is the runtime-observation the agent never had. Chrome DevTools also has Gemini built in directly, an AI-assistance panel plus Console Insights that read the live page, and the Chrome DevTools MCP gives any agent the same eyes on the actual console errors with source maps, the failing XHR, and Lighthouse, so it debugs against what the browser really did instead of what the code looks like it should do. It's the official ChromeDevTools project exposing the console/network/performance/heap tools as callable functions. The root cause it names is a hypothesis backed by real telemetry, which is a much better starting point than a guess, but still a starting point.

Prompt

"reproduce the checkout bug on localhost, read the console errors and the failing XHR, and tell me the root cause"

72. Diagnose a Production Incident by Querying Your Telemetry Over MCP

During an incident you tab-hop between Loki, Prometheus, and Tempo hand-building queries. With the Grafana or Datadog MCP server the agent fetches the real logs, metrics, and traces and correlates across signals, so you stop grepping logs at 2am. Grafana, Datadog, and others now ship MCP servers that expose telemetry plus dashboards and alerts as tools, which is genuinely new. It points at the likely cause from live data; a correlation in the window isn't the cause, so confirm before you mitigate.

Prompt

"p99 latency on the checkout service spiked at 14:20 UTC. Pull the traces and error logs around that window and tell me the most likely cause."

73. Pull a Production Error and Fix It Over the Sentry MCP

Root-causing a prod error means tab-hopping between Sentry and your IDE to copy a stack trace. With the Sentry MCP server the agent grabs the issue, events, replay, and trace context directly, plus Seer's automated root-cause analysis, and proposes the fix in your editor. It stays one loop instead of a transcription chore. The fix it opens is a draft against a real trace, which you read and test like any other diff before it ships.

Prompt

"pull the top unresolved issue in project api, read the stack trace and Seer's analysis, and open a fix"

74. Manage Issues and PRs Through the GitHub MCP Server

Let the agent triage labeled issues, cross-reference them, open draft PRs, and check state through the real GitHub API, so issue grooming and PR housekeeping fold into the coding session instead of a context-switch to the web UI. GitHub deprecated the old npm server in 2025 and now ships an officially hosted remote one. Treat the token like the lethal-trifecta surface it is: scope it tightly, because the agent has write access to your repos.

Prompt

"find issues labeled bug opened this week, summarize them, and open a draft PR linking the one I assigned to myself"

75. File and Update Tickets in Your Tracker Without Leaving the Editor

You just hit a race condition and the bug report dies because writing it means switching to Linear or Jira. The official hosted MCP server lets the agent file it with the right project, priority, and labels from the conversation, tied to the work it just did, and close it on commit, so capturing follow-ups stops being the chore you skip. Glance at what it filed: the priority and labels are its guess at your conventions, not a contract.

Prompt

"create a High-priority bug in the Billing project describing the race I just found, and link the PR"

76. Drive Your Kubernetes Cluster in Plain English Over MCP

Diagnosing a bad pod is a fixed ritual: describe, get events, tail logs, check the manifest. Run K8sGPT or kubectl-ai as an MCP server and the agent runs the whole observe-reason-act loop against the live cluster, so you stop hand-typing the same five kubectl commands per incident. Scope it with a least-privilege ServiceAccount; an agent with a kubectl in its hands on prod is exactly where you want the blast radius small and the writes gated.

Prompt

"why is the checkout deployment in CrashLoopBackOff and how do I fix it?"

77. Operate Your Cloud and Infra-as-Code Through MCP

Give the agent authenticated, scoped access to the AWS MCP server or HashiCorp's Terraform server and it queries the live registry and your account metadata instead of half-remembering provider docs, so IaC scaffolding resolves against current real data. Both reached general availability by mid-2026 and are designed to expose registry and state metadata without leaking credentials or the state file. Keep it read-and-draft: let it find the resource and write the module, but the apply is yours.

Prompt

"find the right provider resource and version for an S3 bucket with versioning, and draft the module"

78. Generate Code From a Figma Frame via Dev Mode MCP

A flat screenshot makes the model guess pixels. The Figma Dev Mode MCP reads the actual file, the exact spacing, the variables, the auto-layout, the component names, so the output matches the design system. With get_design_context and Code Connect mapping a frame to its real import path and props, the agent generates against your component library, not invented markup. It's a real first pass against your tokens; you still wire up the behavior and trim what it over-generates.

Prompt

"generate a React component from my current Figma selection using our design tokens"

79. Exercise a Real API in Test Mode Over MCP

Building an integration used to mean hand-crafting curl calls and guessing payloads from the docs. Let the agent call the API with a scoped test key over its MCP server and it issues real test-mode calls, sees the actual object shapes and errors, and corrects, verifying the integration against the live sandbox instead of an assumption. Stripe's server scopes capabilities through a restricted key against test mode. Use the test key, never the live one, and the rest is the usual review.

Prompt

npx -y @stripe/mcp --api-key=$STRIPE_TEST_RESTRICTED_KEY

80. Profile Why It's Slow and Have AI Read the Flame Graph

Spotting the bottleneck means hunting for the widest box in a flame graph yourself. Hand the model the profile and it reads the call-tree shape, one fat function is a clear hotspot, many thin siblings is an N+1, and names the bottleneck in seconds. Grafana Cloud's Flame graph AI interprets the profile and proposes fixes, and modern profilers now emit markdown hotspot tables built for an LLM to read. It interprets structure, not magic; profile again after the fix to prove it moved.

Prompt

"where is the time going in this profile, and what's the highest-impact fix?"

81. Catch Secrets Before They Hit the Commit With AI-Aware Hooks

A pre-commit scanner blocks the API key, token, or password from ever landing in git history, including the base64/split/obfuscated ones a plain pattern misses. It's the cheap gate that actually saves you: 28 million credentials leaked on GitHub in 2025, and most stay live for years. The newer setups hook the scanner into the AI coding loop so the assistant's own output gets checked before it's saved. Deterministic regex-plus-entropy stays the fast first gate; the AI layer is for the obfuscation it can't see.

Prompt

"scan this diff for hardcoded secrets, including base64/split/obfuscated ones, and tell me what to rotate"

82. Give Your Coding Agent a Security Conscience via a Scanner MCP

Wire your existing SAST engine in as a tool over MCP and the agent runs the scan on the code it just wrote and fixes what's flagged before moving on, instead of the scan-in-CI-then-circle-back loop. This matters because AI-generated code carries meaningfully more security vulnerabilities than human-written, so the model checking its own output every turn is the point. It runs the 5,000-plus deterministic rules and reads the findings as a tool result, not a "is this code safe?" chat, and Cursor/Claude hooks can force the scan after every edit.

Prompt

"after each edit, run security_check on the code you just wrote and fix anything it flags before moving on"

Tier 6: Set It Loose

Give it a goal and an oracle, something that can say pass or fail, and step back. The agent plans, acts, checks its own work against the test suite or the green build or the rendered page, and loops until that oracle is satisfied. You stop driving each turn and start reviewing finished diffs.

83. Let the Debugger Read the Trace, Root-Cause It, and Open the Fix PR

Your error monitor's AI reads the production stack trace, the distributed traces around it, and your linked repo, then hands you a root cause and a draft fix while you're still reading the alert. That collapses the on-call grind of reproducing the error, bisecting which service actually failed, and hunting the line across repos before you've even diagnosed anything. Sentry's Seer/Autofix went GA in 2025, correlates the trace with logs and code, fires on a new issue without you asking, and can open PRs in several repos at once. A confident root cause is not a correct one, so the diff is still yours to read before it merges.

Prompt

"Connect Sentry Seer to my GitHub repos, then on a new issue run root-cause analysis and open a PR with the proposed fix for me to review."

84. Assign a Scoped Ticket to an Async Agent and Collect the PR Later

Hand a well-specified ticket to an autonomous agent from GitHub, Slack, Linear, or your editor; it branches, implements, runs the suite, and opens a PR tagging you, while you work on something else. The whole read-ticket, branch, scaffold, implement, test, push, open-PR loop folds down to two moves for the clearly-specifiable slice of a backlog: small bugs, mechanical changes, well-defined features. In 2025 this went off-machine and parallel. GitHub's Copilot coding agent runs each issue in its own Actions sandbox, and Codex cloud, Devin, and Google's Jules each take a ticket in an isolated VM; Cursor's Background Agents launch from Slack and let you run many at once, so the routine work that used to cost a context-switch every twenty minutes comes back as finished PRs you collect in batches. Launching from somewhere else doesn't move the one step you can't delegate: a clean PR that solves the wrong problem still wastes your afternoon, so you read the diff.

Prompt

"On GitHub assign the issue to @copilot, comment /codex, add the Devin label in Linear, or `@Cursor` from Slack: branch, implement, run the test suite, and open a PR tagging me for review."

85. Reproduce a Bug as a Failing Test, Then Loop Until It's Green

The agent writes a test that reproduces the bug, confirms it fails for the right reason, fixes the code, and stops only when that test passes. Compare that to the patch-it-and-hope fix where you change something, refresh, and assume you're done: a reproducing test up front gives the agent an objective stopping condition and you a regression guard for free. The agentic-repair pattern is reproduce-first, write the red test, then iterate fix-run-fix in a container until it goes green, so "fixed" means a passing test and not a model that feels finished. Simon Willison frames designing this loop and its exit condition as a core new skill, and the loop is only as good as the test you let it write. Read that test.

Prompt

"Reproduce this bug with a failing test first, confirm it fails for the right reason, then fix the code and run the test. Don't tell me it's fixed until the test is green."

86. Run the Test-Loop in a Sandbox So You Can Actually Walk Away

Point an agent at a failing feature and it edits, runs the suite, reads the failure, tweaks, and runs again until the tests pass. The dozens of round-trips you'd otherwise type by hand get handed off, and you check only the final diff. What makes "walk away" safe rather than reckless is where it runs: Codex was trained with RL to iterate on tests until they pass inside a network-disabled sandbox, and cloud agents self-test on a throwaway VM, so a wrong turn can't reach your shell, your credentials, or the network. The predictable cheat is the agent editing the assertions to turn red green, so forbid it and confirm the assertions are untouched.

Prompt

"In a sandbox, make the failing tests in tests/billing pass. Run the suite after each change and keep iterating until everything is green. Don't touch the test assertions."

87. Drive a Dependency Major-Version Upgrade End to End

Bumping a library across a major version is a multi-day slog: read the migration guide, run the codemods, then grind through the long tail of breakages they leave behind. Hand the whole thing over and the agent runs the codemod, fixes what the codemod can't, then builds, lints, and tests, iterating until everything's green. The shape that works is hybrid, deterministic codemods do the mechanical 80%, then a CLI agent owns the build-fix-rerun loop on the rest. The build is the oracle here, which is exactly the trap: a green build isn't proof of preserved behavior, so read this one carefully and ship it behind a flag.

Prompt

"Upgrade us from React 18 to 19. Run the official codemods, then fix the remaining type/build/test errors. Run build, lint, and tests; for each failure, fix and re-run until everything passes."

88. Scaffold a Whole New Project From a Spec

State your stack and the agent stands up the repo, the configs, lint and format, and a runnable skeleton, then runs the build to confirm it boots. Day zero on a new repo is its own slog, the create-* commands, hand-merging configs, untangling lint/format conflicts, wiring CI, all before a line of real code. Pair a reusable scaffolding skill with a precise CLAUDE.md that pins the stack and rules and the agent stands up a full project from a Claude Code scaffolding skill in minutes, build-verified. It's strongest on well-trodden stacks; aim it at a novel architecture and it confidently invents conventions, so review the skeleton before you build on it.

Prompt

"Scaffold a Next.js 15 app with TypeScript, Tailwind, App Router, src/ layout, ESLint and Prettier, and a passing CI workflow. Then run the dev server to confirm it boots."

89. Bisect a Regression to the Exact Commit That Broke It

Give a known-good and a known-bad commit; the agent writes the test wrapper, drives git bisect run, and hands back the first bad commit plus what it changed. No more checking out commit after commit and re-running the repro by hand: it does it in O(log n) steps and then explains the offending diff. Over the pass/fail exit-code automation git bisect run already gives you, what the agent adds is authoring the bisect script and reading the culprit against its change. Bisect's old catch is undimmed: the run is only correct if the test reliably reproduces the bug, so a flaky repro lands you on an innocent commit.

Prompt

"This test passed in v1.4 and fails on main. Set up git bisect with a script that runs the failing test, run it to completion, and tell me the first bad commit and what it changed."

90. Let an AI SRE Investigate the Alert Before You Open the Laptop

An alert fires and an agent investigates across metrics, traces, and logs, then hands you a ranked root-cause hypothesis before you've reached for the laptop. The first twenty minutes of any page is the same scramble, which service, which deploy, which dependency, pull the logs and traces, and an agent running that hypothesis-and-validate loop on alert means you read a conclusion instead of starting cold at 3am. This is real tier-6 autonomy: Datadog's Bits AI SRE runs a continuous observe-reason-act loop over telemetry and can hand off to a code-fix agent, and Grafana shipped Assistant Investigations as an autonomous incident agent, both acting before a human is in the loop. A correlation in the window isn't the cause, so the hypothesis is a lead, not a verdict, especially before you act on it.

Prompt

"Connect Datadog Bits AI SRE (or Grafana Assistant Investigations) to on-call so it auto-investigates the monitor alert and posts findings before I open the laptop."

91. Visual Self-Healing of a Flaky UI Test

A selector breaks. The agent screenshots the live page, sees what actually rendered, rewrites the locator, and reruns until the test goes green, instead of you hunting which DOM change broke it and hand-patching brittle locators every morning. It reads the real page state rather than guessing from the test code, which is the difference between repair and another guess. The current form is Playwright MCP plus a coding-agent loop doing this autonomously, the "AI Healer" pattern: see the rendered page, decide the next action, verify by rerunning. Self-healing a locator can paper over a real UI regression, so a passing repair still deserves a glance at what it changed.

Prompt

"On a failing E2E test, open the URL with Playwright MCP, screenshot the page, diff the failing selector against what's rendered, repair the locator, and rerun until green."

92. Bake a Security Pass Into Every Turn, Not Just CI

Tier 5 wired a SAST engine in so the agent could check its own output when you asked; this is that pass running on every diff automatically, the lightweight gate you stop having to remember. An always-on plugin reviews each change for vulnerabilities as you code and fixes them in the same session, which is why Anthropic's Claude Code security-guidance plugin cut security-related PR comments 30-40% in internal testing. It runs in three mostly-automatic stages: cheap pattern checks (eval, os.system, unsafe deserialization) with no model call, diff analysis after each turn for what patterns miss, then a false-positive-reducing validation pass on commit, none of it requiring a separate tool. It's a first gate, not a substitute for the real scanner in CI.

Prompt

"Install Claude Code's security-guidance plugin: run lightweight pattern checks on edits, analyze the git diff after each turn for what patterns miss, and validate findings on commit/push."

93. Raise Coverage With Build-Pass-Coverage-Filtered Tests

Generate batches of tests but keep only the ones that build, pass, and measurably add coverage, and "get this file to 80%" stops being a soul-draining manual generate-run-prune-repeat. The filter is the whole point: it protects you from the hallucinated test that passes while asserting nothing. This is Meta's TestGen-LLM "Assured LLMSE" pattern, which improved 11.5% of targeted classes with 73% of suggestions accepted by engineers, open-sourced as Qodo Cover. Mutation-guided feedback is the modern addition, making the surviving assertions actually catch faults, because a test that covers a line without checking its behavior is coverage theater. Read the survivors before they merge.

Prompt

"For this class, generate additional unit tests, then discard any that don't build, don't pass, or don't increase line/branch coverage. Show me only the survivors as a PR."

Tier 7: Higher Dimensions

At the top of the ladder you stop typing prompts and start maintaining machinery: bots that wake on a webhook, agents that run while you sleep, packaged skills your whole team loads without asking. The catch rides along with the power. Whatever runs unattended can also break unattended, with nobody reading the diff until you do.

94. Auto-Triage CI Failures and Tell Flaky From Genuinely Broken

A red build kicks off the same scavenger hunt every time: open the run, scroll the log, strip the ANSI and timestamp noise, ask whether the e2e suite is acting up again or you actually broke something. Wire a GitHub Actions failure webhook to an agent that does all of it, fetching the logs, enriching the error with the source snippet from the triggering commit, and checking run history so a step that fails 30% of the time gets labeled flaky instead of paging a human. Even plain log summarization saves the better part of an hour per red build, and mature AIOps self-healing reports MTTR cuts around 65%, from roughly four hours down to under one and a half. Genuine breaks still route to a person.

Prompt

"Wire a GitHub Actions failure webhook to an agent that fetches and de-noises the logs, checks run history (flag steps failing >30% recently as flaky), and opens an issue with the root cause and next steps."

95. Stand Up a CI Code-Review Bot That Comments on Every PR

Install a code-review app (CodeRabbit, Greptile, Copilot review) or wire claude-code-action on pull_request, make it a required status check, and hand it a repo config so it learns your conventions. It does the mechanical first pass on every PR: the forgotten null check, the leaked handle, the wrong error type, plus a security sweep, so your human reviewers spend their attention on architecture and judgment. The whole-repo versions build a knowledge graph of the codebase; Greptile's own benchmark caught 82% of seeded issues, the top score in that benchmark (a vendor figure, so weigh it accordingly). One caveat worth respecting: the security Action's README says it isn't hardened against prompt injection, so point it only at trusted PRs.

Prompt

"Install CodeRabbit/Greptile/GitHub Copilot code review as a GitHub App (or wire claude-code-action on pull_request) and make the review a required status check. Tune it with a repo config so it learns your conventions."

96. Stand Up an Automatic Issue-Triage and Labeling Bot

A persistent agent reads every new issue, categorizes and labels it, flags duplicates, and routes it to the right owner before anyone opens the tracker. Add a workflow on issues: opened, give it the repo's CODEOWNERS and your label taxonomy, and the inbound queue grooms itself: no more reading each report, picking labels, spotting dupes, and assigning by hand. This is a different bot from the code-review one above, which gates PRs on code; this one keeps the backlog navigable so the human triage hour goes to the judgment calls. Anthropic ships an issue-triage recipe in claude-code-action, and the GitHub Actions docs list it as a supported pattern. The priority and the owner it picks are its read of your conventions, so glance at the labels it applies.

Prompt

"Add a workflow on `issues: opened` that runs claude-code-action with a triage prompt to apply labels, flag duplicates, and tag the right owner from the repo's CODEOWNERS."

97. Run Several Agents in Parallel on One Repo via Git Worktrees

Add a worktree per task, launch one agent in each, and the feature build, the bug fix, and the doc pass run at the same time without stashing or stepping on each other. Each worktree is its own checkout, branch, database, and dev-server port, which is what makes concurrent edits safe instead of a merge nightmare. The tooling leans hard into it now: Claude Code has --worktree and a worktree isolation frontmatter, gwq and agentree give you a dashboard across them, and Cursor and Devin generalize the same idea to N agents on separate VMs from one surface. The conflicts the agents couldn't see each other make are yours to resolve on the integration branch.

Prompt

git worktree add ../repo-auth feature/auth && git worktree add ../repo-cache feature/cache

98. Bottle a Repeated Workflow as a Reusable Skill or Slash Command

Stop re-pasting the same paragraph of standards into every chat. Package it as a SKILL.md with a precise "use when" line and your house checklist, drop it in .claude/skills/, and type /review instead. The prompt becomes a versioned, shareable file the agent loads on its own when the task matches, or that a subagent runs in an isolated context. Anthropic open-sourced the Agent Skills spec, and Codex CLI, Gemini CLI, and Cursor have since adopted it, so one SKILL.md travels across agents rather than locking to a single vendor. The natural endgame is a skill that writes other skills.

Prompt

"Create a /review skill: a SKILL.md with a precise 'use when' plus my house checklist (run tests, check error handling, flag missing docs), so I type /review instead of pasting the checklist every time."

99. Wire Hooks So Your Agent Auto-Formats and Lints Every Edit

Ask the agent to format the file and watch it forget, then mop up in a cleanup commit. The fix is a PostToolUse hook in .claude/settings.json that runs prettier and eslint --fix on the file after every Edit or Write, so the formatter fires whether or not the model remembered. The distinction practitioners keep hammering on is the one that matters: a CLAUDE.md rule is a suggestion the model may ignore, a hook is enforced because the harness runs it, not the model. PreToolUse hooks do the inverse, blocking a bad command before it executes.

Prompt

"Add a PostToolUse hook in .claude/settings.json with an Edit|Write matcher that runs prettier and eslint --fix on the changed file after every edit."

100. Let Your Agent Keep a Self-Improving Memory of Your Project

Every conversation starts with you re-explaining "our deploy needs X, don't touch Y." Tell the agent to append a dated, specific entry to CLAUDE.md (or a learnings.md) whenever it finds a build quirk, a convention, or a mistake worth not repeating, then read it first and update it last every session. The project's tribal knowledge persists as a versioned file instead of evaporating when the context window closes. The working pattern is two layers: a CLAUDE.md you curate by hand plus auto-memory the agent writes from your corrections. The discipline is the whole game. Dated specific entries, a read-first-update-last contract, and a periodic prune, or the file bloats into noise the agent learns to ignore.

Prompt

"When you discover a build step, a convention, or a mistake worth not repeating, append a dated, specific entry to CLAUDE.md. Read it first at the start of every session; update it last."

101. Run a Standing Maintenance Agent for the Chores Nobody Remembers

The weekly dependency triage slips, the stale branches pile up, the lint warnings accrete, the TODOs go stale. Schedule a cron job that wakes an agent, runs one of those recurring sweeps, opens a PR if anything moved, and exits. The mechanisms are Claude Code's scheduled tasks and cloud Routines (cron, API, or GitHub-event triggers) and Cursor Automations, each firing in a fresh session that completes and shuts down, which fits a recurring job far better than a long-lived chat that drifts off-thread. The same shape covers a docs-sync pass: read the merged diff, find the pages it touched, open the PR. Start it on low-stakes maintenance and keep everything gated behind a PR, because an unattended agent has nobody reading its diff until you do.

Prompt

"Create a scheduled task: cron 0 7 * * 1 -> 'Sweep for stale branches merged over 30 days ago, draft a deletion list, and open a PR with a cleanup script. Touch nothing unmerged.'"

None of this is finished, and a fair amount of it breaks: the agent loses the thread on hour two, the migration comes back almost right, the bill arrives larger than the task deserved. The diff still gets read, the tests still get run, the merge is still on you. But the floor keeps rising, and the chat tab in the corner is the smallest thing on the menu now.