Haves Versus Have Nots

October 29, 2026

I think we are seeing a large gap in software development right now. We are seeing people who have effectively unlimited token usage and those who (either organizationally or personally) don’t.

Why Does That Matter?

I always have a great conversation or two at the Omaha .NET User Group. This talk was by Matt Ruwe, discussing how he used Spec Kit to build his mowing service application to help manage clients, workers, payments, etc. when it comes to mowing lawns. Matt was able to build an application from the ground up using Copilot and Claude instead of paying $500-$600 per month on a mowing management tool.

One-Off Example or the New Trend?

I think what we are seeing is people who are comfortable with AI are now able to build applications quickly that solve problems for their exact use case. For example, I built a website my wife uses for her floral workflow management that runs under the amount of Azure credits I get per month, so it’s basically free*. Why do I think this is haves versus have nots? I’ve been busy professionally coaching teams on how to be more agentic, and I’ve seen firsthand what you can do with basically unlimited Copilot tokens that we all lost.

The Haves

Let me set the scene for you of what it looks like to have essentially unlimited tokens. I can log in for the day and ask my own AI agent what I am supposed to do today or where we left off. That agent can call out to summarize my tickets to do, the work we did yesterday, any meetings that had transcripts, chats I had, etc. I get a concise list of what I need to do today. Once I know that list, I can delegate work to different agents, review stories I need to work on, work with AI to develop plans for those, have AI start implementing the stories, and review code. Each person on the team has their own unique skills, ways of working with agents, and ways to improve their workflows to be much more productive members of the team. When coaching, we’ve seen throughput increases as high as 80%+, if not more. At clients where we can help with product direction too, we see even more: we are able to feed the machine and get features out that make the company money or save the company money.

Why Does This Matter?

I was personally super lucky that people took a chance on me learning AI. I was one of the early folks and one of the first 50 Microsoft MVPs in the AI designation in the United States. When I tell you that in this not-great job market I have 2-3 jobs people want me to apply for that are $140k-$180k on average, I’m not joking. There is such a massive demand for people working with AI, and it pays better than most roles in my metro in Omaha. Shout out to Buildertrend, they pay upwards of $200k for forward deployed engineers.

What I am seeing is that developers who embrace AI are delivering more value to organizations, and since AI is a multiplier, they keep improving at a rate non-AI engineers have zero chance of keeping up with. So you have developers who make more money, are more in demand, and return more on the investment of their salary than other engineers. In most cases it’s for a cost of $1,500 per year. We used to pay $5k just to let developers have Visual Studio Enterprise, and that was before inflation. So for waaaaaay less money, I get a developer who (once trained) is on average able to be 80% more productive in a worst case. Imagine how much more you can get done if everyone moved that much quicker, at a higher quality.

I had one user group attendee tell me they used to tell the business every request was 9 months and 1 million dollars. Now they are building more for the company on a much smaller timeline. Even if frontier models raise prices, open source models are really great now too. Developers are moving back to what they were originally brought in for: solving problems!

So to summarize: 80%+ more work is being done, more problems are now viable to solve, and we can solve problems that before were not really solvable. Now let’s contrast that with the two types of have nots: the one who chooses not to use AI and the one who can’t.

The Have Nots

The easiest one to start with is the have not by choice. They may have AI tooling around but choose not to use it. That can be because their work is too important for AI, too complex, or they just like writing the code. I think all of those are flawed thinking. It’s like saying why learn higher-level programming languages when C gets the job done, or why learn web development, it’s just a fad?

In reality, people quickly start to notice. Tasks with those individuals start grinding to a halt, and if you are on a team, you start being the person holding up epics. If you work solo on important tasks, eventually the business will ask why one person can deliver something super fast, but when they work with the person who refuses AI, progress drops back to the pre-AI rate at best. That now feels like a snail crawling in comparison to everyone else. The gap between the AI-powered engineer with solid development practices and the non-AI engineer with good dev practices opens at a multiple that’s hard to ignore. It’s not hard to see how you can eventually lose responsibilities and possibly even your job.

My Company Won’t Let Me

This section is a little more nuanced. Your company may have bought Copilot, and it was amazing while credits were flowing, but now they have restricted budgets to the point where you can’t do most things you were doing before. You carry a huge mental load rationing a small amount of credits, plus the stress of when to use it versus not. The other kind of firm is one that is too afraid of using AI tooling for one reason or another.

Both of those cases are ones I really empathize with, because in a competitive market those people are being left behind. Other engineers are figuring out how to be more productive, deliver more features, and will cut into the market share of the slower-moving companies. Not to be too doom and gloom, but as market share shrinks and CEO bonuses are on the line, that usually means employees across the org sadly get laid off. Will this happen in weeks? Probably not. However, when competitors are able to experiment and deliver 80% faster, if not quicker, how do you continue to be competitive?

Summary

The gap between the haves and the have nots isn’t about talent. It’s about access and willingness. On one side are engineers with the tokens, the training, and the freedom to experiment. They’re shipping more, solving problems that weren’t worth solving a year ago, and becoming more valuable every month. On the other side are engineers who either chose to sit this out or work somewhere that made the choice for them.

What worries me is that this gap compounds. Every month an AI-enabled developer spends refining their workflows, building their own agents, and learning what works puts them further ahead. It’s not a one-time jump in productivity, it’s a multiple that keeps growing.

So here’s my ask, depending on where you sit:

AI isn’t replacing developers. It’s letting us get back to what we were hired to do in the first place: solve problems. The question is which side of the gap you want to be on when your competitors figure that out.