The New Bottlenecks After Coding

RobotPaper's analysis identifies deployment, code review, commit conflicts, architecture knowledge, testing, and specs as the new bottlenecks after coding becomes easy. The article highlights that with 1,000 agents pushing 10,000 commits daily, conflicts become a major issue, and proposes game theory for agent negotiations. It also mentions tools like LowKey, Cloudflare agent accounts, Reposwarm, and frameworks like Superpowers and BMAD to address these bottlenecks.

Pattern https://robotpaper.ai/tag/pattern/ The New Bottlenecks After Coding They're not really new, we just never really got to them - we just assumed they were there as a force of nature. Let's list them out I'm sure there are more than this list : - Deployment: Infrastructure is the new bottleneck after coding. - You write the code, but now you have to wait and get a proper environment set up, or permission to deploy to such an environment, or get all the "glue" and much in the environment to play nice with the code you just wrote connections between services, permissions, roles, logins, database connections , bucket permissions etc etc .... it's a long list . - The Pattern: Agent-Owned Accounts Deploy Environments https://robotpaper.ai/agent-owned-accounts-deploy-environments/ pattern is one way to solve this, - Stuff like LowKey https://github.com/inceptionstack/lowkey/?ref=robotpaper.ai solve this bottleneck today, for example, but most of the world isn't there yet . - You can see buds of solutions with cloudflare agent accounts https://blog.cloudflare.com/agents-stripe-projects/?ref=robotpaper.ai , for example. but those are still relatively limited. - Code Review is the new Bottleneck: I believe that - Slowly AI Agents will review more and more of the code - Humans will review more and more of the overall architecture - Code Commits & Conflicts will be the new bottleneck: - When you have 1,000 live agents pushing 10,000 commits a dat in parallel into the same codebase, conflicts will become the new bottleneck. You can see this happening today in project slike OpenClaw, where getting a release out the door become a nightmare due to the simple loop: - The agent conflict loop: - A: Agent stages a PR - B: Needs rebase since a new commit just landed in main just before this PR - C: Rebase has a conflict - D: Agent fixes conflict - Go to - A, repeat ad infinitum - One way I am playing with to solve something like this is applying game theory strategies to agent-to-agent negotiations on who pushes what and when. It's still an open question if that is a good way to go abotu this, but it's an interesting problem - Agent Company / Architecture knowledge is the new bottleneck: - Agents needs to know what they are working on, and what exists around them so they can plan and build things that fit into the existing coding landscape other repose, good architecture practices, upstream and downstream dependencies , accepted and declined ways of working across the entire company, secrets, regulations etc... - Those things keep changing, and will keep changing even faster see previous bottleneck point on code commits - Projects like Reposwarm https://github.com/reposwarm/reposwarm?ref=robotpaper.ai which I wrote help to deal with at least some of that issue cross-repo architecture that is not stale, for agent context - There are many projects trying to build a "company brain" but the situation is all over the place right now. - Testing is the new bottleneck maybe not anymore : - in a world where coding and features are close to free to build, agent functionality verification is king. So if you know how to write good tests, and you write them and the agent uses them, you get a pretty good speed up on getting stuff to work across multiple changes as time goes by. - Greenfield code is easy, as code changes, tests become more and more critical. - But is it a bottleneck to write tests? not really - it's easy to generate tests. but generating good tests is still a skill to teach the agent. - Specs are the new bottleneck: - PMs need to generate good specs faster since coding is easy now. - there are many frameworks to try to help this: superpowers https://claude.com/plugins/superpowers?ref=robotpaper.ai by claude, BMAD https://github.com/bmad-code-org/bmad-method?ref=robotpaper.ai , Spec Driven Development did you know kiro actually came out first with this https://kiro.dev/docs/specs/?ref=robotpaper.ai from an AI-IDE perspective , AI-DLC 2 https://github.com/awslabs/aidlc-workflows?ref=robotpaper.ai , and more. - Orgs are still learning how to work this way and it's still up in the air if any of this truly helps - but early signs show promise. But there's a lot of low hanging fruit here so it might just be that any change here is for the better. - Monitoring is the new bottleneck: - If everyone write and deploys more code and agents are inherently "creative" then monitoring all these processes and all those newly deployed applications that can be generated on a whim become a new potential bottleneck. We have a pretty mature monitoring industry, but monitoring LLM interactions, and all the potential upstream and downstream risks becomes a new area. - An agent that can monitor what it had built and deployed can help alleviate this. - Monitoring all the agents currently running locally, remotely and across the org - not a perfectly solved problem today unless you want to be extremely vendor locked - I'm sure there's more but I can't remember right now. I might edit this post later to add more.