Recently, while working on personal projects, I've been feeling something strongly.
There's so much I want to do.
Thanks to generative AI, I can write code much faster now.
And yet— my overall development speed hasn't increased as much as I expected.
This disconnect led me to start building DevLoop Runner.
Conversational AI is Fun. But You're Stuck on One Screen
The development experience with Claude Code or Codex is really great.
- You can build while having a conversation
- It assists your thinking
- The implementation quality is high
However, as I continued with personal development, I noticed a limitation.
In the end, you give one instruction,
wait for the response, check it, and move on to the next.
Open the terminal, give an instruction, wait for the response.
Even if you try to do something else while waiting, you can't really focus.
As a result:
- Work can only progress sequentially
- You still spend just as much time glued to the screen
- It's hard to do something else on the side
I started thinking:
"Maybe the only thing that changed is that AI does the typing now,
but the way we develop hasn't actually changed?"
In Personal Projects, You Tend to Avoid "Implementations That Might Fail"
There's another problem unique to personal development.
That is:
Hesitating to work on something when you're not sure it will pay off
- I'm not sure if this prototype will work
- But I have to think about the instructions, wait, check...
- If it fails, I'm left with the feeling of "wasted time"
This leads to
unconsciously discarding ideas
you really wanted to try.
As a result:
- You only choose safe implementations
- Less "play" and "adventure"
I realized this isn't a technical problem—
it's a psychological cost problem.
What I Really Wanted Was "Development Where I Can Try Things in Parallel"
So I came up with this idea:
Humans think.
AI works in parallel, in the background.
What if:
Issues A, B, C, D run simultaneously
You leave them for a while
Then review all the PRs together later
If it's good, merge it
If it's so-so, revise it
If it's bad, just close it
Even if it fails, no regrets.
This way,
you could more casually include
"small experiments" and "playful ideas."
This thinking was the starting point for DevLoop Runner.
What I Want AI to Handle Isn't "Thinking"—It's "Doing the Work"
There are tools out there
where AI autonomously drives development.
That's attractive in its own way,
but what I wanted was a bit different.
- I want to verify requirements and design myself
- I want to put my intent into test perspectives
- I want to make final decisions through PR reviews
In other words:
I don't want to hand off development entirely to AI.
I just wanted to delegate parallel implementation.
In DevLoop Runner:
- Starting from a GitHub Issue
- AI automatically proceeds with implementation and testing
- Outputs the result as a PR
Humans focus on
reviewing and making decisions—
that's the division of labor I had in mind.
What I Focused on During Implementation
Using Both Claude Code and OpenAI Codex
DevLoop Runner supports both Claude Code and OpenAI's Codex.
Either one works on its own,
but by combining both,
if one fails, you can fall back to the other—
which provides peace of mind.
Each agent has its strengths,
so I made it automatically select the appropriate one based on the phase.
When developing locally,
this kind of switching can be surprisingly tedious,
so this was something I wanted to automate.
Issue Granularity Is Incredibly Important
One thing I felt strongly while using it:
Issue granularity significantly affects success rate.
If you make the task too large for an Issue,
AI often fails because it can't make all the decisions.
Conversely, if it's broken down into appropriate granularity,
it runs quite stably.
What I'm considering for the future is
an Issue splitting feature.
First, analyze the Issue:
- This task seems too big
- It might be better to split it into sub-Issues
If it decides that, it automatically suggests sub-Issues.
I think having that kind of feature would make operations smoother.
Let's Be Realistic: Success Rate Is About 70%
To be honest,
the current success rate is around 70%.
Depending on LLM tuning
and how you write the Issue, it can fail.
When it fails,
the basic approach is to re-run.
If there's some intermediate output,
I sometimes leverage that
and recover in my local environment.
This is an area that still has room for improvement.
Building a System Where "It's OK to Fail"
What I think is most valuable about this tool
isn't the implementation speed itself.
It's making it less scary to try things.
- Write an Issue for a prototype
- AI implements it on its own
- If it doesn't fit, close it
That's it.
You don't have to bet your time and focus
on "implementations that might fail."
Just having this psychological safety
significantly changes how personal development progresses, I feel.
Who I Want to Use This
First, I want indie developers to use it.
Of course, I'd be happy if people developing for work use it too,
but I think it's good to start with people doing small-scale development.
Especially:
- If you're developing with LLMs (Claude, ChatGPT, etc.)
- But feel like your development efficiency hasn't really improved
For those people,
this idea of "trying things in parallel"
might provide some hints.
For Those Struggling with the Same Things
- Using AI coding but it's not as fast as expected
- Issues keep piling up and you're carrying everything yourself
- There are ideas you want to try but can't take the plunge
If you feel even a little of that,
this concept of "trying things in parallel"
is worth experiencing at least once.
DevLoop Runner is still evolving,
and initial setup (GitHub tokens, etc.) is required.
Still, if you think:
"This direction seems kind of interesting"
Try throwing an Issue at it.
Conclusion
Now that AI can write code,
what needs to change next
might not be development speed, but development courage.
- Humans think
- AI works in parallel
- It's OK to fail
I want to keep trying out
this kind of development style,
little by little.