Vibe Coding vs. SOLID: Is Clean Code Still King?

As an experienced software development manager who’s spent years championing clean code and engineering best practices, I’ve always treated the SOLID principles as gospel. SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) has been my north star for building maintainable, flexible software. 

But lately, I’ve been wondering: In a world where artificial intelligence is writing more and more of our code, are these principles still as “solid” as they once were?

The SOLID principles at a glance

Just to set the stage, here’s a quick refresher on what SOLID stands for:

• Single Responsibility Principle (SRP): Each class or module should have one and only one reason to change—basically, do one thing well.
• Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification. Rather than altering existing functionality, add new features by extending the code.
• Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without breaking the system. A subclass should fulfill all the expectations of its parent class.
• Interface Segregation Principle (ISP): Don’t force clients to depend on methods they don’t use. Having many small, specific interfaces is better than one large, general-purpose interface.
• Dependency Inversion Principle (DIP): High-level modules shouldn’t depend on low-level details; both should depend on abstractions. And those abstractions shouldn’t depend on details.

These principles have guided our code design for years. Following them leads to cleaner, more modular and testable code—and usually fewer late-night debugging sessions. I’ve long preached these rules to every team I’ve led.

SOLID vs. AI’s “vibe coding”

Enter 2025: We now have AI copilots and a new trend called “vibe coding,” where a developer simply describes what they want and the AI generates the code. It’s dubbed “vibe” coding because, as Andrej Karpathy quipped, “It’s not really coding—I just see things, say things, run things, and copy-paste things, and it mostly works.”  

With LLMs writing significant chunks of our software, it feels like science fiction. In fact, a recent Y Combinator batch had 25% of startups where 95% of the code was AI-generated. That’s a tectonic shift in how code gets written.

So, how do our beloved SOLID principles hold up when it’s not a human but an AI churning the code? Here are a few provocative thoughts:

Code reuse vs. rewriting

We’ve long obsessed over DRY (Don’t Repeat Yourself) and code reuse. But if a model can rewrite any piece of code on demand, maybe reuse is less of a holy grail. Duplicating some logic isn’t as costly when the AI can update all copies effortlessly. In fact, one analysis found AI often duplicates code rather than abstracting it, possibly making each piece more straightforward to read, even if the overall codebase isn’t as DRY.

Deep abstraction vs. full implementation

OCP encourages adding new functionality via abstraction layers to avoid changing core code. But if an AI can regenerate the entire implementation when requirements change, those layers of abstraction might be overkill. Why create a complex plugin system or class hierarchy when the AI can spit out a tailor-made solution on demand?

Single responsibility (maybe not so single)

We insist that a class should do one thing so humans can understand it. But what if the “reader” of the code is an AI that can easily handle an entire file’s complexity? Maybe a chunk of code doing two or three jobs isn’t the end of the world if the model can still grasp it and even explain it to us in plain English. 

In an AI-assisted era, a “god class” with multiple duties might not be so sinful, since the model can manage the cognitive load and even add documentation for us.

Inheritance is so 2010s

LSP and deep inheritance chains feel less vital if our new AI teammate can just generate flat, procedural code structures on demand. Why painstakingly engineer a class hierarchy to share code when the model can copy-paste (er, “generate”) similar code in multiple places without complaining? 

The old advice “prefer composition over inheritance” might evolve into “prefer generation over inheritance.” An AI will happily produce whatever variant you need, no subclassing required.

New AI perks

There are other upsides to AI-written code. We might worry less about writing documentation, because the AI can generate docs or explain the code on the fly. Boilerplate and repetitive grunt work? The AI handles those with ease, letting us focus on higher-level design (or just coming up with ideas). And if a big refactor is needed, you can literally ask the AI to do it. In short, some of the old reasons for meticulously applying SOLID are starting to shift.

Of course, I’m not declaring SOLID dead. A codebase that turns into a big ball of mud is still a nightmare (even an AI would agree). And many of these “maybe we don’t need X” ideas assume a mighty and trustworthy AI. In reality, today’s models still make mistakes and need oversight. But it’s worth asking:

In a future where AI codes at will, how SOLID are our SOLID principles? 

Are they timeless truths we’ll keep following, or will we relax our rules and let AI-era “vibe coding” lead us in new directions? As someone who’s spent a career advocating clean code, I find this both exciting and a bit unnerving. 

Whether SOLID remains our north star or becomes a relic of manual coding, one thing’s clear: we’re entering a new era of development. It’s time to engage with it, challenge our assumptions, and shape what good engineering looks like—before someone (or something) else does it for us.

If part of that shift means rethinking who owns what in the stack, Frontegg is already helping teams break free from legacy CIAM constraints and build with a little more freedom. 

Start using Frontegg for free today.