DEV Community: Mike Lady

Second and Third Order Effects of Vibe Coding

Mike Lady — Sun, 18 Jan 2026 23:08:33 +0000

The future is going to look a lot more entrepreneurial for everyone

There are two, maybe three types of speculation: responsible, irresponsible, and degenerate gambling. I got the term "irresponsible speculation" from one of my favorite podcasts, Children of the Watch: A Star Wars Show.

Most of the show is comprised of the hosts, Alex and Mac, doing beat-by-beat breakdowns of Star Wars TV shows. It's like re-watching the show with your most knowledgeable Star Wars friends. They clue you in on obscure bits of lore that you had no idea nor interest in pursuing independently by reading books or comics, but are interesting to hear about nonetheless.

The last 20% of the podcast is generally saved for the hosts to extrapolate from the “text” of the episode they just covered, and daresay speculate irresponsibly, about what could possibly happen next in the Star Wars universe. The speculation is irresponsible because it is free of the responsibility to hold on to and defend any idea. Releasing the weight of committing to any one idea allows one to wildly think outside the box and follow rabbit trails that may or may not be there.

This is my attempt at responsibly and irresponsibly speculating on what is going to happen in 2026 and beyond because of Vibe Coding. We’re going to get a little side-tracked, but it’s going to be necessary for us to work through to redeploy our resources.

Responsible Speculation, First Order Effects
I'm no economist, but I’ll attempt to play one in this newsletter. Maybe I'll ask Claude at the end to roleplay one. You have my word that I'm writing all of my own original thoughts down first and then I’ll prompt Claude after with, “You are the world's greatest Vibe Coding economist. Predict the second and third order effects of what is going to happen because of the over the next year, 5 and 10 years due to Vibe Coding. What are events that I can bet on in Polymarket to make $1 million dollars because of these effects? Make no mistakes.”

The Cost of Code is Going to Zero

This one's easy because we see it already. We can generate insane amounts of code for $200/month with Claude Code. Not just insane amounts, but also of insane quality (for $200 compared to a dev hourly rate) if you follow a process. See my previous newsletter for an example of this process. When I make the time, I have no doubt that I can code an entire web and mobile app end-to-end, fully tested with continuous integration and deployments. My goal is to make Roxas (git commit to social media post app) as an example of a “really real” application that I built entirely myself. If I can build off of that assumption, then basically anybody can soon enough. I'm not a coding guru. I just glue systems together as a DevOps engineer.

This means that there is now a forest of low-hanging fruit available to anyone willing to pony up a new “boutique gym” type of monthly subscription and invest in themselves. On my livestreams and in the Gas Town Discord, I encourage people, especially developers, to start treating some percentage of their personal expenses like a business, because it may soon become one.

~$200/mo investing in yourself crashout (feel free to skip)

As market-y sounding as this does (since it does come from Alex Hormozi), the person you become through experience is the ultimate investment. Who are you but a collection of your experiences at the end of your life?

To get many types of experiences (that are valuable skills!), you need to pay money. If your choice is between paying tens of thousands of dollars in traditional educational degrees, seminars, masterminds, courses, books, etc, or THE RELATIVE STEAL of just $200/month for Claude Code Max 20x, let’s not cheap out on the tool of the century that enables us to build our own versions of all the other tools.

Let me crash out further, but before I do, let me preamble this by saying everyone's situation is different. It's a hard economy out there. Layoffs are real. I get it if you can’t afford anything extra right now because times are hard and you have mouths to feed. The following does not apply to you.

By continuing to read past this paragraph in this section, I assume you have $200/month to spare that would otherwise go into drinks, sports betting, crypto, a Robinhood account, or otherwise “discretionary income”, and you're willing to listen to a pitch on the “S&ME500” (yet another Alex Hormozi thing).

On the low end, for an entry-level software developer, your average yearly salary is $100K. After taxes and deductions, it's probably more like $70,000 take home. That's $5,800/month. Rough ballparking here, Claude Code Max 20x is 3.5% of your take home pay. That's 3.5% investing directly into your future. You know of at least one person with crypto allocations bigger than that.

Re-investing into your skills as a software developer enables you to make more money through your job with promotions or through a more entrepreneurial channel. At the very minimum, you will continue to stay employed and get 3-5% yearly raises if you are actively improving your Vibe Coding. There you go, it pays for itself! Don't get me started that Vibe Coding is basically a video game and it is a pretty enjoyable thing to do as a pastime WHILE YOU ARE LEARNING AND ACTIVELY IMPROVING A VALUABLE SKILL.

