In the Age of AI Coding, Software Architecture Matters More Than Ever

Artificial intelligence (AI) has had everyone agog with the possibility of replacing engineers and putting software creation in the hands of non-developers. Everyone is talking about “vibe coding,” where all you have to do is describe a working idea, and an application appears. AI is clearly changing our approach to software development, but it’s not as foolproof as you may think. Building scalable enterprise applications is still hard, especially when you need to make them secure.

Testing AI’s Ability to Code

I have been a professional software developer for over 25 years and wanted to test the limits of AI in software development. I decided to run an experiment using my children, ages 12 and 14, neither of whom knows how to code. The goal was to create a role-playing game from scratch by describing the game’s features to the AI engine.

We created a pretty old-school, web-based RPG like Dragon Quest based on an old novel. 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.

The first results were promising. Within 15 minutes, we had a playable game. We could talk to characters, walk between maps, open treasure chests, and explore our simple world. It was exciting. If non-developers could build such an application in minutes, it could have larger implications for commercial software development.

It’s natural to think that 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.

As we continued building the game, cracks began to show. We added inventory logic, combat systems, leveling mechanics, and more characters. At first, the AI’s software fixes were fast and accurate, but as the system grew, things started to deteriorate. Bug fixes were taking longer. When one issue was resolved, previous bugs would reappear. We found ourselves playing whack-a-mole with game bugs; for every correction, new regressions emerged.

As progress slowed to a crawl, I decided to take a close look at the AI-generated code. I determined the issue wasn’t the code but the architecture’s fragility.

For example, map exits and player spawn locations were defined separately. What worked fine for five maps became brittle at scale, and adding new locations required updating multiple disconnected definitions. Since the design lacked a single source of truth, even small inconsistencies caused cascading failures.

 Any experienced developer would have started with a different architecture. For our example, location relationships could be derived programmatically using a grid model. This would eliminate the need for exponential refactoring to accommodate dozens of new modules. When developing a game, this is frustrating; in enterprise software, it’s disastrous.

The lesson was obvious: AI makes complexity cheap, but software maintenance remains expensive.

Then it hit me: Oh! That’s what a good software architect and software manager does.

A Fragile Software Architecture Has Security Consequences

In the beginning, when we asked the AI to fix something, it responded quickly, 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 time to fix a problem and often didn’t get it right the first time.

Then, 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 takes 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!

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 from the start.

Challenges in the Real World:

Here is the upshot: when building enterprise software, AI shortcuts don’t just create bugs; they create security risks. Let’s consider the evolution of a simple business application.

The initial application included customer records with one address. As business needs change, the application had to evolve to include multiple customer addresses, then subsidiary and parent-level addresses.

If the original schema has hard-coded a one-to-one relationship for customer addresses, moving to a one-to-many schema affects every query, report, integration, and even access control rules. When you tie authorization logic to those same assumptions, it creates a risk of data exposure. Consider the implications when you scale the problem for financial records, healthcare data, regulated audits, and access control policies.

When you use AI to generate application logic without architectural constraints, you see cybersecurity risks emerge, such as:

• Access control drift – Permissions that depend on brittle data structures break.
• Incomplete audit trails – Logging mechanisms may not adapt to new modules.
• Inconsistent data validation – Validation rules may be redundant and inconsistent.
• Shadow logic proliferation – Having similar logic duplicated across modules increases the potential attack surface.
• Refactoring risk – Architectural rewrites introduce new vulnerabilities.

AI responds to prompts without understanding. AI-written code can’t predict long-term governance or enterprise risk requirements. Sooner or later, AI is going to hit a wall, and that wall often has a direct impact on cybersecurity and compliance.

Avoiding Over-Engineering, but Include Guardrails

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.

In theory, you can instruct AI to generate enterprise-grade software that adheres to best practices to meet security and compliance requirements. In practice, this creates another problem: over-engineering.

Once you instruct AI to follow strict design patterns, the AI produces excessive layers of abstraction, unnecessary services, and fragmented modules. The system becomes bloated, token use increases, each fix requires more context, and maintenance overhead skyrockets. Over-engineered systems aren’t inherently more secure, but they do have more blind spots and increase the likelihood of misconfigured permissions and inconsistent enforcement.

AI can generate code quickly, but it can’t incorporate security without clarity, and clarity depends on a well-scoped architecture.

AI coding works best when done by experienced developers who understand architectural trade-offs. Non-developers shouldn’t be making architectural decisions about database normalization, relationship cardinality, or access control inheritance, even though they implicitly do so when they use AI coding tools.

When using well-designed no-code platforms, the AI doesn’t have to create an architecture from scratch. Architectural decisions are made inside the platform, providing structural guardrails. Data relationships are modeled in a structured way, permission systems are predefined, audit trails are standardized, and UI consistency is enforced. AI accelerates code development, but architectural guardrails ensure a secure system.

AI Raises the Bar for Software Developers

The experiment with my children developing a game demonstrates that AI makes it easy to create new software. It also reinforced several important considerations for enterprise software, especially as they relate to cybersecurity. As software scales, it needs a well-defined architecture to provide guardrails. Software resilience requires:

• Maintainable access controls
• Consistent auditability
• Predictable schema evolution
• Controlled integration boundaries
• Sustainable long-term governance

AI code generators can’t provide this level of software resilience, at least not yet, so AI can’t do the job of enterprise architects. When AI is embedded in no-code platforms with architectural discipline, security boundaries, and governance controls, creating enterprise software with AI is easier, but maintaining security at scale requires strategic oversight.

An experienced developer who knows the full picture in the beginning would have designed this differently. A developer would design the location definitions so that the exit and spawn areas are programmatically determined (maybe with a grid system). But this issue has to be addressed in the beginning, or later it becomes entangled with hundreds of other similar problems. It becomes unmanageable even for AI when the codebase is so large that none of the modules fit in the context window.

Architecture still matters, and architects are still needed to ensure security and functionality in enterprise applications. AI provides a tool that translates user requirements into system definitions, but without making technical decisions. No-code tools ensure there is business logic to keep complexity manageable, security intact, and long-term maintenance sustainable.