AI coding agents are most useful when they are treated as operators, not magicians.
The risky workflow is simple:
- Give the agent a broad task.
- Let it edit immediately.
- Inspect a large diff afterwards.
- Hope the tests cover the real failure mode.
That can work for toy projects. It is not reliable enough for production code, WordPress operations, API integrations, or anything with external side effects.
The safer workflow is to split the work into four phases.
1. Inspect Before Editing
Before the agent edits anything, make it map the repository.
Use a prompt like this:
Inspect this repository before editing.
Provide:
1. The runtime or framework.
2. The entrypoints.
3. The files most likely involved in [TASK].
4. The tests or checks that validate this task.
5. External services or credentials that could be affected.
Do not edit files yet.
This prevents the common failure where the agent solves the wrong problem in the wrong files.
2. Plan The Patch
After inspection, ask for a scoped implementation plan.
Create a minimal implementation plan for [TASK].
Constraints:
- keep edits scoped
- preserve existing conventions
- avoid unrelated refactors
- list exact files likely to change
- list verification commands
- identify any manual checks required
Do not implement yet.
The goal is not bureaucracy. The goal is to make the agent commit to a narrow path before it starts modifying code.
3. Patch The Smallest Useful Surface
Only after the plan is reasonable should the agent edit.
For small production changes, I usually want one of these outcomes:
- one bug fixed
- one page improved
- one script corrected
- one integration verified
- one test added around changed behavior
If the agent starts rewriting unrelated code, stop it and return to the plan.
4. Verify In The Real Runtime
A passing unit test is useful, but it is not always enough.
For production workflows, verification may need:
- tests
- build checks
- public HTTP checks
- browser DOM inspection
- tracking attribute checks
- logs
- screenshots or saved evidence
The agent should report what it verified, what it did not verify, and what residual risk remains.
Example: WordPress Operations Audit
For a WordPress operations page, do not start by asking the agent to rewrite the page.
Start with:
Audit this public WordPress operations page without changing content.
Check:
- links
- rel and target attributes
- CTA clarity
- tracking attributes
- mobile overflow
- public HTTP status
Provide the top 3 safe improvements and the evidence needed before publishing.
This keeps the agent away from public-facing edits until you know what the actual issue is.
Free Starter Kit
Disclosure: I made the free starter kit and the paid playbook linked below. They are my own Gumroad products.
I packaged the starter version of this workflow into a free Claude Code Automation Starter Kit:
It includes 5 prompts, a setup checklist, and one complete workflow example.
The full playbook expands this into 80 prompts and operating checklists:
Publishing Note
Recommended dev.to settings:
- Tags:
ai,claude,productivity,webdev - Canonical URL: leave blank unless a separate canonical page is published first
- Cover image: optional; do not delay publication for it
- First check after publishing: Gumroad Analytics/referrers after 24 hours and 48 hours
Top comments (0)