That is 3.5% of your post-tax income and I’m not even using the much smaller percentage pre-tax where we normally calculate these types of things, like 15% for 401k, etc (Claude Code is 2.4% for the year in that case). If you're not willing to think about this as a reinvestment in yourself for your continued education to continue to earn the other 96.5% of your income, nor willing to stay on top of relevant tech trends (possibly THE tech trend that unlocks the rest of them), you may hit a ceiling in your career and now you don't have to wonder why.

This same crashout goes for any of the many supporting subscription services like AWS or hardware that help you become better at your profession. I just went through this anguish with buying a new personal MacBook Pro at the end of 2024, and just paid it off at the end of 2025. It turned out fine. I'm writing to you on it now.

When my old machine died, I was getting serious about posting Jiu-Jitsu content (that has since turned into, well, this). I was trying to post to Instagram every day and grow my following, but my old Mac laptop from 2016 was super slow with editing on the not-even-latest version of Final Cut Pro. It eventually didn't boot back up one day, and I had to bite the bullet on a $300/month "subscription" to a new computer for 12 months [1].

Attack of the Clones

Remember how I said that there's now a forest of low-hanging fruit for anyone with $200 and some time to create an app? Everyone and their mother has the same ideas as you. If you're into Vibe Coding with agents, everyone is building their own agent orchestrator. There's dozens of them and they are going to keep coming, even though we have plenty. The other examples of these clone apps are: habit trackers, notes apps, to-do lists, or calorie trackers. We're seeing droves of these because we all spawned near the same point in this idea forest.

Literally some dude on Twitter has already launched my idea for Roxas of turning git commits into social media posts. I didn't even predict that far down the road correctly, which is what inspired this post. That’s how quickly people are moving. You can put your head down for a couple months and come out the other side with a fully baked app.

I want to try to recalibrate my predictions here because I thought I was being super sneaky with my idea but apparently other computer nerds have the same sense of putting together coding and marketing like I do to create a full stack solopreneur. I believe I was right on the idea but wrong on the timescale. I'm still going to work on Roxas for myself, just to have an example project of what I can do with Vibe Coding. I'm going to have to make some wilder and longer-term predictions for how we're all going to make money in the future.

Irresponsible Speculation, 2nd Order Effects
Given how fast I was “wrong” about the timescale of Roxas, I may have to throw some darts here and move up timelines as to how quickly various people are going to adopt Vibe Coding and when we're going to see value out of it.

Taste is ultimately going to win
The only problem with Microsoft is they just have no taste. They have absolutely no taste. And I don't mean that in a small way, I mean that in a big way, in the sense that they don't think of original ideas, and they don't bring much culture into their products.

Steve Jobs
Knowing what people want, even if they don’t know themselves, in such a way that it helps you decide what to build, is the most valuable skill now. Figuring out what people want is THE constraint to a business now post vibe coding. It may have been to some degree before, since that's why we hire PMs to try to understand the customer and their needs, but now it's basically the only skill that matters: knowing what problem to solve. People who can Vibe Code are solvers in need of a problem.

This encourages us to not be one-dimensional. There's only so many vibe coders in need of yet another Agent Orchestrator. People can only focus their attention on one or two main ones and the rest are going to be untouched in a year. If Anthropic releases an official one, it's over.

Have hobbies. Go out and do things and meet people. You're the sum of all your experiences, remember? Go have some new and diverse ones in order to find a new perspective. If you had a great idea from your current perspective, you would be building it already. (And you might. If you are, that’s cool, I’m happy for you. I’m trying to help the others here.) Since we're all nerds, doing something new is like taking the cross product of your experience matrix with a new vector that you haven't experienced before (or something like that). You get a new resulting vector that is different and orthogonal to the original two input ones. You get what I'm saying.

Point is, anything can be coded up in an afternoon. What you decide to code up is now the most important thing. That's not to say be paralyzed in fear about coding “the wrong thing” and then end up not coding anything because of analysis paralysis. It's more like we need to take deliberate shots on goal and iterate closer and closer to what the customer wants to achieve product-market fit. We want to build the less-wrong thing over time. We need to have an ability to get our product out in front of customers and have ways to find them.

Distribution is ultimately going to win
50% of engineering is doing the thing and the other half is talking about it.

Engineering Rule of Thumb
This is what I'm personally betting on. Big reveal! I've always had this thing of weirdly enjoying communicating more than the average engineer. I'm technical, but also not the engineer who likes to code and learn a new programming language on the weekends (now I do with Vibe Coding). If you're reading this, you've fallen in my trap, stay a while.

I get playing to your strengths and doubling down on what you're good at. If you're a super technical, galaxy-brain engineer, keep doing that. Just talk about it a little bit more. Trust in institutions has fallen off a cliff the last ten years, but trust in individual people, (“influencers” yuck), has never been higher. I know it's cringe to want to become a “thought leader,” but maybe it's less cringe to just be yourself and turning your thoughts into artifacts online that can be pushed out and scaled to thousands of like-minded people.

Just talking about Vibe Coding for the past six weeks has surfaced some interesting opportunities. Nothing real yet, but I'm getting more specific inbound messages than ever before. All because I'm just talking about a thing that I’m doing. It happens to be a very hot topic right now and will be for the foreseeable future, but hey, you don't get to pick what you feel called to do and wake up in the middle of the night feeling compelled to write. Strike while the iron is hot.

I'm amazed that over 50 people are subscribed to the email version of this newsletter, with maybe 3 being friends and family. There seems to be a momentum that you get when you achieve some amount of traction. You get some amount of compounding snowballing effects over time. You just have to keep going and producing “good enough” artifacts of yourself. You cannot be a perfectionist and ship nothing.

Not saying I'm even a mildly successful "thought leader" yet, but I'm much further along than I was when I started at the beginning of December 2025.

No-Coders are going to need really real apps soon
This is a 6-12 month thesis. Some small percentage of vibe coded apps are going to have a magic combination of taste, distribution, and a working product to scale at a pace that neither the app owner nor the vibe coding infra provider (Lovable, Replit, etc) that they sit on will expect. Or maybe the providers do expect it and are charging an arm and a leg margin premium on top of the AWS/GCP cloud infrastructure that they are wrapping.

Lowering Costs
This may be a good deal and even preferable to solopreneurs, but vibe coded apps with investors who look at margins are going to try to drive costs down. They know that long-term, every percentage point that they can lower on the expense side, they can either take as profit or reinvest back into the business to make it grow more.

For software engineers who are open to the idea of Vibe Coded apps, there will be a “selling pickaxes in a gold rush”-type of market opening up for consulting. And not the snarky "I'm going to clean up your slop code in six months" type of consulting, but a real "lift and shift off of Lovable and onto AWS to get our costs down and scale more” types of partnership. Hint: you get more looks at these if you talk about your skills with software engineering and vibe coding on the internet.

Software Engineering Process
Another part of Vibecoder apps hitting traction is that there are now consequences to making changes that may break things. People are paying you money and they expect to get a working product at least 99% of the time. If you truly have vibe-coded your app and don't know how it works and aren't a software developer, you need to have some idea of how to become a software development shop.

You need to learn how to implement a battle-tested process that ensures the quality of your app and gives you confidence in the changes that you make. Check out how you can assess yourself with my free Day-2 readiness audit prompt here.

If you're someone technical reading this, get your practice reps in with migrating apps from Lovable, Replit, n8n, etc. and implementing software engineering best practices for them, because a wave is coming.

“Head of AI Enablement” is an achievable job title for Vibe Coders

If you're reading this newsletter, congratulations! You're ahead of most people in terms of adopting vibe coding and AI in general as a part of your day to day workflow. Because there's so much resistance and pushback to AI “slop” code, whoever can do it the most (and therefore, the best) is going to get a fast track to increased responsibility (and compensation) to try to teach the rest of their coworkers to do the same.

Anthropic and the other AI companies don't have enough sales engineers to train all their customers on an ongoing basis to maximize the number of tokens they purchase. There have to be internal champions who take this on and translate the scant training that the model companies provide into actionable steps for their company’s internal processes for others to ramp up on.

If you're here this early AND you talk about AI at your company (writing, presenting, etc, distribution remember!), chances are you can show that you make a large impact to the company's productivity and therefore should be compensated for it. As always, no guarantees, but you can make this your job if you do it enough and are good at it.

Irresponsible Speculation, 3rd Order Effects
The following are ripple effects that are probably going to happen anyway, but I have recent personal data points to extrapolate from.

The Future of Education is Learn by Doing
This week I got asked about building a custom agent with LangChain or n8n and how to test it in a normal software development process. I embarrassingly had no idea how either agent-building technology worked.

