The psychology of PR in the age of AI
🧠 human psychology → ⚙️ tooling shift → 🤖 new collaboration model
The Psychology ofPR
A Pull Request (PR) isn’t just a code review mechanism, it’s a psychological contract. When a developer opens a PR, they’re not just asking for approval… they’re saying:
“Here’s my work. Please review it but respect my ownership.”
That sense of ownership is powerful. It fuels accountability, pride, and craftsmanship. It’s also why developers feel uneasy when someone pushes changes directly into their branch. It feels like someone rewriting your paragraph while you’re still typing it.
Even when the intention is good, the impact can be unsettling. It breaks the loop of autonomy and learning that’s key to growth. That’s why most senior developers review, don’t push. They guide instead of overriding. They influence through feedback, not force.
Psychologically, it builds trust, respect, and shared ownership; the real foundation of high-performing teams.
Tooling shift: the Agent Modes
In the age of AI, a new software engineering approach has emerged: Vibe Coding where developers collaborate with LLM-based coding agents by validating outcomes rather than reading or writing every line of code.
It’s not just a two-actor interaction but more a collaboration among three forces : humans (who mainly express intent and judge quality), projects (which provide context such as code, data, and knowledge), and agents (LLMs that handle code generation and refinement).
There isn’t just one way to do Vibe Coding, it actually comes in many flavors, depending on how much control you want to keep and how much you trust your coding agent.
At one end, there’s Unconstrained Automation, where agents run almost fully on their own, taking care of everything from implementation to testing while you just validate the results. Then there’s Iterative Conversational Collab, which feels more like pair programming, a back-and-forth between you and the AI, refining ideas through dialogue.
Some prefer a more structured approach with the Planning-Driven model, where the agent breaks down complex tasks, makes a plan, and executes it step by step. Others lean into the Test-Driven model, where quality takes the front seat — the agent keeps improving code through cycles of testing and feedback.
And for those who want the best of all worlds, there’s Context-Enhanced Vibe Coding — where agents combine all that structure, testing, and autonomy while tapping into project data, external knowledge and tools to make truly informed coding decisions.
Today, there’s already a growing ecosystem of tools helping developers embrace Vibe Coding — from GitHub Copilot and Claude to Cursor, Gemini, and many others that blend seamlessly into our daily coding workflows.
At work, GitHub Copilot is the vibe-coding tool we chose.
It’s also worth noting that GitHub Copilot now comes with two agent modes:
- Agent Mode runs locally on your machine, attached directly to your IDE helping you code, refactor, and experiment in real time.
- Copilot Coding Agent runs in the cloud, working asynchronously in the background tackling tasks, refactors, or bug fixes while you focus on something else.
That said, I noticed that many developers still feel a bit uncomfortable with the in-IDE agent mode. It’s an intimate space, your editor is where you think, experiment, and make mistakes.
Having an agent “watching” or proactively suggesting changes there can feel intrusive, confusing or even like it’s taking creative control away. Bottom line, it takes time (and trust) to shift from “this is my code” to “this is our shared workspace.”
On the other hand, the Copilot Coding Agent adoption was pretty fast. It has quickly become our favorite kind of pair-programming partner quietly changing the way we develop software starting from the psychology of the PR.
🤖 Changing the PR Psychology with coding agents
But how does the our development workflow changed since the Copilot Coding Agent adoption?
The starting point is still the same, a work item. But now, instead of assigning it to a teammate, we hand it over to a Copilot SWE agent that plans the approach, explains its reasoning, and implements the change. The agent creates a branch, opens a PR, and does all the technical work: fast, consistent, and traceable.
Sometimes the result is not good or the issue description fails to convey nuanced requirements and architectural constraints.
And that’s fine. If the outcome isn’t what you expected, just trash the PR, refine the work item or the project context, and try again.
If the PR needs improvements, that’s where the psychology shifts as a senior developer, you can pull the branch, adjust the implementation to steer it in the right direction, push it back, and ask the agent to continue from there. No hurt feelings. No broken trust. The agent won’t get mad, it will just keep learning.
It’s the best of both worlds: the speed of AI paired with the critical thinking of a senior developer.
PRs stop being about ownership and start being about collaboration at light speed.
Finding the balance in the age of AI collaboration
As powerful as this new model is, there’s also a subtle risk hidden in its efficiency.
When multiple AI agents can work in parallel, each generating code, fixing bugs, and opening PRs at machine speed it’s easy for developers to slip into a state of perpetual context switching.
Instead of feeling empowered, teams may start to feel stretched, never fully engaging with the deeper architectural thinking behind their work. What was meant to save time can, ironically, create cognitive overload and, in the long run, burnout. The key is to find the right pace: AI should boost human creativity, not overwhelm it with too much parallel work.
In the end, the healthiest workflows will be the ones where AI accelerates delivery without compromising depth because even in the age of AI and extreme automation, software still reflects the minds that guide it.