Skip to content

What's the Best Workflow for AI Coding Assistants? A Practical Guide

The Problem

My AI coding workflow was broken. I’d give Claude or Cursor a vague request, get some code back, review it, find problems, fix them, and repeat. The cycle looked like this:

My broken workflow
Vague Request → AI Generates Code → Review → Fix Issues → Repeat

I was spending more time fixing AI-generated code than writing it myself. The code worked, but I didn’t fully understand it. And the style drifted from my team’s conventions.

Then I found a Reddit thread where experienced developers shared their AI workflows. One comment stopped me:

“The worst slop comes from the worst plans.”

That was it. I was spending my time fixing problems instead of preventing them.

What I Was Doing Wrong

My old workflow treated AI as a magic code writer. I’d say something like:

Bad prompt
Implement a cache for API responses

The AI would generate generic code that worked, but didn’t match my project’s patterns. I’d spend 30 minutes refactoring it to:

  • Use my existing Redis client
  • Match our error logging pattern
  • Handle edge cases we care about
  • Follow our naming conventions

I was reactive. AI produced code, I fixed it. The problem? I was fixing preventable issues.

The Better Approach: Proactive Parallel Work

The Reddit thread revealed a different approach. Instead of fixing AI code, prevent bad code from happening. The workflow looks like this:

Better workflow
Detailed Plan/Spec (Human) || AI Generation (Parallel) → Review + Refactor → Test

The key is parallel work. While AI generates code, I don’t wait idle. I:

  • Plan the next feature
  • Write specs for upcoming work
  • Review existing code for integration points

This approach has three phases.

Phase 1: Invest in Specs

Before any AI generation, I write a detailed spec. The same “cache for API responses” feature now looks like this:

Detailed spec
Write a function `cacheApiResponse` that:
1. Accepts: key (string), fetcher (async function), ttlMs (number)
2. Behavior:
- Check Redis cache with key
- If cached and not expired, return cached value
- If not cached or expired, call fetcher()
- Store result in Redis with TTL
- Return result
3. Error handling:
- Cache miss: call fetcher, don't throw
- Cache error: log and fallback to fetcher
- Fetcher error: propagate up
4. Use our existing RedisClient from src/cache/redis.ts
5. Follow our error logging pattern: logger.error with context
6. Return type: Promise<T>
Do NOT:
- Add retry logic (handled by caller)
- Add request deduplication (separate concern)
- Cache errors/exceptions (only cache successful responses)

This takes 5 minutes to write. But it saves 30+ minutes of fixing later.

Phase 2: Parallel Work

When I give the spec to AI, I don’t sit and wait. I start planning the next feature. This parallel approach means:

  • AI generates code while I plan
  • When AI finishes, I switch to review mode
  • I’m productive the entire time

One developer put it well:

“I just refactor everything myself, sending him to work on something else meanwhile. That helps to actually understand WTF is going on in codebase.”

Phase 3: Review for Understanding

After AI generates code, I review it. But not just for correctness - for understanding. The review checklist I use:

Review checklist
Understanding (Most Important):
[ ] I understand every line of this code
[ ] I can explain the logic to a teammate
[ ] I can debug this if it breaks
Quality:
[ ] Follows team style conventions
[ ] No unnecessary complexity
[ ] Error handling matches requirements
[ ] Edge cases from spec are handled
Integration:
[ ] Uses existing utilities (no duplication)
[ ] Matches patterns in codebase
[ ] No security issues introduced

If I can’t explain the code to a teammate, I refactor until I can.

Time Allocation: The Shift

The biggest mindset shift was where I spend my time. Traditional development vs AI-assisted:

Time allocation comparison
| Activity | Traditional | AI-Assisted |
|-------------------|-------------|-------------|
| Planning/Specs | 10% | 30% |
| Code Generation | 80% | 10% |
| Review/Refactor | 10% | 40% |
| Debugging | Variable | Minimal |

I spend less time writing code, more time thinking about code. This sounds inefficient, but it’s not. A 5-minute spec prevents 30 minutes of fixing.

Common Mistakes I Made

Mistake 1: Accepting code without review

When I first started, I’d accept AI suggestions quickly. The code worked, so why not? The result: code I didn’t understand, technical debt accumulating, debugging nightmares later.

Mistake 2: Vague prompts

Compare these:

# Vague (causes problems)
Implement authentication
# Specific (prevents problems)
Implement JWT authentication with refresh tokens using our existing AuthService class. Include rate limiting of 10 requests per minute per user. Store refresh tokens in Redis with 7-day expiration. Follow our error logging pattern.

Vague prompts produce generic solutions. Specific prompts produce code that fits your project.

Mistake 3: Waiting idle for AI

AI generation takes time. I used to wait, checking my phone, wasting time. Now I use that time productively - planning the next feature, writing specs.

Mistake 4: Skipping the spec phase

“I’ll just fix it after” - this is the trap. Time spent fixing > time spent specifying. Always.

Tool-Specific Tips

Claude Code

  1. Create a CLAUDE.md with project rules and conventions
  2. Write detailed specs as task descriptions
  3. Let Claude work while you plan next phase
  4. Review generated code with diff view
  5. Run tests immediately after generation

Cursor IDE

  1. Use chat for complex multi-file changes
  2. Review diffs before accepting
  3. Use multi-file context for refactoring
  4. Iterate with follow-up prompts
  5. Keep human in the loop for style decisions

GitHub Copilot

  1. Use comment-driven development (write intent as comment)
  2. Accept suggestions selectively
  3. Maintain active editing to guide suggestions
  4. Review each accepted suggestion
  5. Never accept blindly - always understand

The Prevention Mindset

The key principle I learned: prevent bad code instead of fixing it later.

Prevention checklist
Before AI generation:
1. Write specs before prompts (prevents misunderstandings)
2. Define patterns before generation (prevents style drift)
3. List edge cases before implementation (prevents bugs)
4. Specify what NOT to do (prevents over-engineering)
5. Review for understanding, not just correctness (prevents confusion)

As one developer said:

“Being proactive in this manner is much better than trying to fix things once bad code is in place. Prevent bad code, and your future self will thank you.”

The 80/20 Principle

AI gets you 80% of the way. The human 20%:

  • Understanding domain-specific requirements
  • Enforcing team conventions
  • Handling edge cases
  • Ensuring maintainability
  • Code review for understanding

The workflow that works isn’t about maximizing AI usage. It’s about strategic human-AI collaboration.

Summary

The best workflow for AI coding assistants has three key principles:

  1. Plan more, fix less: Invest time in detailed specifications upfront
  2. Work in parallel: Don’t wait idle while AI generates
  3. Review for understanding: Not just correctness

The developers who get the most from AI assistants don’t treat them as magic code generators. They treat them as junior developers who need clear instructions, constant supervision, and careful review.

The time saved isn’t in writing less code - it’s in thinking more strategically about what code needs to be written.

The workflow formula
Detailed planning + Parallel AI generation + Thorough review
= Maintainable, understood, quality code

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments