Agentic coding has the risk of doing “One More Prompt” before finalizing. I’ve been using agents for a while now and found myself running into this trap a few times before I realized how to solve it. Agents make it so easy to fix things, that it’s tempting to increase the scope for no good reason.
In this example, I’ll take you through a journey of implementing a post-editor for RocketSim‘s Xcode Simulator recording feature. Recording the Simulator is one of the most popular use cases, so I decided to further enhance it. I scoped it well, but it’s not a small feature that you can build in a few lines of code.
Understanding the “One More Prompt” scenario
Just before lunch, just before I would make myself some coffee, or just before I would walk the dog:
“Let’s trigger one more prompt so I have something to review when I come back”
These are just a few scenarios that happen to me daily now that I have embraced agentic coding. A fix is just a prompt away.
At the same time, during development, I would encounter bugs or opportunities for improvement. Normally, these would take me about 30 minutes to fix manually, but now I can combine them into a single planning prompt and fix them straight away.
Why would I postpone fixing it?
Ending up with a massive pull request
And so it began. I worked on the post editor for screenshots and videos. It looks pretty awesome:
If you want to test it out, you can join the RocketSim beta here.
This whole view did not exist before. It wired up a lot of existing logic, added a new editing window, and applied all kinds of performance optimizations to be able to edit styling when the video plays real-time.
The first mistake I made was to develop it all into a feature branch. I did trigger worktree results into a separate branch (e.g. feature/video-editor targetting epic/post-editor), but I did not carefully enough review all the changes. “If it works, it works” was something that I thought a little bit too much.
The result was a massive PR:
13,758 lines added, 1,057 lines removed is just way too much.
At the same time, I was postponing changes as I first wanted to get this massive change into the main branch.
I scoped it well, but I just kept prompting. I constantly had the idea I was almost there and I needed just One More Prompt. The reality is that 100% was actually 80%, and I still had to fix the remaining 20% with many single prompts.
What I learned: A different way of scoping
I scoped the feature thoroughly; I even created dedicated branches targeting the core feature branch (feature/capturing-editor-refactor in the screenshot above is the actual feature branch).
When I tested out the final delivery, many things turned out to be bad performing or not how I envisioned the final state. Yes, things worked great somewhere along the way, but final prompts broke more than they fixed. A major reason for this was that I did not take the time to review the code well, but I also created too many large PRs along the way.
Using the massive PR as inspiration for Agentic Coding
What’s interesting is that something bad turned into something great. I had a reference PR as inspiration for agents to pull changes from. I decided to revisit the feature completely and start over.
The goal was to get things merged into the main branch quicker, being able to truly mark things as done. Some of these changes affected production code, some PRs simply prepared the codebase for the future ahead.
I reviewed every single file inside GitHub, and I only merged the PR in if things looked truly solid. This made me understand the code changes much better and builded confidence in the final outcome. I know it sounds ironic, but agentic coding makes it too tempting to let lose of strict reviews. I regret, I learned.
As a result, I ended up merging many smaller PRs pretty fast:
Everytime I would start a new agent, I would ask it to use the current state of the main branch and compare it with the big inspirational branch:
“Analyze our main branch and compare it with feature/capturing-editor-refactor. Find the smallest next change we can copy over. Don’t blindly copy, analyze the code changes, simplify, and keep tech debt low”
You get the idea of the prompt and its impact. I always used it with planning mode and decided on the suggested changes next. Some PRs only contained changes like adding public modifiers: super easy to review. Even though those changes existed in the massive PR as well, they became much easier to mark as done now that I moved them into dedicated PRs.
Massive PRs weren’t completely prevented
I still ended up with a few ‘massive PRs’. It all depends on what you call massive, but 20+ files and several hundred lines of code is something I would call massive. The biggest difference, though, was that the PRs were focused on a single change. I could review those changes much more easily, and I would mark each file as “Viewed” in GitHub. Iterations would become visible as non-viewed, resulting in a pretty optimized workflow to make forward progress.
Key takeaway: reconsider the “One More Prompt”
The key takeaway for me is to reconsider the One More Prompt.
- Is this a bug that already existed before?
→ Move it into a new PR - Is this something we don’t really need to fix right now?
→ Move it into a new PR?
What I mean to say is that you could sometimes close the task for the current agent and move the One More Prompt into a new agent context. That allows me to mark things as done more quickly while still effectively applying the same fix. The key difference is a dedicated agent for a specific task with a dedicated PR that is easier to review.
Conclusion
Agentic Coding brings new learning and challenges. I’ve been developing apps since 2009, both as an indie and as part of a team. Yet, the workflows I’ve been using need to be adjusted for better efficiency in today’s development environment.
These workflows are just the beginning and a subset of what I’ll train in my dedicated course. I’d love to welcome you to it: Agentic coding fundamentals for developers.
See you there?