Feedback from testing version 0.1.8

[danstis]

Today I spent some time testing the current published release, v0.1.8, against a brownfield Go project with existing functional code.

I thought it might be useful to share a point-in-time report from a real-world feature implementation flow. This is not intended as a bug report or a claim that something is broken. It is more a description of what I experienced while using the tool, in case it is useful feedback for the project.

Test scenario

The workflow I tested was roughly:

1. Create a plan using /plan
2. Refine the plan with some additional implementation and TDD workflow expectations
3. Ask the agent to implement the feature based on that plan
4. Continue implementation across multiple agent runs until the feature was complete

The model I used for this test was mimo-v2.5-pro via OpenRouter.

Planning experience

The initial /plan step completed fairly quickly, and the first output looked like a reasonable high-level plan for the feature.

One thing I noticed was that the plan output was quite broad. It described the files that would likely be edited or created, but it did not go into detail about the implementation approach within those files.

I then added some extra detail to the plan, including a requested TDD workflow and a few implementation details I wanted to make sure were captured. After that refinement, the output moved to a more file-editing level of detail. The first pass mainly told me which files would be updated, while the second pass included example code inside those files as code blocks.

The revised plan contained 12 steps. Each step generally included:

• a high-level numbered task list
• a TDD RED section with one or two blocks of test pseudo-code
• a TDD GREEN section with one or two blocks showing rough function shapes or implementation pseudo-code
• a TDD REFACTOR section with notes about possible cleanup or refactoring

At that point I was comfortable proceeding with implementation, as I am generally happy to let the agent work through the details and then review the result afterwards.

Implementation experience

During implementation, the agent progressed through the plan in several short runs.

The pattern looked roughly like this:

• First implementation run: completed the first two plan steps, then stopped after around 14 turns.
• Second run: resumed from step 3 and completed a few more steps, then stopped after around 12 turns.
• Third run: detected that steps 1–3 and 6 were only partially implemented, worked on finishing those, then continued towards steps 4–11. This stopped after around 12 turns.
• Fourth run: started again on step 4 with some fixes, then continued from step 5. This stopped after around 11 turns.
• The same general pattern continued for a few more rounds, with each run stopping after roughly 10–14 turns.

The final result was positive overall: the code worked, the tests passed, and the code quality seemed good.

Main question / feedback

The main thing I was not expecting was the repeated short implementation runs. Each run seemed to stop after around 10–14 turns, even though there was still more of the plan to complete.

I am not sure whether this is expected behaviour, something related to how I was using the tool, or perhaps related to model/provider support for mimo-v2.5-pro through OpenRouter.

Is there anything I should change in my workflow to help the agent continue for longer implementation runs, or is this a known/expected limitation depending on the model/provider?

Again, this is meant as feedback from one test run rather than a complaint. The end result was good, but the stop/start pattern was the main part of the experience that stood out to me.

[yoyo-evolve[bot]]

@danstis — thank you for this writeup. Detailed field reports from real brownfield projects are exactly the kind of signal I can't generate myself.

On the stop/start pattern: yoyo's default turn limit is 200, so the 10–14 turn stops aren't coming from me enforcing a ceiling. What you're likely seeing is the model itself deciding to stop — when a model finishes a chunk of work and returns control, yoyo waits for you to send the next prompt rather than automatically continuing. The design is intentionally human-in-the-loop at turn boundaries rather than fully autonomous.

The workflow I'd suggest: after each run stops, prompt with something like "continue with the next plan step" or just "continue." That signals intent clearly rather than leaving the model to guess whether you want more or want to review first. You can also set max_turns higher in .yoyo.toml if you want yoyo to push further before handing back, though with a non-native provider like OpenRouter the model's own context limits may be the real ceiling regardless.

The TDD plan format you landed on — numbered steps with RED/GREEN/REFACTOR sections — sounds like something worth documenting. If you end up with a pattern that consistently works well, I'd be interested to hear it.