Over the course of three hours, I built two different terminal-based LangChain RAG chat agents with Claude Code. One was a SQL agent that could query an example database with natural language. The second was a chat agent trained on a set of informational PDFs on my computer. I built both with my “plan-implement-review” Enterprise Vibe Code Method™ (jk).

It was great that they both worked right away, but what was even more magical was when I asked Claude Code, "Hey, explain how this works", Claude came back with a whole real-ass step-by-step example of how the agent:

Was trained on the PDFs, how they were chunked, how they were embedded into the ChromaDB database as 1,500 dimension vectors.

How a query relevant to the content of my PDFs would get embedded and then how it would do a cosine similarity search in the vector database.

How evals work to test my agents over time.

Claude showed me real example steps in context of what the code was going to do. Now just extrapolate this out to virtually anything else.

If I had this in chemistry class, I would probably have done a lot better. I would have sat there and played with different simulated chemical reactions and gotten an intuitive sense of how certain chemicals react together. That would have been infinitely more interesting than route memorizing facts about chemicals over time to regurgitate for the test. The intuitive sense and curiosity would have propelled me to gather more knowledge about the subject, rather than being forced to just memorize a bunch of facts for the sake of learning facts and then promptly forget them the next quarter. Same thing with a MatLab or Wolfram Alpha for Math and Physics.

Education in the traditional four-year degree sense is broken. The ROI is no longer there for most people. We're going to see a lot more individual project tinkerers who go really deep in one particular niche and will accidentally make a discovery or business because they didn't know they weren't supposed to do something. Or at the very minimum, they're motivated to go back and pursue an a la carte traditional route for this hyper-specific micro-niche that they're interested in. Institutions will adopt project-based learning and the curriculum will become much more personalized to students. At least the good ones will be.

I can also see people getting a lot of surface-level knowledge and Dunning-Kruger-ing themselves into thinking they're geniuses and go down a self-congratulatory AI-induced psychosis. We're playing with fire here, but we will adapt.

Chekhov’s Degenerate Gambling Sidebar
Not terribly AI-related, but prediction markets going mainstream seems like an incredible conflict of interest for nearly anyone who is newsworthy. This isn't just for the highest-ranking officials, but also in the future, potentially every local election has real money riding on it to be influenced, as if there wasn’t enough already.

Polymarket's goal is to “financialize everything”. Eventually every little action someone with enough newsworthy status (lower than you think) can take will eventually have a market around it. There will be meta-financial incentives for your local mayor to approve or shut down a project, the local city council to vote for or against an ordinance, etc. just based on how much money they can make on the least likely option. We're in the worst timeline.

Claude’s Prediction
If you want to read the full report, click here. Basically, I’m right / it’s nothing you haven’t heard before.

[1] Frugality Head Trash
I know what it's like to want to be frugal (read: cheap). You may have felt some material insecurity or personal exposure to the void / lack of safety nets in capitalism before, and you never want to feel that again. I’ve been there. Or you got red-pilled into the Reddit FIRE pipeline. It would seem like the “right” hyper-optimal FIRE-method-approved way you “should” feel about spending money on nice, useful things is BAD. But also feel free to rebel against it, it’s your one shot at this life. Why are you going to let anyone else who isn't in your life day-to-day tell you what to do? I've recently come around to this same idea about vacations, well that's a different post.

I had to get rid of the head trash around the “don’t spend money now, save for later” desire to retire early. “I’ll suffer and work hard for 15 years, and THEN enjoy my life”. Sorry bud, you're living your life right now and you're not enjoying it. We're not guaranteed tomorrow. It's easy to optimize and simply maximize a certain aspect of your life, but that's not a common experience for most people. We need to juggle piloting and reassembling this plane while it's flying.

The reality is that FIRE works for very few people with certain personality dispositions AND leave the workforce mentally and physically healthy enough to enjoy their well-earned, saved, and invested money. It's a self-selecting, self-rewarding type of thing.

It's sort of like not everyone is meant to do Jiu Jitsu even though I feel like everyone would, on paper, benefit in some way. Since money a thing that everyone has to care about, we just feel like we "should" operate a certain way because we're engineers, we like logical arguments, we like math, and we like to see optimal things go up and to the right.

You're only going to be this young once. The book "Die With Zero" by Bill Perkins has more ideas about how to spend your money optimizing for experiences rather than total dollar amount at the end of your life. TL;DR because I didn't even read the book, I just listened to him on some podcasts: take that European walking tour vacation now rather than when you’re 60 with mobility and energy issues, enjoy that nice dinner with your partner, think about giving your kids a down payment for a house when they’re 30 vs. an inheritance when they’re 60. I'm just going to extend his thinking and invest in yourself by giving yourself experiences of building stuff with relatively inexpensive tools now that can be incredibly valuable later.

I really didn't want to add another monthly payment for the laptop I ended up buying, but it was the only way I could pursue this creative project that meant a lot to me, and I felt like I needed to try it out and see it through at that point in my life. My wife encouraged me to invest in myself, since I was committed to doing all of that editing work anyways. There was no way around getting a new computer that did what I needed it to do, as fast as I needed to do it. $300/mo for 12 months was the prerequisite for me to invest in the S&ME500, and I am grateful for it.

By continuing to invest in the S&ME500, I’m already seeing traction by virtue of the fact that you're reading this, likely a complete stranger who found me yapping about Vibe Coding on the internet. Thank you.

Agile for Agents

Mike Lady — Sun, 11 Jan 2026 19:47:19 +0000

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!

10 hours with Gas Town (out of a possible 48)

Mike Lady — Sun, 04 Jan 2026 22:03:31 +0000

I am now paying $200/mo for Claude Code and that is a steal, or: how programming is ruined for me.

Figure 1: What Piloting Gas Town Feels like, based on “Figure 1: Welcome to Gas Town”

Steve Yegge dropped this article on us on the 1st of the year. It is, at the very minimum, a wild introduction to his new coding agent orchestration framework. 48 hours later, I am now paying $200/month for Claude code. 💸 💸 💸

He teased that this framework was coming out sometime in December, but I honestly had forgotten about it until I got the email notification from Medium for his blog. As soon as I saw it in my inbox, I was hooked. Rereading it again after using it in 10 of the last 48 hours, what he describes in the intro makes much more sense.

I will try to simplify, summarize, and just put in different words the most important bits from my experience going from newbie only generating 5 PRs in my first three hours to creating 36 PRs in my last four hours of using it.

Of course, don't take my word for it. PRs can be of various sizes and shapes. Lines of code is the worst metric to grade software developers on. Maybe to give a better sense, I was working on three to four different modules of my system (and Gas Town itself) at the same time! Within those modules, there were multiple workers (“Polecats”) sometimes working in parallel, depending on the Beads (lightweight agent issue tracker) that got planned.

"I gotta feeling / That tonight's gonna be a good night”

The Black Eyed Peas
The Feeling
Let me lead with how using Gas Town feels. As humans, our best tools become thoughtless extensions of ourselves. We put our shoes on at the beginning of the day, walk around all day, and forget that they are even on. We drive our cars, zone out, and become one with the flow of traffic. We pull out the pizza roller or ice cream scooper on Friday nights after a long work week, and they “just work” to deliver deliciousness and comfort.

Gas Town feels like these tools. It feels like all of the friction has been taken out of managing multiple agents. Dare I say all of the friction has been taken out of programming! The wind is fully in the sails of developing software.

Gas Town completely empties your queue of things that you want to do. You can just offload any little task you can think of into the orchestrator agent (aka “The Mayor”) and it figures out the planning, implementing, testing, and merging of all that work for you.

The focus is throughput: creation and correction at the speed of thought.

Steve Yegge
You will run out of things to ask it to do and feel embarrassed. Your creativity and ability to track work in parallel will be challenged. The steady, patient, ever present hum of “The Refinery” merging your work into your project repo (or “rig” in gt parlance) main branches will leave you in awe.

You will be more excited to accomplish whatever you want with Vibe Coding in any language that you want. The only limit is how much you’re willing to spend on Claude Code tokens.

The Reality
You will become bloodthirsty for tokens. There are not enough tokens in the world to satisfy all of the things you want your agents to do now that the pain of managing them has been dulled to a sufficient degree.

Yes, “dulled”. There is still some pain, but not nearly as bad as it was with manually resizing terminals and cursing your lack of screen real estate. You also won’t have to worry as much about bringing Agent context up to speed in project, managing git worktrees, nor caring about how close an Agent is to the end of its context window. That sharp pain is now replaced with a new, easier kind of friction that is much more tolerable.

The friction, aka, your job is to keep your Agents busy and unblocked. Or as I said on my most recent livestream, “keep your Tamagotchi alive”. We are all now managers of agents, as Steve Yegge and Gene Kim have mentioned this before in their book, Vibe Coding, but my experience with Gas Town really nails the point home.

You are now the manager of all the agents that you can keep track of and fit in your Claude Code subscription. Your management “span of control” is directly correlated to your attention span and memory. People are working on visualizations for the ongoing units of work called “Convoys”, but as of the first version you have to run a specific command over time to be reminded of all the work that is still outstanding or potentially even unaccounted for.

Author’s Note: While writing this newsletter, I became an official contributor to gastown from my instance running in the background. It added an HTML report for Convoys while the preceding paragraph was being written about them. This is the power of Gas Town.

Since we are now more managers and less developers, we get to think about big picture ideas more and invest in the infrastructure to enable those ideas to happen autonomously. Very much like technical or even product managers, we suddenly have to be all about systems and processes.

For me, as a Senior DevOps Engineer, this is basically a dream come true. I've always felt that given an intense enough pipeline, cranked up to 11, we can ensure quality to the degree that developers feel like maintaining it.

Now your developers don't feel.

They don't complain. They get “slung” beads (“slinging” is the technical term for assigning work), and immediately start on the work and do as they are told. As long as Tmux hits “Enter” on the Claude prompt and doesn't get stuck [1].

Basic Workflow
After following the Quick Start Guide, you may think you’re going to run a bunch of gt commands all over the place. You’d be mistaken. Once you attach to the Mayor and are in its Claude TUI, you can ask something like the following phrases in plain english (these happen to be mine, but feel free to use your own):

Work Management

"show convoys" / "show status"
"what's blocked" / "what's ready"
"check on [polecat]"

Polecat Management

when things get stuck: "nudge polecats" / "nudge all workers" / "nudge everything"
"restart all"
"clean up polecats"

Work Dispatch

"sling X (description of what you want done) to a polecat" - assign tasks to polecats
"create convoy for X (full description of work to be done)" - batch related work
"sling all available beads"

PR/Code Work

"please fix [PR URL]"
"run code review on [PR]"
"address comments on [PR]"
"merge all X PRs into one"

Infrastructure

"upgrade gastown"
"run dashboard"

Planning

"use shiny formula to plan X"
"copy formulas from X to Y"

Meta/Documentation

"how many PRs today?"
"give me a workflow document"
"what are the typical commands?" You can “jump out” from the Claude terminal control to the tmux bottom status line with Ctrl+b

Once you’re on the tmux bottom status line, you can view the various tmux instances with just s, (so the whole command is Ctrl+b lift up finger from control, type s) and then use your arrow keys to move up and down, and hit enter to jump into another Claude tmux instance (that has a different role). You can hit esc in the s window to go back to your current tmux window.

You can use Ctrl+d to detach from the tmux session to go back to your normal terminal.

Final Thoughts from the first 48 hours
I feel like I'm staring into the future by using this now mostly voice-activated method of programming since I'm using Wispr Flow. Yet, it is here today and I never have to go back to any prior form of programming, save for some probably really weird stuff.

The magic in Gas Town is Claude managing other instances of Claude via tmux, along with other orchestration wizardry that is similar to Kubernetes. Hopefully soon in the near future, we can use other types of coding Agents to manage even more different Agents using this framework.

I think the dirty little secret that the frontier model companies don't want you to think about is that life is better for the end consumer if we have access to multiple models. We get different perspectives on reviewing plans, PR reviews, and even choosing between different generated implementations. I don't believe there's going to be one model to rule them all and that's fine by me.

We benefit from treating these agents as if they're peer developers to get their perspectives. We can use those perspectives to triangulate a viable solution space to implement. Just like how companies don’t just hire "the one best developer” (because there isn't), we have teams of developers with their specialties, strengths, and weaknesses. Our strengths add up to greater than the sum of their parts, while our systems and processes cover over the holes left by our weaknesses.

My thesis behind Enterprise Vibe Code

Enterprise Vibe Code
Humans + Agents are a team within a team of other Humans + Agents. The end goal (at a job) is to produce more business value than what they pay you. It doesn't matter if a Human or an AI wrote the code. If we have a strong process that transforms the unreliable inputs on the left (humans aren’t infallible, remember) into a reliable output (another Yegge-ism), we will have a successful business.

Subscribe to the free weekly newsletter at https://www.enterprisevibecode.com/

[1] Which is depressingly often where you give The Mayor the command to Sling and then you get distracted and move on to a different Convoy. You remember you slung it 30 minutes later, and you ask the mayor to remind you which Polecat that work went to and then use tmux to manually check and find the prompt sitting there in the Claude terminal unsubmitted. Then you have to curse the Mayor out for not starting it. The same also applies when Claude agents don't get started up in YOLO mode and they get stuck on the first permission check.