Why process is more important than ever for getting the most out of Claude and others

Adventuring through the Canadian Rockies Four Old Fashioneds in on Thanksgiving 2025, I hit the Ballmer Peak.

As always, a relevant XKCD

Ballmer Peak For those who don’t know, the Ballmer Peak is a mythical BAC level where your coding ability 10x’s but sits precariously on the edge of becoming non-existent in either direction. I believe that my peak lasted longer due to a mitigating factor of all-you-can eat Brazilian Steakhouse meat from Thanksgiving dinner sitting in my belly.

What did I do with this Ballmer Peak? I played with Beads of course.

Beads as Agent-First Design Beads is an Agent-oriented issue tracking system by Steve Yegge. I previously wrote an article about his newest framework, Gas Town, and how I used it for 10 out of its first 48 hours of public existence. Beads is not meant for human reading, tracking, or modification, but we can still do all of those if we really wanted to. Its intent is purely for the Agent to store the current state of the project to disk over time. It is fast, using a local SQLite cache that eventually writes down to a JSONL file. I’m thoroughly convinced Beads is the right shape of a task-tracking system for coding Agents, because when have you heard of “Enterprise-Grade To-Do Lists”?

You haven’t. Then why do we accept that to-do’s are the state of the art built-in planning tool for frontier coding Agents?

Speed-Running the History of Software Engineering Process

TO-DOs To-do lists are largely unstructured data. It’s a jumbled mess even for one person’s list of to-dos (at least mine). They’re like sticky notes covering a person’s desk and peace of mind. They may be good for temporary reminders, but not for medium to long-term planning.

Imagine organizing to-dos across a team of 5, 10, 100, 10,000 people. You need to have a much more structured system to organize work top-down, bottom-up, or laterally for corporate "cross-functional synergies.” Each ticket pushes the enterprise forward, delighting customers, and hopefully increasing shareholder value (or something like that).

Yet with coding Agents, most people accept the defaults of ephemeral bulleted to-do lists for keeping track of what needs to be done, or at least that’s what we are presented with in the TUI. We don’t really have the ability to modify or introspect the data structures that are behind those bulleted lists in the Agent, or at least it isn’t obvious to me, a power user of these things. Beads allows us to do both.

Spec / PRD / Agent Markdown Litter People also rely on overly complex and verbose spec, PRD, or enthusiastically Agent-generated Markdown documents. These may still help at the beginning of the process as design documents to potentially to help define Beads, but they may soon become out of date as soon as Agents metaphorically start putting pen to paper in code. Code is ultimately the source of truth. Documentation always lies to some degree.

I’m not completely ruling out Markdown design document usefulness, but imagine we could only have one Google Doc to keep track of a project. If I just use it for myself then it probably works well enough. If I introduce a second person, my teammate, to start collaborating, it probably still works pretty well but we may collide occasionally and overwrite each other’s work. As we scale up the number of editors on a doc, we may start changing the entire meaning of certain sections daily. This is because there would be so many new people who would not have the context for all the decisions and work that led up to writing the current version of that document.

Eventually it would get so expensive to try to scroll up and down the document to try to find the right place to view, edit, and cross-reference between different sections, someone may have the bright idea to create new documents and links to those other documents from this first document. Now we have an ecosystem of documents in space that we need to keep track of that have no organization themselves. Document links may be modified And broken, orphaning documents to the void unless somebody remembers to go back and get them and keep them up-to-date.

Someone else may now get the bright idea to add metadata around these documents to name, track their status, change history, organize them outside of their relationship to each other in this void of Google Docs hell. Congratulations, you just invented an issue tracking system, but worse. Why do all this work with plain text files when we could have a specialized tool for the job?

It does feel like we are speed-running the history of software engineering processes. Adhering strictly to a spec feels like Waterfall development. Planning Beads feels more like Agile development because it is more flexible and can adapt to implementation details the Agent may run into in the middle of doing the work.

Beads: JIRA for Agents Beads is fundamentally different because it mirrors a well-trodden path for software engineering that everyone in the industry has used. Beads are ultimately json objects stored on disk. They have a nice binary interface to update them that Agents can easily understand. Yegge is on the forefront of something that I’m sure will become an entire field of study with Agent “experience design” (like UX, but the U is an A now) or Agent “ergonomics”. Basically how well does an Agent understand how to use a new tool that it hasn’t seen before?

I am aware that there’s other Agent issue trackers such as Linear and the like. Same thing with Gas Town and other Agent orchestrators. Agents are a brand new technology that is part of the broader massive AI adoption curve. There will be much more duplicated effort now than ever thanks to more people feeling empowered to pick the low hanging software fruit with Vibe Coding.

