Claude Code and Claude Opus 4.5 have poured fuel on the hype. LLM tools existed before, but they’re better than ever now, so a lot more people are paying attention. But we’re not entering a golden age of SaaS. We’re entering an era of personal, disposable software—where engineering shifts from writing code to shaping systems, and engineers are still required for exactly that reason.

The Shift in Modern Development

Claude Code is taking over my feed right now, and for good reason. What’s interesting isn’t just that developers are jumping on it—it’s that "builders" and makers who previously relied on platforms like Lovable or Replit are migrating to it.

Don’t get me wrong, those tools are still perfectly viable for shipping fast. But we’re seeing a clear shift as people rediscover the inherent beauty of a CLI-first workflow. When you move the interaction into the terminal, the abstraction layer thins out. You aren’t just following a managed UI’s happy path; you’re the one in control.

---

The collapse of the barrier to entry

What are people actually building with these tools? If you look around, the answer is: almost everything. In fact, we’ve reached a point of saturation. On one hand, we are witnessing the true democratisation of software creation. The barrier to entry has effectively collapsed. For the first time, non-developers aren’t just consumers of software - they are the architects of their own tools.

In the past, if you had a specific problem, you’d spend hours searching for a SaaS product that solved 80% of it. Today, the workflow has shifted. People are opening a CLI or a voice interface and simply describing what they need. We’re seeing a surge in "personal software":

• A subscription tracker tailored to a specific budget style
• A Chrome extension that solves one very niche data entry problem
• A fitness app with an interface exactly how the user wants it

This is a massive shift. Software is becoming a personal utility you generate, rather than a commodity you buy.

From SaaS to Scratchpads

We’re entering a new era of software development where the goal isn’t always longevity. For years, the industry has been obsessed with building "platforms" and "ecosystems," but the tide is shifting toward something more ephemeral. We’re moving from SaaS to scratchpads.

A lot of this new software isn’t meant to live forever. In fact, it’s the opposite. People are increasingly building tools to solve a single, specific problem exactly once—and then discarding them. It is software as a disposable utility, designed for the immediate "now" rather than the distant "later."

What makes this viable today is a specific technical philosophy: CLI-first interfaces, local data, and zero onboarding. When you remove the friction of signing up, configuring a database, or navigating a complex UI, the cost of creating a tool drops so low that "temporary" becomes a feature, not a bug. If it takes five minutes to spin up a custom solution for a one-off task, you don’t need it to persist.

The contrast with the traditional SaaS model is stark. SaaS is inherently built to optimize for retention, lock-in, and expansion. It’s a business model designed to keep you inside the ecosystem and growing your footprint. Bespoke tools, on the other hand, optimize for immediacy and control. They don’t care about your lifetime value as a customer; they only care about solving the task at hand.

In many ways, this is a return to how spreadsheets were originally used. You didn’t open a spreadsheet to build a permanent, multi-year database; you used it as a scratchpad to reason through a problem, calculate the results, and move on.

In this new landscape, Claude Code is Excel for developers—a powerful, flexible utility for solving immediate problems—rather than Shopify for founders, which is built to be a permanent foundation for a business. It’s about getting the job done, and then letting the tool go.

This also explains why the next part matters: generating software quickly is one thing; making it survive contact with the real world is another.

Code Is Cheap. Software Is Still Expensive.

Here is the reality of the current "AI-native" era: code has become cheap, but software remains incredibly expensive.

LLMs have effectively killed the cost of generating lines of code, but they haven’t touched the cost of truly understanding a problem. We’re seeing a flood of "apps built in a weekend," but most of these are just thin wrappers around basic CRUD operations and third-party APIs. They look impressive in a Twitter demo, but they often crumble the moment they hit the friction of the real world.

The real cost of software isn’t the initial write; it’s the maintenance, the edge cases, the mounting UX debt, and the complexities of data ownership. These "fast" solutions are brittle.

The subscription tracker breaks the moment a bank changes its CSV export format. The Chrome extension dies the second a target website’s DOM shifts. The fitness app becomes unusable as soon as a user needs robust offline support or reliable data sync.

Lately, I’ve seen plenty of doomsaying on Hacker News, Reddit, and Twitter about "the end of software engineering." This misses the point entirely. We aren’t witnessing the end of the profession; we’re entering a new era of it.

The value of an engineer is shifting away from the "how" of syntax and toward the "what" and "why" of systems. Real engineering lies in the abstractions and the architecture. It’s about knowing how to structure a system that lasts, understanding why a specific rate-limiting strategy is necessary, knowing how to manage a distributed cache, and knowing exactly where not to store your environment variables.

AI often feels powerful because it hides the complexity, but as an engineer, your job is to manage that complexity, not ignore it. The tools have changed, but the fundamental requirement for engineering rigour has never been higher.

The distribution illusion

But there is a flip side. With the barrier to entry gone, the noise level has reached an all-time high. My feeds are currently flooded with "AI entrepreneurs" claiming five-figure monthly recurring revenue (MRR) for apps they built in an afternoon.

In many cases, these claims are highly suspect. When you see a creator with no existing distribution and no clear "moat" claiming $10,000 in MRR on a weekend project, it’s usually a play for engagement rather than a reflection of business reality.

Some of these stories are almost certainly true but in most cases, these aren’t actually blueprints for technical innovation. They are marketing case studies. These individuals succeed because they have mastered the art of capturing attention in a crowded landscape, not just because they have an AI co-pilot.

We’ve entered an era where the ability to generate code is no longer the bottleneck. The real challenge has shifted to distribution and, more importantly, distinguishing the genuine utility from the "get-rich-quick" posturing that has become so prevalent in the industry.

These people haven’t stumbled upon a secret shortcut; they have simply found a way to execute their existing advantages faster (and potentially unlocked it in the first place if learning to code was rightfully too big of an undertaking for a side project idea).

There is a useful framing for this shift: AI has effectively removed engineering leverage as a primary differentiator. When any developer can use an LLM to build and deploy a complex feature in a fraction of the time it used to take, the ability to write code is no longer the competitive advantage it once was. It is no longer enough to just be a "builder."

Instead, success now hinges on factors that are much harder to automate. Taste, timing, and deep, intuitive understanding of your audience matter more than ever. You can generate a product in a weekend, but that is worthless if you are building the wrong thing or launching it to a room full of people who aren’t listening.

In this new environment, the code has become the easy part. The hard part remains exactly what it has always been: finding a way to get people to care.

Who wins

First, you have domain experts who are stuck with boring, repetitive problems. Then there are the internal teams building throwaway tooling, the kind of scripts and internal apps that need to work immediately rather than look perfect. Power users also see a massive gain here, particularly when they are looking to replace brittle, manual workflows with something more robust. Finally, it is a win for those engineers who prioritise ownership of the solution over high-gloss polish.

And yes — tools like Claude Opus 4.5, Claude Code, and Cursor are genuinely useful for engineers. They are remarkably good at removing boilerplate, implementing features, and writing unit tests. One of my favourite use cases lately, especially since starting a new job, is generating personalised documentation and walkthroughs of features to get up to speed on the product codebase and how all the nuance works - it’s been extremely helpful in getting up to speed.

But here is the reality: LLMs are not perfect at writing code - even if it compiles first time. Even with high quality prompting and clear rules, these models still make mistakes. Speaking as someone who uses these tools every day, you cannot simply trust the output outright. You still have to review the code as if it were a pull request from a teammate. You have to read the logic, check the assumptions, and often make manual edits to get it right.

After all, you’ll likely be sending this to a teammate for a review (and maybe Code Rabbit I guess) - is it fair to make them review something you didn’t write or even bother to check?

These tools help you move faster, but they do not replace the need for a critical eye or your years of experience and do not understand the overall problem space better than you.

---

The hype makes it look like we’re entering a golden age of SaaS. We aren’t. We’re entering an era of personal software: tools you generate to solve a problem, and then move on.

With twenty dollars, a few hours of spare time, and a bit of patience, almost anyone can ship a functional application. We are entering the era of "personal software," where the gap between an initial idea and a working product is narrower than ever before.

In this new reality, engineering expertise remains incredibly valuable, but the nature of the role is shifting. Relevance is not fading. Instead, it is about leveraging these tools to build at a higher level than was previously possible. True expertise is now required to steer these systems and provide the technical oversight that LLMs currently lack.

While AI is undeniably good at writing code, it remains poor at architecting maintainable, distributable, and scalable systems. This is where non-technical leaders who think they can fire their development teams are making a significant mistake. Until we see the arrival of an artificial intelligence that renders this entire discussion moot, believing that technical expertise can be replaced by a prompt is a strategic error. Building robust software still requires a human who understands the underlying principles of the craft.

The bottom line is that while the tools have changed, the fundamentals of good engineering have not.

While barrier to entry may be gone - judgment, taste, and responsibility are still the job.

---

I hope you found this post insightful. Follow me on Twitter and Bluesky for more wild takes and opinions on programming & Elixir.

Check out defer.to — my current obsession!