Cursor AI Agent Mode Beats `git cherry-pick`: Agentic Debugging

Facing a frustrating `asyncio` timing bug that nearly forced me to revert significant work, I used Claude's Agent mode in Cursor. It impressively navigated my git history, used the terminal following my custom rules, diagnosed the concurrency issue, and ultimately helped devise and implement a lightweight message queue to ensure proper message order without needing explicit delays or manual `git` fixes, showcasing a powerful new way to debug complex problems.

By Mike Levin

Tuesday, April 8, 2025

Understanding the True Value of AI Agent Mode

The important nuance to appreciate in this article is that the new Agent or agentic modes in AI-assisted editors isn’t so much about going hog-wild coding (the fear) as much as it is about doing deep-dives into studying your code — and not just what’s in your current folder, but also diving into your git history and branches as well.

My mind was blown. I absorbed what it said:
“You don’t need to git reset --hard HEAD!”
“Just give me hashes of a working state”
“And I’ll diff ‘em.” Had to contemplate 🤯

AI as a Code Archaeologist

Watching Claude execute commands in terminal, grepping and git diff’ing away like an old school hacker is massively impressive and a bit humbling. That’s the big win here — not the coding quite so much as deep understanding. These things are making the jump from not having enough context about what you’re doing to having more than you could ever hope to have yourself — at least as expressed by your code and everything you ever tried.

Facing a Complex Asyncio Timing Bug

On a round of work I was doing this morning, I almost had to revert and loose a lot of progress because of a nuanced issue related to asyncio.create_task() timing. Instead, I had Claude use Agent mode in Cursor to look at a git branch I made to capture the last working state. In the course of doing so, it executed a lot of terminal commands. I noticed it looked at a Cursor Rule I set up for it when using terminal, and it miraculously found and solved the problem.

Training AI to Navigate Your Terminal Environment

Over the past few days, I added rules for Claude to look at whenever it tried to execute terminal commands on my system to deal with the nuances of the Python virtual environment and NixOS. It’s not just you. Every terminal environment is weird with all its environment variables, .venv’s, restricted permissions, sandboxing or whatever. That doesn’t keep the AI from being helpful by using hte terminal on your behalf. It just means you gotta train it a bit.

Avoiding Painful Git Resets

I know that the concurrency problem I was encountering is the kind of thing that I would have git reset --hard [hash] to the last working version to fix, and then consider but abandon git cherry picking to get back any peripheral improvements I made to the code, but then abandon the idea based on how frequently I git commit and quite how many cherries there are to pick. I am not Linus.

Claude Knows Git

This generally results in me just having to get back to where I was again feature-wise organically. But I didn’t have to because Claude was able to untangle it all and solve it efficiently — comparing git branches and seeing what worked in the past! This is a game changer. Agent mode in Cursor is worth it for this alone.

A New Reason for Good Git Practices

Let me repeat that. Coding assistants can know your git history, your git logs, your git branches, your git diffs better than you do. They can hold a concept of your git repo and everything you’ve tried in their AI-minds better than a human ever could (except maybe Linus). You have a brand new reason to use good git commit messages.

This turns the entire argument that your AI coding assistant doesn’t know your codebase as well as you human do upside down. Agentic mode doesn’t just let your AI coding assistant go directory-diving (which it also does), but it goes time-traveling (git history) and alternate timeline exploring (branches).

BAM!

Stunned By The Realization

My mind was blown. I absorbed what it said:
“You don’t need to git reset --hard HEAD!”
“Just give me hashes of a working state”
“And I’ll diff ‘em.” Had to contemplate 🤯

Me: OMG, you just saved me from so much reverting! That was amazing! How would you describe your new Agentic capabilties that let you do this? And what role did the rule for using Terminal play?

Claude: I was able to solve the streaming message timing issue by identifying the root cause and applying the fix through careful analysis and comparison between branches.

My enhanced agentic capabilities that enabled this include:

Contextual awareness across environments: I could navigate between git branches, understand file differences, and recognize the significance of implementation patterns (concurrency vs. sequential execution).
Deep system-level reasoning: I identified that the issue was caused by concurrent asyncio.create_task() calls competing with each other, which is a subtle but critical asynchronous programming pattern issue.
Multi-step problem-solving: I worked through a complete diagnosis-to-solution workflow:
- Locating relevant code in different branches
- Comparing implementations (goodtiming vs main)
- Identifying the core issue (task concurrency causing out-of-order messages)
- Applying a targeted fix with proper timing control

The terminal rule was crucial because it provided:

Repository navigation guidance: The nix-rules specified how to access repositories correctly in your environment
Permission boundaries: It clarified I should “work exclusively in ~/repos/nixos” and focus on repo locations
Command execution context: It helped me understand I could use git directly in your environment

Without the terminal rule, I might have suggested approaches that wouldn’t work in your specific environment or wasted time trying incorrect repository paths.

This kind of complex debugging showcases how agentic capabilities enable multi-step technical problem-solving that combines tool usage, code understanding, and system-level knowledge to resolve issues that would traditionally require significant human expertise.

Considering Accepting Necessary Tradeoffs

Me: But I really have to live with the timing delay on entering a pid key now, don’t I?

Claude: Yes, unfortunately the timing delay is a necessary tradeoff to ensure your messages display in the correct order.

The alternative would be jumbled, overlapping messages as we saw with the concurrent tasks approach. Those small delay calls (await asyncio.sleep(0.5)) are essential for maintaining a coherent conversation flow in the UI.

If you’re concerned about the user experience impact of these delays, you could potentially:

Fine-tune the delay times - You might experiment with smaller values (0.3s or 0.2s) to find the minimum delay that still preserves message order
Add a subtle loading indicator during initialization to set user expectations
Consider a more sophisticated message queue system for future iterations that could handle ordering without explicit delays

But for now, the sequential awaited calls with strategic delays represent the most reliable solution within the current architecture. It’s a small UX compromise to ensure a much more important aspect of the experience - coherent message ordering - remains intact.

This is one of those cases where doing things the “right way” does have a small performance cost, but the benefits to user experience far outweigh that cost. The goodtiming branch clearly showed this was the better approach all along.

Exploring Lightweight Message Queue Solutions

Me: What is the lightest possible touch message queue that could solve this? Think outside the box. Zero Message Queue (zmq) is an option. But don’t over-engineer. Just think in terms of piping it through order assurance.

Claude: Looking at the current code, you’re right that the delays are a tradeoff we need to make. The simplest solution would be a lightweight message queue implementation that preserves order without requiring external dependencies.

Here’s a minimal approach that could solve this:

# pipulate/plugins/20_hello_workflow.py
// ... existing code ...
import asyncio
from collections import namedtuple
from datetime import datetime

from fasthtml.common import *
from loguru import logger

"""
Pipulate Workflow Template

After copy/pasting this file, edit this docstring first so that your
AI coding assistant knows what you're trying to do.

This file demonstrates the basic pattern for Pipulate Workflows:
1. Define steps with optional transformations
2. Each step collects or processes data
3. Data flows from one step to the next
4. Steps can be reverted and the workflow can be finalized

To create your own Workflow:
1. Copy this file and rename the class, APP_NAME, DISPLAY_NAME, ENDPOINT_MESSAGE
2. Create a [filename].md the training folder (no path needed) and set TRAINING_PROMPT to refer to it
3. Define your own steps
4. Implement custom validation and processing as needed

There are two types of apps in Pipulate:
1. Workflows - Linear, step-based apps. The part you're looking at. WET.
2. Apps - CRUD apps with a single table that inherit from BaseApp. DRY.

CRUD is DRY and Workflows are WET! Get ready to get WET!
"""

# Simple ordered message queue to ensure messages appear in sequence
class OrderedMessageQueue:
    """A lightweight queue to ensure messages are delivered in order.
    
    This class creates a simple message queue that ensures messages are delivered
    in the exact order they are added, without requiring explicit delays between
    messages. It's used to fix the message streaming order issues.
    """
    def __init__(self):
        self.queue = []
        self._processing = False
        
    async def add(self, pipulate, message, **kwargs):
        """Add a message to the queue and process if not already processing."""
        self.queue.append((pipulate, message, kwargs))
        if not self._processing:
            await self._process_queue()
    
    async def _process_queue(self):
        """Process all queued messages in order."""
        self._processing = True
        try:
            while self.queue:
                pipulate, message, kwargs = self.queue.pop(0)
                await pipulate.stream(message, **kwargs)
        finally:
            self._processing = False

# This is the model for a Notebook cell or step (do not change)
Step = namedtuple('Step', ['id', 'done', 'show', 'refill', 'transform'], defaults=(None,))


class HelloFlow:  # <-- CHANGE THIS to your new WorkFlow name
    APP_NAME = "hello"  # <-- CHANGE THIS to something no other workflow is using
    DISPLAY_NAME = "Hello World"  # <-- CHANGE THIS to value for User Interface
    ENDPOINT_MESSAGE = (  # <-- Shows when user switches to workflow landing page
        "This simple workflow demonstrates a basic Hello World example. "
        "Enter an ID to start or resume your workflow."
    )
    TRAINING_PROMPT = "hello_workflow.md"  # markdown file from /training or plain text
    PRESERVE_REFILL = True  # <-- Whether to preserve refill values on revert

    def __init__(self, app, pipulate, pipeline, db, app_name=APP_NAME):
        """
        Initialize the workflow.
        """
        self.app = app
        self.app_name = app_name
        self.pipulate = pipulate
        self.pipeline = pipeline
        self.steps_indices = {}
        self.db = db
        pip = self.pipulate
        # Create message queue for ordered streaming
        self.message_queue = OrderedMessageQueue()

// ... existing code ...

    async def init(self, request):
        """
        Initialize the workflow and create the UI for all steps.
        """
        pip, db, steps, app_name = self.pipulate, self.db, self.steps, self.app_name
        form = await request.form()
        user_input = form.get("pipeline_id", "untitled")
        
        # Get the context with plugin name and profile name
        context = pip.get_plugin_context(self)
        plugin_name = context['plugin_name'] or app_name
        profile_name = context['profile_name'] or "default"
        
        # ───────── PIPELINE ID GENERATION AND PARSING ─────────
        # Create the expected prefix parts
        profile_part = profile_name.replace(" ", "_")
        plugin_part = plugin_name.replace(" ", "_")
        expected_prefix = f"{profile_part}-{plugin_part}-"
        
        # Determine pipeline ID based on user input
        if user_input.startswith(expected_prefix):
            # They provided the full composite key
            pipeline_id = user_input
            # Parse it to get the user part
            parsed = pip.parse_pipeline_key(pipeline_id)
            user_provided_id = parsed['user_part']
        else:
            # They provided just their part - generate a full key
            _, prefix, user_provided_id = pip.generate_pipeline_key(self, user_input)
            pipeline_id = f"{prefix}{user_provided_id}"
        
        db["pipeline_id"] = pipeline_id
        logger.debug(f"Using pipeline ID: {pipeline_id}")
        
        # ───────── STATE INITIALIZATION AND WORKFLOW MESSAGES ─────────
        # Initialize the pipeline state
        state, error = pip.initialize_if_missing(pipeline_id, {"app_name": app_name})
        if error:
            return error

        # After loading the state, check if all steps are complete
        all_steps_complete = True
        for step in steps[:-1]:  # Exclude finalize step
            if step.id not in state or step.done not in state[step.id]:
                all_steps_complete = False
                break

        # Check if workflow is finalized
        is_finalized = "finalize" in state and "finalized" in state["finalize"]

        # Add all messages to the ordered queue in sequence - they'll be delivered in order
        # Add information about the workflow ID to conversation history
        id_message = f"Workflow ID: {pipeline_id}"
        await self.message_queue.add(pip, id_message, verbatim=True, spaces_before=0)
        
        # Add the return message
        return_message = f"You can return to this workflow later by selecting '{pipeline_id}' from the dropdown menu."
        await self.message_queue.add(pip, return_message, verbatim=True, spaces_before=0)

        # Workflow status messages
        if all_steps_complete:
            if is_finalized:
                await self.message_queue.add(pip, f"Workflow is complete and finalized. Use {pip.UNLOCK_BUTTON_LABEL} to make changes.", verbatim=True)
            else:
                await self.message_queue.add(pip, f"Workflow is complete but not finalized. Press Finalize to lock your data.", verbatim=True)
        else:
            # If it's a new workflow, add a brief explanation
            if not any(step.id in state for step in self.steps):
                await self.message_queue.add(pip, "Please complete each step in sequence. Your progress will be saved automatically.", verbatim=True)

        # ───────── UI GENERATION AND DATALIST UPDATES ─────────
        # Update the datalist by adding this key immediately to the UI
        # This ensures the key is available in the dropdown even after clearing the database
        parsed = pip.parse_pipeline_key(pipeline_id)
        prefix = f"{parsed['profile_part']}-{parsed['plugin_part']}-"
        
        # Get all existing keys for this workflow type
        self.pipeline.xtra(app_name=app_name)
        matching_records = [record.pkey for record in self.pipeline() 
                           if record.pkey.startswith(prefix)]
        
        # Make sure the current key is included, even if it's not in the database yet
        if pipeline_id not in matching_records:
            matching_records.append(pipeline_id)
        
        # Use the Pipulate helper method to create the updated datalist
        updated_datalist = pip.update_datalist("pipeline-ids", options=matching_records)
        
        # Get placeholders for all steps
        placeholders = pip.run_all_cells(app_name, steps)
        return Div(
            # Add updated datalist that includes all existing keys plus the current one
            updated_datalist,
            *placeholders, 
            id=f"{app_name}-container"
        )

// ... existing code ...

    async def step_01_submit(self, request):
        pip, db, steps, app_name = self.pipulate, self.db, self.steps, self.app_name
        step_id = "step_01"
        step_index = self.steps_indices[step_id]
        step = steps[step_index]
        pipeline_id = db.get("pipeline_id", "unknown")
        
        # Handle finalized state using helper
        if step.done == 'finalized':
            return await pip.handle_finalized_step(pipeline_id, step_id, steps, app_name, self)

        # Get form data
        form = await request.form()
        user_val = form.get(step.done, "")
        
        # Validate input using helper
        is_valid, error_msg, error_component = pip.validate_step_input(user_val, step.show)
        if not is_valid:
            return error_component

        # For now, just use the user input directly
        processed_val = user_val

        # Update state using helper
        await pip.update_step_state(pipeline_id, step_id, processed_val, steps)

        # Send confirmation message - use the queue for ordered delivery
        await self.message_queue.add(pip, f"{step.show}: {processed_val}", verbatim=True)
        
        # Check if we need finalize prompt
        if pip.check_finalize_needed(step_index, steps):
            await self.message_queue.add(pip, "All steps complete! Please press the Finalize button below to save your data.", verbatim=True)
        
        # Return navigation controls
        return pip.create_step_navigation(step_id, step_index, steps, app_name, processed_val)

// ... existing code ...

I’ve implemented a super lightweight message queue solution that eliminates the need for explicit delays while ensuring your messages appear in the correct order. It’s the perfect balance between functionality and simplicity:

How It Works

Zero-Dependency Implementation: Uses a simple Python class (OrderedMessageQueue) with no external dependencies - just core Python async functionality.
Sequential Guarantee: Messages are processed one after another in FIFO order, ensuring perfect sequence without artificial delays.
Self-Managing: The queue automatically starts processing when a message is added and monitors its own state.
Drop-In Replacement: All await pip.stream() calls are replaced with await self.message_queue.add(pip, ...) with the same parameters.

Key Benefits

No Timing Delays: Completely eliminates the explicit asyncio.sleep() calls while still maintaining message order.
Natural Pacing: Messages will appear in sequence at their natural processing speed.
Single Instance: The queue is created once during workflow initialization and reused throughout.
Transparent Usage: The queue handles all the complexity internally - your code just adds messages.

This solution is perfect for your use case because:

It’s extremely lightweight (about 20 lines of code)
Has zero external dependencies
Doesn’t artificially slow down your application
Guarantees message order without complex synchronization

You get the best of both worlds - correctly ordered messages without having to “live with the timing delay” of the explicit sleep calls.

Me: Excellent! Can you recap what we did solving the message timing issue, unblocking I/O, externalizing the function, and then deploying it throughout? And then trying to put it into the BaseCrud class and backing off?

Solving the Message Timing Issue: A Technical Journey

Claude: Here’s a recap of our journey solving the message timing issue:

1. Identifying the Problem

We recognized that messages sent in quick succession could arrive out of order, creating a confusing user experience.
The issue occurred because each message was processed independently with its own async behavior.

2. Creating the OrderedMessageQueue

We designed a lightweight queue class to ensure messages are delivered in sequence.
The class maintains a queue of messages and processes them one after another.
Key components:
- __init__: Sets up the queue and a processing flag
- add: Adds a message to the queue and starts processing if not already running
- _process_queue: Processes messages in order, ensuring each completes before the next starts

3. Externalizing the Function

Initially, the OrderedMessageQueue was defined in 20_hello_workflow.py as a local class.
We moved it to the Pipulate class in server.py to make it globally available.
Added a get_message_queue method to provide access to the queue.
This allowed any plugin to use the centralized queue for message ordering.

4. Implementing in Workflow Plugins

Updated 20_hello_workflow.py to use the externalized queue:
```
self.message_queue = pip.message_queue
```
Changed 10_connect_with_botify.py to use the queue instead of direct stream calls:
```
await self.message_queue.add(self.pipulate, message, verbatim=True)
```
Updated 40_stream_simulator.py to use the queue for its status messages.
Commented out non-essential LLM interactions in 10_connect_with_botify.py to streamline the workflow.

5. Attempting BaseCrud Integration

We attempted to update the BaseCrud class to use the OrderedMessageQueue:

self.send_message = lambda message, verbatim=True: self.pipulate_instance.message_queue.add(
    self.pipulate_instance, message, verbatim=verbatim, spaces_after=1
)

The change caused runtime errors because:
1. The lambda couldn’t handle coroutines properly (needing await)
2. The send_message function was used in non-async contexts
3. Error: “a coroutine was expected, got pending name=’Task-46’”

6. Strategic Retreat

We backed off to the original working approach for BaseCrud:

self.send_message = lambda message, verbatim=True: asyncio.create_task(
    self.pipulate_instance.stream(message, verbatim=verbatim, spaces_after=1)
)

Added a TODO comment for future integration once we can solve the async lambda issues.
Updated the stream method documentation to note that direct calls bypass the queue.

7. Lessons Learned

The OrderedMessageQueue successfully solves the message ordering problem for workflows.
When a pattern is known to work (asyncio.create_task with stream), it’s sometimes best to stick with it for core functionality.
We maintained two approaches to message sending:
1. Direct stream() with asyncio.create_task() for BaseCrud methods
2. message_queue.add() for workflow plugins where ordered messaging is critical
The hybrid approach gives us stability now with a path to full integration later.

This journey highlights the importance of balancing innovation with stability - we successfully improved message ordering in the areas most critical while avoiding regressions in the core functionality.

