DEV Community: Subhash Jha

The Cost of Convenience: How Vibe Coding is Changing Developer Growth

Subhash Jha — Wed, 18 Jun 2025 05:39:13 +0000

Agentic coding is great. I have been leveraging this technology daily for past six months. I’m not here to discuss its precision or the productivity gains it offers. As the saying goes in the AI world: this is the worst it’ll ever be.

I am concerned about something completely different. The dopamine effect of triggering the LLM through a click of button, whether it’s for writing, refactoring, or debugging code. It feels like a slot machine, except here your odds of winning (getting a good solution) are nine out of ten. And soon, that’ll become ten out of ten. This whole vibe coding has gamified some part of software development.

When you spend 10 hours debugging a code or refactoring a code, you learn a lot of things in the process, like design principles, code quality concepts, better awareness of common pitfalls. This leaves you happy and satisfied in the end when you see the result of your effort. But with vibe coding it’s all about instant gratification. Triggering LLM once or twice (if the result is not right) takes the same effort. Devs are using prompt to get the solution and another prompt to explain the solution and then next prompt to write the test case for that solution.

This feels like magic wand, the developers are now 10x productive, even product managers can now build a quick POCs to validate their ideas, most of the infrastructure work can now be automated under a single person which earlier required a complete team. But there is a tradeoff. We’re sacrificing the constant learning and growth that naturally came from the struggles, struggles now replaced by these tools..

I align with the belief that 90% of routine development work should be automated, and that human creativity should be focused on the remaining 10% areas where deep insight is needed and where LLMs still fall short (because of lack of training data). But the reality is that many used to build their capabilities by grappling with that 90%. It’s through that struggle that developers earned the depth needed to contribute meaningfully to the 10%. With that learning opportunity fading away, we need to find new ways to train ourselves and stay relevant for the remaining 10% of work that still requires human developers.

SOLID Principles

Subhash Jha — Mon, 31 Oct 2022 06:57:56 +0000

The principles :

Single-responsibility principle
Open-Closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

Single Responsibility Principle

A class should do one thing and therefore it should have only a single reason to change

class Vehicle {
    public:
    int speed;
    Engine* engine;
    int mileage;
    void changeSpeed();
    void changeDirection();
    void repair();            // Violate SRP
}

// FIX
class Garage {
    public:
    void repair(Vehicle* vehicle);
}

Open Closed Principle

Classes should be open for extension and closed to modification.

class Garage {
    public:
    void repairLocal(Vehicle* vehicle);
    void repairBranded(Vehicle* vehicle); // Violate Open closed principle
}
// Addition of new tyep of repair will result into modfying the existing class.

//FIX
class Garage {
    public:
    virtual void rapair(Vehicle* vehicle) = 0;
}

class LocalGarage : public Garage {
    public:
    void repair(Vehicle* vehicle);  //Local repair
}

class BrandedGarage : public Garage {
    public:
    void repair(Vehicle* vehicle);  //Branded repair
}

Liskov Substitution Principle

Subclasses should be substitutable for their base classes

Liskov Substitution Principle is an extension of the Open Close Principle and is violated when you have written code that throws “not implemented exceptions” or you hide methods in a derived class that have been marked as virtual in the base class.

class Vehicle {
    public:
    virtual void changeGear();
}

class Scooti : public Vehicle {
    public:
    void changeGear(){
        throw("Not implemented"); //Violate Liskov substitution principle
    }
}

// FIX
class Vehicle {
}

class GearVehicle : public Vehicle {
    public:
    virtual void changeGear();
}

class NonGearVehicle : public Vehicle {
}

class Scooti : public NonGearVehicle {
}

Interface Segregation Principle

Separating the interfaces

The principle states that many client-specific interfaces are better than one general-purpose interface. Clients should not be forced to implement a function they do no need.

// FIX
class Vehicle { // Common Base Interface
}

class GearVehicle : public Vehicle { // Segregated Interface 1
    public:
    virtual void changeGear();
}

class NonGearVehicle : public Vehicle { // Segregated Interface 1
}

class Scooti : public NonGearVehicle { // Implement only what required
}

LSP vs ISP

LSP: The receiver must honor the contracts it promises.
ISP: The caller shouldn’t depend on more of the receiver’s interface than it needs.
Where they fit: If you apply the ISP, you use only a slice of the receiver’s full interface. But according to LSP, the receiver must still honor that slice. If you fail to apply ISP, there can be a temptation to violate LSP. Because “this method doesn’t matter, it won’t actually be called.”

Liskov Substitution addresses Subtypes design whereas Interface Segregation addresses Basetypes design.

Dependency Inversion Principle

Our classes should depend upon interfaces or abstract classes instead of concrete classes and functions

class Vehicle {
}

class Car : public Vehicle {
}

class Garage {
public:
    void repair(Vehicle* vehicle); // depends on Vehicle interface rather then on Car
}

Binary Search

Subhash Jha — Mon, 31 Oct 2022 06:55:02 +0000

Binary Search - Different variations

// return index of first element >= target
int lower_bound(vector<int> v, int target){
    int l = 0;
    int r = v.size();
    while(l < r) {
        int m = l+(r-l)/2;
        v[m] < target ? l = m+1 : r = m;
    }
    return l;
}

// return index of first element > target
int upper_bound(vector<int> v, int target){
    int l = 0;
    int r = v.size();
    while(l < r) {
        int m = l+(r-l)/2;
        v[m] <= target ? l = m+1 : r = m;
    }
    return l;
}

// return index of element == target
int binary_search(vector<int> v, int target){
    int l = 0;
    int r = v.size();
    while(l < r) {
        int m = l+(r-l)/2;
        v[m] < target ? l = m+1 : r = m;
    }
    return l < v.size() && v[l] == target ? l : -1;
}

int main()
{
    vector<int> v = {1,1,2,4,5,5,5,6,6,8,9};
    cout<< lower_bound(v, 5);  // 4
    cout<< upper_bound(v, 5);  // 7
    return 0;
}