AI Is Not Eliminating Software (For Now)

As software stocks sharply decline in value, a growing number of people are starting to predict that AI will replace software. We are seeing tons of stories on how quickly AI generates software—at a speed that was unthinkable in the past.

Is this the future? A future where everyone can just generate the software they need on demand? Or simply ask AI to do whatever the software was doing for them?

The Excitement With AI Coding

I've been developing software for the last 25 years, and the latest iteration of AI coding like Claude Code got me hooked for quite a while. I love developing software and creating things; AI coding is as addictive as PC and mobile games to me. Outside of Ragic, I started quite a few side projects for fun and to test out what AI coding can do. I even work with my 14 and 12-year-old kids, who don't know how to code, to create games for fun as an experiment. I also want to understand how well vibe coding works for non-developers.

We created a pretty old-school, web-based RPG like Dragon Quest based on an old novel (so there are no copyright issues and it has a full backstory). We all acted like non-developers, not looking at the code it generated, only testing it and telling the AI what we wanted to add and what needed to be fixed.

In 15 minutes, we already had a game with a few screens where we could walk around, talk to NPCs, check out items, and even open chests! It was so awesome and exciting—as always with vibe coding, you want to share this cool thing you have built with others.

The Issues That Popped Up During Vibe Coding

It's natural to think "If we can do all this in 15 minutes, imagine what we can do in a couple of days!" We started adding more maps, combat systems, level-up systems, inventory systems, and ability systems. It quickly looked more and more like a complete RPG.

In the beginning, when we asked the AI to fix something, it was usually really fast and the AI got it right the first time; but as we added more locations, NPCs, and different modules, we started to notice that the AI took more and more time to fix a problem and often didn't get it right the first time.

We started to ask the AI to implement an automated test system so that it could stay in a loop to playtest the game and fix issues until they were verified as fixed. The AI started to take longer and longer to fix the issues (it also used up a lot more tokens!), and still often didn't fix them correctly. Worst of all, when it fixed Issue A, Issue B would pop up; when it fixed Issue B, Issues A and C would pop back up! It's like whack-a-mole!

Looking Into The AI-Generated Code

It got so frustrating that I decided I had to go in there to take a look at what was going on. The code generated had some significant, fundamental design issues. For example, players travel the world through a series of locations. When a player exits Location A from the right, he appears at the next Location B on the left. If he goes back left exiting Location B, he should appear at the right of Location A. This is a very natural behavior, and it was correct at the start.

However, as more locations were added, we noticed that this behavior began to break, and it was very hard to make sure they were all correct when we had over 100 locations. When I looked into the code, I noticed the location definitions specified where the exit areas were and which location each exit lead to. Spawn areas were separately defined for when the player appears on the map. This is actually a very fragile design that's hard to maintain, because when new locations are added, it's very hard to ensure all other locations are changed accordingly to keep the logic consistent.

Experienced developers who know the full picture from the beginning would design this differently. They would design the location definitions so that the exit and spawn areas are programmatically determined (perhaps with a grid system). This issue has to be addressed in the beginning. Otherwise, it will be entangled with hundreds of other similar problems later on. It will become unmanageable even for AI when the codebase is so large that none of the modules fit in the context window.

Then it hit me— "Oh! That's what a good software architect and software manager does." They understand the big picture, then plan and construct the system so that it's manageable and reduces code duplication to avoid issues like this.

Why AI Is Not Eliminating Software Yet

Can AI do this design? Certainly! Can AI create a good software architecture with a person who has no software development experience? This is the part where I start to wonder, and it doesn't look like it's going to be easily solvable soon.

AI can create great designs and follow best practices pretty easily, but following every one of these practices blindly results in huge, over-engineered software, which is a bigger problem of its own. You don't create a foundation meant for a skyscraper every time you build a house.

A certain type of guardrail—a platform where non-developers can talk about their requirements in an iterative manner without worrying about "how" it's implemented—would be the way to go. AI coding still works great for experienced developers, but for non-developers, these guardrails would help immensely when building a non-trivial project that’s supposed to be used and maintained for years. AI makes complexity cheap, but maintenance remains expensive.

The same problem can be even more serious for enterprise applications, where the business logic is just as complex (if not more so), and software glitches have much higher consequences—especially regarding data security, compliance, and monetary transactions. When the big picture is not presented to the AI carefully from the start, the same problems we saw in the game design will start to haunt you as the application develops. AI development without a professional software architect tends to hit a wall at various application sizes. Sooner or later, it will hit a wall and become more and more expensive to maintain. AI cannot magically fix large codebases.

No-Code Applications Working As Guardrails

This is exactly the problem that "No-Code" applications are trying to solve. Non-developers should be provided a way to describe purely "business logic" without the need to make any software architectural or implementation decisions—No code, and no "tech talk" either. The no-code tools should be designed specifically for the category of application that the user wants to build; for example, "database applications" like CRMs, Project Management, or ERPs.

This is where a no-code tool like Ragic comes in handy. When business users describe what their application should do on Ragic, they only need to describe how their sales process works or how their projects are managed—not how the data is saved to which databases.

AI-assisted development within no-code tools like Ragic does not require assumptions about how business processes are implemented from a technical standpoint. Instead, it uses the platform to translate user requirements directly into system configurations, without making technical design decisions. The no-code tool works as the guardrails for non-developers and AI to design the system, ensuring not only that it's technically sound, secure, and robust, but also that it has a consistent and clear UI/UX—which is often surprisingly hard to do for non-developers vibe coding.

The result is a system that does not grow out of hand when developed and maintained by AI. It also provides a level of transparency for human users to go into the system and look at the application design without reading or understanding any code. Users can take advantage of the no-code tool to ensure they have a full grasp of the current business logic, while having the ability to make changes and maintain the system without coding as needed.