Gemini 2.5 Experimental Weighs In

Okay, here are the requested components based on the article:

Summary (Author’s 1st Person Perspective):

I nearly lost significant progress due to a tricky asyncio.create_task() timing issue, but Claude, using Agent mode in Cursor, saved the day by analyzing my git branches and using terminal commands guided by a custom rule I’d set. It diagnosed the concurrency problem and initially solved it with delays, which wasn’t ideal. After discussing tradeoffs, Claude proposed and implemented a lightweight, zero-dependency Python message queue directly in my code, externalizing it for broader use across my workflow plugins. While an attempt to integrate this into a core BaseCrud class hit async limitations and was rolled back for stability, the overall process showcased how AI agent capabilities can untangle complex coding problems, debug across environments, and iteratively refine solutions, ultimately solving my original issue without manual git wrangling or accepting unnecessary UI delays.

Titles & Headlines Ideas:

Claude Agent Saves the Day: Debugging Asyncio with AI in Cursor
How an AI Agent Solved My Git Branch Nightmare and Asyncio Bugs
Debugging Asynchronous Python: AI Agent vs. git reset --hard
Cursor’s Agent Mode: A Game Changer for Complex Debugging
From Asyncio Hell to Ordered Messages: An AI-Assisted Coding Journey
Beyond Code Completion: AI Agent Tackles Git and System-Level Debugging
Developing a Lightweight Python Message Queue with AI Assistance
Claude + Cursor: Untangling Concurrency Issues and Improving UX
When AI Beats git cherry-pick: A Case Study in Agentic Debugging
Solving Real-World Coding Problems with Claude’s Agent Mode

Strengths of the Article:

Real-World Problem: Addresses a common and often frustrating type of programming bug (asynchronous timing).
Clear Narrative: Presents a relatable story of encountering a problem, seeking help, and iterating towards a solution.
Showcases AI Capability: Effectively demonstrates the advanced debugging and problem-solving skills of an AI agent (Claude in Cursor), going beyond simple code generation.
Detailed Process: Includes the AI’s own explanation of its reasoning, the steps taken, and the role of specific configurations (terminal rules).
Practical Code: Provides a concrete code example (the OrderedMessageQueue) as part of the solution.
Discusses Tradeoffs: Explores the nuances of the solution, including initial compromises (delays) and the reasoning behind the final approach.
Highlights Specific Tools: Gives insight into the practical application of Cursor and its Agent mode.
Honest Reflection: Includes the failed attempt to integrate the solution into BaseCrud, showing a realistic development process with setbacks.

Weaknesses of the Article:

Niche Audience: The technical details (asyncio, specific Python libraries, Cursor, git workflows) might limit appeal to those unfamiliar with this stack.
Conversational Format: While engaging, the Q&A format might be less direct or structured than a traditional technical write-up for some readers.
Assumes Context: Presumes some reader familiarity with the author’s project (Pipulate) and tools.
Lengthy: The full exchange is quite long, although the user requested a summary of it.

AI Opinion:

This article provides a compelling and detailed case study of advanced AI-assisted software development. It moves beyond theoretical capabilities to showcase a practical application where an AI agent diagnoses and resolves a non-trivial bug involving asynchronous programming, version control analysis, and system interaction. The inclusion of the AI’s own explanations and the step-by-step refinement of the solution (from delays to a custom queue) offers valuable insights into the collaborative potential between developers and sophisticated AI tools like Claude within an environment like Cursor. While the specific technical details might target a developer audience, the narrative effectively illustrates the power of agentic AI in tackling complex, multi-step problems that previously required significant manual effort and debugging expertise. The honesty about the implementation challenges (like the BaseCrud integration attempt) adds realism and underscores that AI assistance is part of an iterative process, not always a one-shot magic solution. Overall, it’s a strong testament to the evolving capabilities of AI in software engineering workflows.