If you’re using agents with GitHub Issues but skipping pull requests, there’s a gap in your workflow you probably haven’t noticed yet. I didn’t either until I kept watching “fully tested” code break the moment it merged. That’s what made me realize that pull requests matter even more in an agentic workflow than they do on a traditional team.
For most of my career, pull requests were something I did on other people's projects. My background is IT and information security, and while I spent years working alongside dev teams, I was never really inside the development lifecycle outside of security. I understood the SDLC from textbooks and from observing how developers worked, but not from owning it myself. Most of the time I had contributor-level access at best, which meant I could submit a PR, but someone else decided what actually made it into production.
So when I started building my own projects solo, I dropped pull requests entirely. No approvals, no gatekeepers, just me and the repo. And for a while, that felt great. It felt fast, clean, and frictionless in a way that traditional workflows never did.
🤖 How My Workflow Is Actually Set Up
My current setup runs like a small team, except the entire team is made up of agents. Every feature starts with a PRD and spec documents that live inside a docs/features folder within each project. From there, an agent creates GitHub Issues based on those specs. Different agents handle different parts of the workflow, one writes the code, one runs QA, one focuses on security. It is structured, it is consistent, and for the most part, it works well.
Where things started to break down was at the end of that process. I was letting the QA agent test the implementation, confirm everything passed, close the issue, and then merge. On paper, that sounds completely reasonable. In practice, it ignores something important, which is that code can pass every test in isolation and still fail once it is introduced into the rest of the system.
💥 What Kept Breaking
The pattern became hard to ignore. QA runs, everything looks good, I merge, and then something unrelated breaks. Not the feature that was just built, but something that had already been stable. Something that no one thought to re-evaluate.
It forced me to step back and think about what was actually missing from the workflow. The agents were doing exactly what I asked them to do. They were testing the feature. What they were not doing was evaluating how that feature interacted with everything else that already existed. No one was looking at the change holistically before it became part of the codebase.
That is the gap that pull requests fill.
✅ What the PR Actually Does Now
Now, instead of closing the issue and merging, the process routes through a pull request. The QA agent still validates the feature, but it now opens a PR instead of ending the workflow. A second agent reviews the diff, looking for logic issues, inconsistencies, and potential conflicts. After that, I step in and review it myself, specifically from a security perspective.
And this part matters more than people think. Agents are helpful, but they are not infallible. I have had multiple agents review the same pull request and approve it, only to find a security issue myself that none of them caught. Without the pull request, there would have been no natural place to even pause and look. That code would have gone straight into production.
The PR is what creates that pause.
🧠 Why Solo Developers Skip This
Pull requests feel like a team ritual. Something designed for multiple people, approvals, and process. When you are working alone, it can feel unnecessary, even heavy.
But working solo does not mean you are not part of a team. It just means your future self is the other person on that team. The person who has to maintain the code, debug unexpected behavior, or understand why something was built a certain way is still you, just later.
The pull request becomes a checkpoint for that version of you. It is the moment where you step outside of the code, look at it as a whole, and decide whether it is actually ready to live in the system.
If you are building with agents and skipping pull requests, you are relying on the assumption that “the agent said it works” is the same as “this is ready.” It is not. Pull requests are what close that gap.
