The End of the Pull Request: Why Your Workflow is Your Biggest Bottleneck

The biggest barrier to engineering speed is not a lack of AI tools. It is the persistence of legacy workflows that prioritize distrust over delivery. By removing pull requests and feature branches, teams can unlock massive productivity gains. This shift forces a move from verification by committee to verification by evidence, where engineers build smaller, safer changes that move directly to production. For engineering leads, the advantage is systemic: it creates a high-throughput pipeline that makes fixing bugs as fast as shipping them. The transition is uncomfortable, as it requires a fundamental change in how teams manage trust and state, but it creates a competitive advantage against organizations still stuck in the slow cycles of the past.

The Hidden Cost of Safe Workflows

Conventional wisdom suggests that pull requests (PRs) protect quality. Dario Hamidi, an AI engineer at Amp, argues the opposite. PRs were designed for strangers on the internet, not teammates. When used within a team, they signal a lack of trust that creates a cascade of inefficiencies.

PRs accumulate changes, encourage context switching, and make verification an afterthought. Because the effort to boot up a version of an application from a PR is high, developers rarely do it thoroughly. This leads to the worst-case scenario of finding architectural flaws only after the work is complete.

> Pull requests come from an environment where people do not trust each other. If a stranger on the internet wants to make a change to your project, of course you do not give them the keys to your home. If you do not trust your colleagues to that level, and you allow them to enter your living room, then maybe something else is wrong.
>
> -- Dario Hamidi

By eliminating PRs, you force a shift in psychology. Developers start pushing smaller, safer commits because they know the code is going directly to main. This is not about skipping quality. It is about optimizing for a faster feedback loop. If a bug is shipped, the system is already optimized to push the fix immediately.

Why Juggling Knives is a Design Failure

When teams struggle with AI agents going rogue or deleting production databases, they often blame the AI. Hamidi suggests this is a failure of environment design, not agent behavior. The solution is to move beyond approval fatigue, where humans manually approve every tool call, and instead focus on deterministic boundaries.

If an agent has the power to delete a production database, the problem is not the agent. It is that the database connection had the permissions to allow it. By applying systems thinking, you isolate the model layer from the deterministic layer.

> There is a graph in my head where if you have more trust, you parallelize more with agents. Part of your job is to create an environment in which you can trust the agents.
>
> -- Dario Hamidi

This requires a shift in the Agentic Engineering skillset. Stop trying to supervise every action and start building environments where the agent cannot cause catastrophic damage, even if it tries.

The 18-Month Payoff: Remote Execution and Orbs

The next frontier of velocity is moving away from local development machines toward remote execution environments, which Amp calls Orbs. These are ephemeral, well-connected VMs that eliminate the friction of port conflicts, local dependency hell, and hard-coded configurations.

While the industry is still grappling with how to handle short-lived credentials and state management in these environments, the payoff is immense. Orbs allow for massive parallelism. When you can spawn 100 environments to test different hypotheses simultaneously, the bottleneck ceases to be the machine and becomes the human cognitive bandwidth. This is where the real competitive advantage lies. Those who master this level of parallelism will be able to iterate at a speed that makes traditional local-dev teams look like they are standing still.

Key Action Items

• Implement a No-PR Experiment: Over the next two weeks, require all team members to push directly to main. This will be uncomfortable, but it will surface the exact areas where your team lacks confidence.
• Audit Agent Permissions: Immediately remove write access to production databases for any agent-accessible credentials. Move to read-only roles and use OIDC workload identity federation where possible.
• Automate Triaging: Start using AI to aggregate bug reports. Instead of manually reviewing 60+ reports a day, build a system where agents categorize, verify, and propose fixes for you to review in batches.
• Invest in CI/CD Speed: If you move to direct-to-main deployment, your CI pipeline becomes your biggest constraint. Prioritize reducing build and test times. If it takes 30 minutes, you will naturally stop pushing frequently.
• Adopt Remote Environments: Transition from local development to remote, ephemeral environments (Orbs) to eliminate port conflicts and environment drift. This pays off in 6-12 months as your team scales and parallelism becomes necessary.
• Shift from Approval to Evidence: Stop asking for human approval on every code change. Instead, require the agent to provide evidence (screenshots, logs, test results) that the change works as intended.