Bringing an AI Agent Into Your Actual Dev Workflow

Most posts about AI agents stop at "install it and give it a task." That's the easy 10%. The part that actually determines whether an agent helps or slows you down is how you fit it into a real project — one with existing conventions, a git history, teammates, and code you can't just let get rewritten on a whim.

Here's what that looks like in practice, on a project I actually work in.

Start with context, not tasks

The single biggest lever is giving the agent something to orient against before it touches anything. In this repo, for example, there's an AGENTS.md/CLAUDE.md at the root that tells the agent this isn't a stock framework setup and points it at the right docs before writing code. That one file saves dozens of wasted edits from an agent confidently applying patterns from its training data that don't match this codebase.

If your project doesn't have something like that, write one. Even a few lines — "we use X instead of Y," "don't touch the migrations folder without asking," "tests live next to the file they cover" — pays for itself the first time an agent would've guessed wrong.

Use it for the boring middle, not just the ends

The failure mode I see most often is people using agents only for greenfield generation ("build me a login form") or only for one-line fixes. The bigger win is the boring middle of real work:

• Tracing a bug through three files you didn't write
• Updating every call site after a function signature changes
• Writing the test that covers the edge case you keep forgetting
• Summarizing a diff before you open a PR

None of these are exciting, and that's exactly why they're a good fit — low creative risk, high tedium, easy to verify.

Keep a tight loop: plan, diff, verify

The workflow that's actually stuck for me:

1. Ask for a plan first on anything non-trivial, before letting it edit. A plan is cheap to reject; a half-finished refactor across ten files is not.
2. Read the diff, not the summary. The agent's own description of what it did is a claim, not a fact. Actually look at what changed.
3. Run the tests or the app. Type-checking proves the code compiles, not that the feature works. If it's UI, actually click through it.
4. Commit in small chunks. Small commits make it trivial to git revert the one change that turned out wrong, instead of untangling it from five others.

Scope what it's allowed to touch

Give an agent broad file access and broad shell access, and eventually it'll do something broad you didn't want — a stray rm, a force-push, a "helpful" cleanup of code you hadn't asked it to clean up. The fix isn't distrust, it's scoping:

• Let it read freely; be deliberate about what it can write or execute.
• Treat destructive or hard-to-reverse actions (force-push, dropping a migration, deleting a branch) as things it should always confirm with you, not infer permission for.
• If it's touching CI, secrets, or shared infrastructure, that's a different trust tier than editing a component file — treat it that way explicitly.

Where it actually pays off

After using this pattern for a while, the clearest wins have been:

• Onboarding to unfamiliar code. Pointing an agent at a directory and asking "how does this work" is faster than archaeology through git blame.
• Consistency enforcement. Agents are good at applying a convention uniformly across a codebase once you've shown them one example — better than a human doing it by hand across 40 files.
• PR prep. Having it draft the PR description from the actual diff, then editing that draft, beats writing one from scratch after you've mentally moved on to the next task.

The agent isn't a replacement for engineering judgment — it's a very fast, very literal collaborator that does exactly what you tell it and nothing you didn't. The work is in getting good at telling it the right things.