Yegge Fanboying Break I choose to use these tools by Yegge because he has Vibe Coded more than nearly everyone else on the planet, plus he is already a supremely seasoned developer. He is probably among the most experienced with applying Agents and LLMs to coding outside of the people actually making them. He is much further along down the road of how to get value out of Agents and what tools they might need than us mere mortals are.

I value the sheer experience and perspective earned by someone who has put in more hours doing a thing than anyone else. They tend to be right. Not to say that he is infallible, nor always will present the tightest, most optimal solution, but he has earned an honest try from me to learn his systems and I’m willing to contribute to them.

Have a “Daily Driver” If you want to use other tools that are basically swap-ins for Beads or Gas Town, be my guest. But whatever tools and frameworks you pick, stick with them. I think engineers have a tendency to always be on the lookout for the next shiny high-leverage tool to their own detriment. Trying a dozen different frameworks or Agents that accomplish the same goal doesn’t net you significant experience points in any. What will pay dividends for you is sticking with one framework for a long enough amount of time to obtain a certain level of mastery over it.

Baseball players don’t change their bats every day. Golfers don’t change their clubs every week. Racecar drivers certainly don’t change their cars whole cloth every month. Why are you constantly chasing the latest Agent framework of the week once you have a good established system? Oh, you don’t have a good established system? Maybe that’s why.

I’m not saying never try new things; just look at me. I jumped two feet into Gas Town with no hesitation like it was a New Year’s resolution (it was released on 1/1/26). That was based on the fact that Beads had been an integral part of my workflow for months at that point, and this new Agent orchestration system was built on Beads. It was an evolution of my current process.

I also used Gas Town for 10 hours with no expectation of a return on investment because the initial article was so crazy and out there. I ended up getting one anyway. I used it during my winter break so I didn’t have any looming deadlines or expectations of performance. This may not be the same situation for everyone.

Your next 50% improvement in productivity likely will not come from the next AI tool, it will more likely come from using the same AI tool for a long enough period of time. Using the next tool will have a guaranteed cost of a learning curve that will make you less productive than your current setup. Alex Hormozi estimates this to be about a 20% negative for anything in business. So you have to have an expectation of a 50% positive increase with an initial 20% negative to just get a 30% net increase in performance over time.

I think more people need to be aware of that, especially those who are new to Vibe Coding. The haters online who say "Vibe Coding didn’t work for me” probably didn’t use it for long enough to really understand how Agents handle, or fall under a novel or niche branch of coding where Agents aren’t well-trained on their specialty. I get it - everyone is under time pressure and performance expectations in this new software engineering economy. It is a real opportunity cost to try anything new, fail at it, and still have work to be done by a certain time.

We need to 80/20 this. 80% of the time we are using the same set of tools, getting better at them, and 20% of the time taking a risk and trying new things to look for new high-leverage opportunities. The space is moving fast and who knows if we’re even going to be using the same toolset in six months. I’m certainly not using the same tools as I did in June of 2025. I threw away my IDE in that time and now trying to use as many Claude Code Agents as possible. The principles learned from really sitting with one set of tools, holding that part of the equation constant, while experimenting with one thing at a time will likely apply moving forward to anything new.

Ballmer Peak - Reprise Getting back to that Thanksgiving Ballmer Peak.

Beads opened my eyes to what was possible with Agents. It showed me that if we treat Agents as some form of software engineer, maybe not a fully responsible software engineer, but maybe a junior engineer, we can more effectively use them. That led me to think: what if we use these different Agents together?

What if we treated Claude, Codex, Gemini, Cursor, Auggie, etc. as if they were teammates rather than competitors? I started having them review each other’s code on pull requests and that proved to be effective. Each of these models is trained on more or less the same Internet of publicly available code, but in slightly different ways. They each also have special Agent sauce baked into their CLIs which cause them to each behave a little differently even if they are using the same model on the backend.

My Ballmer Peak moment was realizing we can use these Agents to not only review PRs but to review the Beads plans themselves!

Beads is genius in the fact that it has all the features of a ticketing system. A crucial feature that was included was comments. I realized that I could use the same team of models to non-destructively review my plan at the beginning of my Vibe Coding process as I do at the end of it.

To be clear, my Vibe Coding process is:

Plan Beads with Daily Driver Agent. Use TDD, Tracer-Bullet, and MVP concepts to constrain focus. I’m currently toying with the idea of putting a spec/PRD step before this, TBD.

Multi-Agent Review Beads Plan

Refactor Beads Plan with Daily Driver Agent

Implement Beads with Daily Driver Agent, monitoring context usage. Restarting with a new Agent as necessary.

Make PR with Daily Driver Agent

Loop until CI checks pass with Daily Driver Agent

Review PR with Multiple Agents against planned Beads.

Daily Driver addresses comments or kicks out out of scope issues to new Beads

Merge PR

Beads has a major benefit over plain text documents because there is no native support for multiple Agent editors in one markdown document. You can try to have Agents sign their name on changes in a document but that gets messy and unreliable pretty quickly. Ultimately you’re potentially clobbering changes of other Agents whenever you modify one document with no specialized fields.

Having Agents use a purpose-built tool with the existing conventions and processes baked into the assumptions of the tool is the major key here.

Mapping the Future of the Software Engineering Process to Agents So what other tools should we try to map to Agents? What do we use day-to-day as software engineers that Agents may benefit from? I’m going to start to irresponsibly speculate here.

Agent “E-Mail” Gas Town and other frameworks are starting to use the concept of “Agent Mail”. People are giving Agents ways to communicate with each other more directly in an P2P Agent-to-Agent way or in a loop on a shared resource. This loop may try to come to a consensus around a Beads plan or a PR review, and deadlock disagreements may yield to the choice of the user. This leads me to believe that we will see an evolution from “email” to a form of “Slack for Agents”.

Slack for Agents Slack for Agents implies the existence of “Slack search for Agents”. Slack search is one of the most helpful features of any tool I have ever used. If I have a problem that is specific to working at my company, I can search it and more than likely someone else has already encountered it. I can read the conversation that was had about the problem and how they resolved it. This is a way that we can "save” the results of all these tokens that we burn. All of the decisions that these Agents make every day for us are just thrown away as waste product.

I wish I could cite a Hacker News thread source here that I read a couple months ago, but I can’t find it. Dude was wicked smaht.

One of the key things they brought up was that the Agent-Human prompt history is the best source of knowing how decisions were made, a literal historical record of context. A “duh” thing to say, but still nobody is saving them by default. This person was making a dump of all their prompt chat histories locally and allowed their Agents to look back on those previous conversations when they get stuck on something. I think whoever can make this first/best is going to have a crazy powerful tool.

Tokens would no longer be burned in debugging and evaporate into the ether. Instead, they would turn into a product that can potentially save tokens and improve performance in the future. Augment’s Agent, Auggie, saves tokens by pre-indexing your codebase so that Agents can query it instead of blindly grepping around. I’m curious to see who comes up with this concept for single and multiple Agent chat histories and if it’s useful. Maybe it exists already and you can let me know in the comments.

Agent Sprint Planning Anytime we have a “meeting” or “ceremony” in Agile terms, that’s an opportunity for multi-Agent consensus-seeking review. It all depends if burning these tokens at these various points is worth it to you, but I do believe the teams who have the most tokens burned will be the most successful as well.

Agents can help with Sprint Planning by ensuring that all tickets meet a certain definition standard and can ask the user questions about tickets in a conversational way to fill them in. I’m also sure there will be some amount of “Scrum Master Copilot” built into JIRA to help assign tickets to developers, optimizing for various goals like: maximize total points closed as a team, bringing developers up to speed on certain parts of the stack for team redundancy, or to even to schedule work in such a way to avoid interpersonal conflicts between developers.

Agent Daily Standup We may not even need a daily stand up meeting anymore, at least in the way that we have it now. All project status will be updated in JIRAs automatically by the Agents and even sent to an automated daily standup thread. So where does this leave the engineering manager? Potentially teams can spend the first 5 minutes of the meeting reading the automatically generated reporting and then spend the next 10 minutes focusing less on “status update” and more on higher priority items like “blockers” and coordinating cross-cutting changes. Not everyone would need to talk every day, and that would be okay.

Agent Retrospective Having a structured way for Agents to reflect on how a given Bead/feature/project implementation went so that it can apply lessons learned into long-term AGENTS.md behavior. This feels like it would be another opportunity to let the various frontier model Agents collaborate together to create worthwhile process-as-code improvements moving forward.

A note about AGENTS.md is that you don’t want it to be too long. 100-200 lines should be plenty to get your point across to your Agents. Otherwise, your Agent starts “forgetting” rules, and you don’t get to choose which ones it remembers. Theres’s various techniques like “progressive disclosure” that enable linking to larger, more detailed documents as necessary.

Conclusion I haven’t looked for these tools, and I’m sure they exist somewhere as a prototype in someone’s public Github. I’m curious when we will see widespread adoption of these as standard practice. Since it’s the beginning of 2026, I’ll call by 2027 the rest of our workflows will be heavily Agent-ified (Agentic?), just like how the actual coding process has been upended by Agents in the past 6 months.

Thank you for reading this far. I used a lot of speech to text in this article to write. I think it puts more of my literal “voice” in here, but also made it a much longer article. Let me know what you think!

Please subscribe to the newsletter if you haven’t already at enterprisevibecode.com

I also have been livestreaming myself Vibe Coding on Youtube early in the mornings PST Monday, Wednesday, and on the weekends at @EnterpriseVibeCode come hang out!