Skip to content
BSWEN
Blog

What's the Best Workflow for AI Coding Assistants?

Cowrie
Cowrie
Dev @ Bswen

I kept asking Claude to fix the same bug. It failed five times in a row. Each attempt looked plausible, but the test still failed. I was frustrated—why couldn’t the AI solve this simple problem?

The issue wasn’t the AI. It was my workflow.

The Reactive Loop Trap

Most developers use AI assistants reactively:

Me: Fix this error
AI: [provides fix]


Me: Still broken
AI: [provides similar fix]


Me: Same error
AI: [provides slightly different fix]


Me: Still failing
AI: [provides another similar fix]

This pattern is familiar because it mirrors how we debug normally—try something, see if it works, try again. But AI assistants don’t have the context we carry in our heads. They don’t know what “done” looks like unless we tell them.

Why Unstructured AI Interactions Fail

When I reactively ask AI to “fix this,” several things go wrong:

No clear intent. The AI doesn’t know what success looks like. Is it supposed to make the error disappear? Make the test pass? Optimize performance? Handle edge cases?

Bloated context. I paste entire files or long stack traces. The AI wastes tokens on irrelevant code and misses the actual problem.

No validation criteria. I ask the AI to check if it works, but it can’t run code. It guesses at correctness.

Session drift. Each failed attempt adds noise. After several iterations, the conversation contains contradictory suggestions, partial fixes, and confusion.

The Structured Workflow That Actually Works

After that frustrating five-failure session, I tried a different approach. Here’s the workflow that cut my AI debugging time by 70%.

Phase 1: Define Intent (Before Engaging AI)

Before typing anything to the AI, I write down:

  • What is the specific goal? Not “fix it” but “make test_filter_empty pass”
  • What are the constraints? Python 3.11, no external dependencies, must maintain backward compatibility
  • What does success look like? Test passes, existing tests still pass, no new warnings

This takes 2-3 minutes but saves 30 minutes of confused iterations.

Phase 2: Provide Focused Context

Instead of dumping files, I extract only what’s relevant:

filter.py
def filter_items(items, predicate):
    result = []
    for item in items:
        if predicate(item):
            result.append(item)
    return result if result else None  # Bug: returns None instead of []

Not the entire module. Not the import statements. Just the function with the issue.

Phase 3: Create Validation

I write a failing test before engaging AI:

test_filter.py
def test_filter_empty():
    result = filter_items([1, 2, 3], lambda x: x > 10)
    assert result == []  # Expected: empty list, Actual: None

This gives the AI a clear target. It can see exactly what’s wrong.

Phase 4: Engage with Structure

Now I compose a focused prompt:

prompt.txt
Here's a failing test. The filter_items function returns None when
all items are excluded by the predicate. It should return an empty
list [] instead.


Current behavior: filter_items([1,2,3], lambda x: x > 10) returns None
Expected behavior: filter_items([1,2,3], lambda x: x > 10) returns []


Make the test pass while keeping existing behavior for non-empty results.

This prompt has everything the AI needs: the problem, the expected behavior, and the constraints. No fluff, no ambiguity.

The Three-Failure Rule

Here’s the key insight that changed everything: when AI fails three times, stop.

I learned this from a Reddit discussion where a developer described their pattern:

“AI failed 3 times → I investigated manually → Wrote root cause analysis → Asked AI to write test → AI fixed the issue”

After three failures, something is wrong with how the problem is framed. The AI is stuck in the wrong frame. Continued attempts just compound the confusion.

Instead, I:

  1. Stop engaging the AI
  2. Investigate manually—run the code, add print statements, use a debugger
  3. Write a root cause analysis—what’s actually happening vs. what I expected
  4. Create a reproducible test case
  5. Start a fresh session with the refined problem

This pattern—human framing, AI execution—consistently outperforms pure persistence.

Why Framing Matters More Than Prompts

A key insight from the same Reddit thread:

“A lot of the time the model is not really stuck on code, it is stuck on having the wrong frame for the problem. Once you write down the actual failure mode and force a repro or test, it stops wandering and gets useful fast.”

AI models excel at execution. They’re good at translating clear intent into code. They’re terrible at investigation—they don’t have access to runtime behavior, they can’t run experiments, and they can’t see what’s actually happening.

When I provide a clear frame—a failing test, expected vs. actual behavior, minimal context—the AI stops guessing and starts solving.

Workflow Decision Tree

decision-tree.txt
Start
  |
  +-- Define Intent (What do I want?)
  |   +-- Write down goal, constraints, success criteria
  |
  +-- Prepare Context (What does AI need?)
  |   +-- Minimal code, relevant errors, environment info
  |
  +-- Create Validation (How do I verify?)
  |   +-- Test case, expected output, repro steps
  |
  +-- Engage AI
      |
      +-- Success? --> Done
      |
      +-- Failure? (count++)
          |
          +-- Count < 3? --> Refine prompt, try again
          |
          +-- Count >= 3? --> STOP
              |
              +-- Investigate manually
              +-- Write root cause analysis
              +-- Create failing test
              +-- Start fresh with refined problem

Common Mistakes I Made

Vague requests. “Fix this” without defining “this.”

Fix: “Make this test pass” or “Implement function X that returns Y”

Context dumping. Pasting entire files or long logs.

Fix: Extract only relevant code, summarize errors in one line

No validation loop. Asking AI to “check if it works.”

Fix: Provide test case or expected output

Persistent looping. Trying same approach 5+ times.

Fix: Stop after 3 failures, investigate manually, reframe

Carrying baggage. Copying failed attempts to new session.

Fix: Synthesize learnings, start with clean problem statement

The Real Productivity Gain

Structured workflows prevent what I call “session drift.” Without structure, long AI conversations accumulate:

  • Contradictory instructions
  • Failed attempts that confuse the model
  • Irrelevant tangents

A 5-minute framing session saves 30 minutes of debugging loops. More importantly, it produces better code—because the AI understood what I actually wanted.

When This Workflow Doesn’t Apply

This structured approach works best for focused, well-defined problems. For exploratory work—brainstorming architectures, discussing tradeoffs, learning new concepts—a more conversational approach is fine. The key is matching the workflow to the task.

But for debugging, feature implementation, and refactoring? Structure beats reactivity every time.

The Takeaway

The best AI coding assistant workflow isn’t about finding the perfect prompt. It’s about structuring the problem before engaging AI.

Define intent. Curate context. Create validation. Iterate with discipline.

And when AI fails three times: stop, investigate, frame, restart.

A well-framed problem solved once beats a poorly-framed problem solved ten times.

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

Tags: