I should probably admit something before I irritate my developer friends. I am not a developer. I have held a lot of jobs, titles, and positions over the years and pretended to wear even more hats. But sit me down and ask me to write Python, or really any code, and we need to go all the way back to high school. There is a reason for that.
So I waited until Friday on a short holiday week to ask this. It may piss off some of my developer friends, and I wanted to give them the weekend to get over it. To be extra-double-careful, I am framing it as a question, not a prediction.
Today I was talking with a buddy about how some technology companies may not survive what is coming. He asked a simple enough question. How does company X survive when someone can ask Claude to build its product? There are obvious answers. Copyright and patent law may object, depending on what gets built and how. Corporate lawyers certainly will. The company may have proprietary data, years of accumulated knowledge, integrations, support, trust, and people who have already found the edge cases nobody else knows exist.
Scale is another obvious issue. The thing Claude builds for me may work beautifully with one user and fall over when the second one arrives. But I kept dwelling on that and out popped another question: If the application is built for me, why does it need to support a million people? The software company had to create one product flexible enough for thousands of customers with slightly different needs. I only need AI to build the particular version that shapes itself around what I need. It does not need to replace Salesforce. It may only need to replace the small part of Salesforce I was paying for and actually using.
That conversation led me to yet another question. Let us say two people decide to build the same SaaS application. What it does is not relevant to the thought experiment. Let’s just assume there is a real need for it.
The first developer uses AI, but still builds in a fairly conventional way. She designs the architecture, understands the code, reviews what the model contributes, and produces her first usable version in 30 days. The second developer completely vibe codes his application. He barely looks at the code and certainly does not pretend to understand all of it. Instead, he explains what he wants, lets the machine produce most of it, asks the LLM to fix whatever is obviously broken, and has something working in three days.
Let us make this easy on my developer friends. His code is bad. It has security holes. Things break. Parts of the architecture make no sense. The documentation is mostly written for the next model, not the next human. Nobody looking through the repository would call it a well-engineered system. On day three, I know which codebase I would rather inherit. Or at least I think I do.
The real question is what happens on day 30.
The vibe-coded application has had a 27-day head start. How far has it progressed during that time? The developer may have spent those days blindly adding features until the original mess became a much larger mess. That is entirely possible, and I know from experience! But what if he used those days to put the application in front of people? What if he watched where it broke, learned what users actually wanted, threw away the first architecture, especially because it was “cheap” to make, and built it again? What if he ran static analysis against the code and dynamic tests against the application while it was running? SAST and DAST, if we want the acronyms. I may not be a developer, but security acronyms I can do. What if he added unit and integration tests, fixed what all of those tools found, and then did it all again?
None of those tools makes an application secure. Static analysis can catch insecure patterns in the code. Dynamic testing can attack the running application from outside. Dependency scanning can flag a known vulnerable package. All useful. But the tools do not know what the application was supposed to protect. They can still miss a conceptually broken authorization model. They may not notice that one customer can see another customer’s data, or that the system performs an action the developer did not anticipate and the user should never have been able to request. Someone still has to understand what must remain true.
But 27 days is a great deal of time when an iteration takes hours. By the time the first developer finishes a carefully built v1, the vibe coder may be on version twelve. It may still be questionable code, but it may also contain 27 days of contact with actual users, actual failures, and actual evidence.
Or he may be sitting on a pile of twelve broken applications.
And that is the part I keep circling. Speed is not learning. If every failure becomes another prompt without anyone stopping to understand what happened, AI simply helps us make the same mistake faster and in more places. The advantage only appears when someone turns failure into evidence.
This gets even more uncomfortable when I put my cybersecurity hat back on. The carefully written application will have vulnerabilities too. Fewer, perhaps. Different ones, probably. But the number will not be zero. AI systems are already finding and patching real vulnerabilities. What happens as both discovery and repair begin moving at the speed of AI? Does the ability to find and fix vulnerabilities quickly become as important as preventing them in the first place? I can hear some of my security friends sharpening their keyboards.
I am not suggesting that we accept vulnerable and flaky software because a model can produce patches quickly. “We will fix it later” has created enough disasters without giving it an accelerator. I also do not want every application I depend on to feel like an experiment being rebuilt underneath me from click to click. Maybe the change is subtler. We stop pretending that quality and security can be established once, immediately before release. We begin treating the speed and reliability of the repair loop as part of the application itself.
How quickly does the team discover that something is wrong? How much damage can happen before it notices? Can the system contain the failure and roll back cleanly? Does a human understand the important boundaries well enough to recognize when the machine produced something technically functional but conceptually false? The code still matters. The loop around the code may matter more than it used to.
I keep coming back to another part of that original conversation. I think there may be a new kind of entrepreneur emerging here. The AI entrepreneur. I do not mean that anyone with an LLM instantly becomes a software company. Anyone can generate code. Finding a real problem, understanding the people who have it, recognizing when the machine is wrong, and getting something useful into their hands still requires a human. The model can keep typing long after it should have stopped.
But one person with domain knowledge, judgment, and a capable model can now attempt work that recently required a small startup. In some cases, that person may even outrun a large company that simply cannot move at the same speed. Large companies are not slow because everyone inside them is stupid. They have customers, old systems, security reviews, legal obligations, roadmaps, internal politics, and products they cannot casually break. Those constraints are often there for good reasons. The AI entrepreneur begins with almost none of them.
The other part I keep thinking about is how quickly and cheaply that person can fail. The first application can be terrible. Fine. It took three days. Throw it away. Keep what was learned. Change the architecture, test another assumption, and try again. The code may be disposable even when the learning is not.
Of course, failure is only cheap while it is contained. A broken prototype on my laptop is cheap. A broken healthcare application exposing patient data is not. Neither is a financial system making real trades or a security tool taking action inside someone else’s network. That is where the cheap part ends. The AI entrepreneur still has to make smaller bets, constrain the consequences, and learn before each experiment becomes a company-sized commitment.
And now the economics look different. The first version no longer has to justify months of payroll and a meaningful piece of the company’s runway. It can simply answer a question. Did anyone want this? Did the interaction make sense? Was the architecture wrong? What did we learn? Maybe that is the real 27-day head start. The first application is not better. It is just the first of many attempts that can happen before someone else finishes one.
So what does the established software company sell in that world? Maybe it sells trust. Maybe the proprietary data matters more than the interface around it. Maybe customers are paying for integrations, support, compliance, institutional knowledge, or someone willing to answer the phone when the strange edge case arrives at two in the morning. Those are real things. I am not suggesting that every SaaS company disappears because someone wrote a run-on-sentence, best-prompt-ever on Tuesday afternoon.
But “our product took years to build” is beginning to sound less like a moat and more like a warning about how long it may take to change.
The comfortable cliché is that none of this will happen today. This is a tomorrow problem. Lately, I am not so sure how far away that tomorrow is anymore. In my last article, I named the models I was using and joked that doing so dated the article. That is precisely the point. Remember Moore’s Law? It gave us a rough clock for computing progress. AI has scaling laws, but no equally tidy clock. The capabilities move before we have finished deciding what the current ones mean.
Every release changes what one person can build, how quickly they can build it, and how much of the unfinished work the machine can carry.
So what does tomorrow bring?
I do not know which companies disappear. I am not even sure disappearance is the most interesting outcome. Maybe a product becomes a service. Maybe the company survives because what it really owns is trusted data and operating knowledge. Some software may become temporary, generated for one need and discarded when that need changes. I do know that comparing the code on day three does not tell me very much about what exists on day 30.
One developer arrives with a carefully built v1. The other may arrive with a questionable v12 and 27 days of evidence. What I can say is that I work at a cybersecurity vendor, and I do not expect the work I am doing twelve months from now to look exactly the same, even if the title does. I have been trying on “AI Coordinator,” although I am kind of loving “Human-to-AI Translation Monkey.”
But I digress. Go enjoy your weekend while the models have left us enough electricity to do it.
These views are my own and do not represent my employer. AI was only slightly harmed in the production of this article.