My Big Bet

Somewhere around 1990, I bought a computer I couldn't afford.

My wife was not so quietly angry, and the only thing I could think to tell her was, "I want to go back to school and work on my master's degree."

There was no real thought there. It was literally just a spur-of-the-moment response to somebody who can really get angry.

I waltzed on down to Regis University in Denver, applied, and was accepted into a master's program in Information Systems. I spent the next few years learning how to manage—and also develop—software.

PowerBuilder was a huge product at that time. You built the forms in a database, and they were nicely tied together. I learned to develop in it, but I also learned the managerial side of software development. Although I developed for the rest of my life, I had to dabble in almost all of it. The program was definitely worth the time and money.

I took my master's degree and my ability to do PowerBuilder and never touched PowerBuilder again.

I started coding in VB, which eventually led to C# and SQL Server, and doing what would now be called full-stack development. I did it for one very good reason: I worked at companies that needed entire applications built for them.

There were several of us at every company I worked at who built one or more applications at any one time, specifically designed for that company. We designed the database, tied it to the front end with various libraries—what would now be called ORMs—built the front end, tested with the users, deployed when it was "acceptable," and moved on to the next one.

Then, in what seems like a very quick two-step, the internet forced most of us to stop writing desktop apps and start writing browser-based apps. First, they were private applications for the company. Then they became public-facing websites.

Almost immediately after that, at least the way it seems to me, SaaS took over.

Individual company developers moved to SaaS companies, or became the one-, two-, or three-person groups that had to tie company data to SaaS solutions. This is very high-level. There is a lot more detail here, but you can see the direction of what I'm trying to say.

Over the past decade, private companies working with SaaS solutions became accustomed to either tweaking their processes to work with a SaaS solution or having multiple SaaS solutions to get the coverage they needed.

What we never really thought about at the time was that companies were losing their ability to think about software as something they could build for themselves. There was really no concept of building your own software. It became something companies were losing the ability to do.

In my experience, development groups at larger companies spent a bulk of their time dealing with ERP solutions and connecting systems together.

I made a very good living during this time. I am not begrudging the state of our industry. I managed to find a very, very good company, Lubetech, and built their e-commerce platform several times with progressively more modern frameworks. I was very good at it, and they were really good to me.

Upon semi-retirement, I continued to support that e-commerce platform while they moved to a SaaS solution. Yes, I see the humor here.

There is still a lot of effort being made to tie that large SaaS solution to abilities I was able to build fairly simply. Lubetech had a lot of exceptions that are difficult for SaaS solutions to cover, but they are doing an admirable job of closing the gaps.

While I was maintaining that site, I started exploring AI development. I followed the typical path: code enhancement and some code generation. The coding harnesses were just beginning. I built agents and front ends for agents. I started exploring LangGraph and more complex agents and workflows.

I started building a product I called OrchestratorAI so I could explore the facets of using AI in my development and of building an AI framework for small and midsize companies.

It was a place where people could build agents, build workflows, add authentication, add separate organizations, build RAG collections, and view them. Anything that came up as a research or growth topic, I implemented in OrchestratorAI.

I left it open source. I never really cared to market it. It is comprehensive. There is agent-to-agent communication, and there is just lots of stuff. I may come back to it later.

But what matters for this story is that there were several iterations as I discovered newer and better ways to use agents and combinations of agents.

What I noticed was that I was flying.

I started building libraries of skills, sub-agents, and memory files. I developed skills to help make sure my code stayed on track, that I followed my PR requirements, and that I could catch the moments when my coding harness—Claude Code, Codex, or Cursor—was going to try and do something psychotic.

I mostly caught it before commit. The few times I did not, I built a hardening process that goes around, finds issues like that, and fixes them.

What this did was allow me to find a seriously accelerated rhythm.

Most mornings, I have two or three coding environments up, working on one of several coding projects. Most of them are public in my GitHub if you want to look. I build by effort. I have a directory of efforts: Current, Archived, Next, and Future.

If an effort is in Current, I build an intention file, and then off we go. We build a PRD, a plan, and I keep an eye on it as it builds. I certainly do a lot of testing.

With in-browser, in-app browsers, you can have the coding environment test before you even have to go look and test it yourself. It is doing a seriously better job than it was even last month. If you are reading this three months from now, you will probably be taking this for granted.

That brings me to my big bet.

My Big Bet

I think a lot of coding environments and development groups are going to use these tools the way they have used every development improvement over the last 15 years. IDEs get better, Git gets easier, form development gets easier, and we become more productive.

That is the pace we are comfortable with.

My big bet is that it is not going to play out that way for much longer.

There will still be companies that are perfectly happy to use AI as another acceleration tool. But small, midsize, and eventually large companies are going to recognize that they can build software for themselves again.

They are going to look at their backlog and realize they can knock much of it off in a couple of weeks. They will look at SaaS solutions they have bent their processes around and ask whether they can build something that actually works the way they work.

That does not mean every company should rewrite every SaaS product. It does mean they will have a real choice again.

Some will reduce SaaS dependencies. Some will replace a narrow part of a SaaS solution that never quite fit. Some may eventually take on pieces of their ERP dependencies, although that is more of a stretch right now.

More importantly, after the backlog is gone, companies will start asking better questions: "What can we do now? What really cool thing can we do that we have never been able to do?"

They can spend a couple of days thinking about what they really want, writing down the intention, setting the guardrails, deciding how to test it, and then letting it rip.

You can watch it build. I watch it build. The changes are super fast.

That is the real opportunity: companies being able to build applications that increase business opportunity instead of spending all their energy fitting themselves into software someone else built for the middle of the road.

Your Big Bet

If my big bet is that companies are going to start building more software for themselves, then your big bet is to take this on.

There is a real upside to moving to an AI-centered development process. You can get through backlogs faster. You can build things that have been sitting on somebody's "wouldn't it be nice" list for years. You can build software around the way your company actually works instead of trying to make your company fit the way a SaaS product works.

But the other side is that it takes work.

You do not just buy a coding harness, pick an LLM, write a few guidelines, and walk away. You have to maintain the process. You have to maintain context at the company level, organization level, group level, and project level.

You have to decide which providers and models you work with. Some of that may be contractual. You have to test what gets built and decide what is important enough to keep a human involved.

And the ground is going to keep moving.

The models will become more capable. The harnesses will become more capable. New processes will show up. As that capability changes, you will be able to move more of your people out of the repetitive development loop and into finding, defining, and building the next growth opportunities for your company.

But that does not mean you can move responsibility out of the loop.

Somebody still has to understand the business. Somebody still has to understand enough about data, code, frameworks, and testing to know whether the thing being built is the thing the company needs.

This is not for the faint of heart. It requires a company to be involved in development again. It requires people who can make decisions, set guardrails, test the results, and keep changing the process as the technology changes.

That will involve growing pains. A lot of companies will put it off because it sounds like more work, and it is more work.

But a company can get started. It can put together a development process that is an immediate, or close-to-immediate, improvement. Then it can keep improving as the models and harnesses improve.

Companies are also going to need developers trained to work this way. People who know how to use AI development tools but who also understand the basics: data sets, arrays, lists, dictionaries, front-end frameworks, APIs, testing, and how all of it fits together.

They do not need to become experts in every framework before they can be useful. But they do need to be diligent. They need enough understanding to ask good questions, recognize when something is wrong, and help keep the work moving in the right direction.

That creates room for people early in their careers, people who are newly trained, and people who may not have followed the traditional development path.

An Even Bigger Bet

Part of my bullish view of AI development, software development, and AI in general is that we have limited ourselves to a pretty small set of problems because those are the problems our tools let us fix.

We balance spreadsheets. We do logistics. We build companies around ERPs. We connect systems. We make the existing process a little better.

That has all been useful. It has built a lot of businesses. But it has also limited where we put our time and energy.

With these new tools—and with people seriously thinking about how to use them—we can start working on bigger things.

We can help researchers find better ways to treat disease. We can work toward better energy solutions. We can improve manufacturing. We can help make space more accessible. We can improve quality of life. We can build businesses around passions that were never practical before.

We can also get better context with each other.

Personal assistants are a good example. A CEO has always had an assistant who knows how they work, keeps track of what matters, handles the drudgery, and helps them stay focused. We may all be able to have something like that—an assistant that knows us well enough to help us live and work better.

That is what excites me.

It is not just that we will build software faster. It is that we will have more people, more time, and more capability to work on the things we have not been able to work on before.

That's my big bet.