Vibe Coding vs Using LLMs to Code Responsibly: Guidelines for Technical Leaders

I was asked in seriousness recently if ‘vibe coding’ is a reasonable way for a software development team to operate.  There’s a lot of misinformation buried in the hype about AI and software development.   Technical leaders: help your teams, your business, and your non technical counterparts separate signal from noise: here are some guidelines and thoughts. 

First off, an important distinction:  ‘Vibe Coding’ and ‘Using LLMs to Code Responsibly’ are different ways of using AI that should be used for different purposes.  

• Using LLMs to Code Responsibly means to use AI to generate anywhere from 0% to 100% of your code and then to read, understand, and refactor it if needed (using traditional or more prompts, it doesn’t matter) to ensure it meets best your practices for your codebase and business at its current stage (see below) before committing to production.  In short, it doesn’t matter where the code came from, but the developer needs to understand 100% of the code they commit to production. 
• Vibe Coding means completely ignoring the code and underlying infrastructure and never even looking at it; that is using natural language only to produce, correct, and iterate on the result.

So when is ‘Vibe Coding’ appropriate?

• You’re building and rapidly iterating on a prototype to show to customers for feedback to validate an idea (It is in my opinion a complete, and better replacement for traditional ‘low/no code’ tools for prototyping).
• You’re building one off scripts or rapidly evolving internal tools to do a job and save time
• You’re building hobby software for yourself 
• You’re experimenting with different LLMs/models as part of your learning path to understand their strengths and weaknesses  

In all other cases, teams should be somewhere in the ‘Using LLMs to Code Responsibly’ camp as otherwise you’re creating a minefield of technical debt in one or more of the following areas, which AI can not be trusted to be good: 

• Scalability (Performance and concurrency)
• Security (system and data)
• Proper edge case and error handling
• Costs / usages
• Privacy and PII+sensitive data handling
• Code quality (good architecture and encapsulation, maintainability, speed of future delivery, defects)
• Interoperability and backwards compatibility (how the system interfaces with other systems - such as public API specifications)

However, and this is crucially important and has nothing to do with AI: ‘code responsibly’ is not a static thing and tech debt is NOT always bad; in early stages of a startup I’d argue it’s necessary to take on debt to iterate fast enough to find product market fit and capture customers and market. In the above list, how much each of these matters and the appetite for technical debt in the area depends on the stage of your business and particulars of the software product.  It is a mistake to over engineer early on, and AI can be a massive help to get your company off the ground, iterate, and hopefully get those first customers.  The first entry in the Vibe coding list, ‘You’re building and rapidly iterating on a prototype to show to customers for feedback to validate an idea’ is essentially the first stages of a startup. Teams would be crazy not to leverage that and the line between ‘vibe’ and ‘responsible’ might thin; but you as the technical leader need to understand where to draw the line and define ‘responsibly’ for those first iterations and it always should involve looking at the code.  

Now contrast this scenario to a mature, large SaaS company with a big customer list, mature codebase, and huge transactional volume.   A screw up in any of the listed categories could cost millions/billions of dollars, compliance and legal problems, data loss, etc.  I’d be extremely cautious on where to trust AI code in this scenario, and put a lot more emphasis on the review and human side of things. It's an easy sell to your non technical leadership counterparts when you put things in terms of $.

Another observation is that all the things in the list that AI is bad at or untrustworthy are common parts of a software developer’s growth path; expectation to be good at them increases as they move up the levels.  Therefore, and this is no surprise, AI is best wielded by experienced, competent developers and the role of the technical leader to level up their team becomes more important than ever.  Inexperienced developers using AI without oversight is an antipattern to be avoided.

To summarize: 

• Vibe coding and responsible AI assisted coding both have their place in a developer’s toolbox; code destined for production should fall in the latter camp.
• The amount that you trust code generated by AI in general should be directly proportional to how much tech debt you’re willing to take on for that particular development effort, and in which particular areas.  A good rule of thumb is the more mature / large scale the product and codebase, the less gains / trust from AI.
• Inexperienced developers wielding AI is an antipattern. Continue to hire, train, and mentor developers so AI can be a multiplier.
• The role of a technical leader is unchanged at its core by AI (level up your team, make good foundational technical decisions, deeply understand the business and customer to understand where to take on technical debt and where not to), but the downsides of poor leadership are magnified (explosion of tech debt in the wrong areas by inexperienced developers, fundamental foundational / costly problems introduced by unchecked AI generated code).    

Thanks for reading! Please share thoughts in the comments.