For software teams adopting AI coding tools who want to avoid burnout, security breaches, and code quality collapse. A candid look at what actually happens when developers go fast without guardrails.
‘Vibe coding’ has captured imaginations, it also carries a lot of hidden pitfalls and misplaced optimism. Too many discussions around it are framed as if it’s the natural evolution of software engineering, when in fact the current reality is much messier.
By laying out the top 15 reasons the “vibes are off,” Ivan’s aim is to spark a more honest, nuanced conversation about what’s working, what’s failing, and where the risks really lie. You will hear clear, practical takeaways to help engineers and leaders separate hype from reality.
Slides
Find out more about BoS
Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.
Transcript
What Is Vibe Coding (And What It Isn’t)
Vibe coding is collaborating with AI to build software through natural language. You ask an AI developer something, and they come back with code. It’s great for prototypes, mockups, marketing sites, and small features. But it’s not your software architect. Many people make that mistake.
It’s excellent for rapid iteration. It’s not excellent for building something like Stripe from scratch.
AI-assisted coding tools like Cursor and Copilot are different. For developers, they can help with auto-complete, code refactoring, scaffolding, root cause analysis, ideation, and unit testing. But it’s like using a chainsaw. If you know what you’re doing, it’s powerful. If not, it’s a bloody mess.
The Real Cost: 19% Longer on Tasks
We looked at five of the most cited papers on how AI is being used in development, and the data is clear. Developers are currently spending 19% longer on tasks when using AI tools.
This isn’t because the tools are slow. It’s because hallucinations are not free. They require a lot of refactoring and review. And security risks are huge.
The 15 Problems (And How to Fix Them)
1-3: Tool Overload, Shadow AI, and Security
First, coding tool overload. There are now hundreds of tools developers can use, and it’s becoming difficult to evaluate, integrate, and assess them. Everyone has an opinion about which one to pick.
Second, shadow AI. Unauthorized use of development tools introduces massive security risks. Your sales intern might think they can write a prompt and contribute code.
Third, security risks compound from the first two. People copy and paste credentials, usernames, passwords directly into these tools. Once data is leaked, you can’t get it back.
How to fix it: Pick one stack and centralize it. Experiment with two or three if you need to, but commit to one. Then write standards. Any team can generate a prompt, but great teams write guidelines on how AI should be used in development. Capture input from business and product, not just code. You want progress for customers, not just lines of code.
4-6: Hallucinations, Security, and Architecture Drift
Hallucinations are the next problem. You generate hundreds or thousands of lines of code until you start analyzing them and notice APIs that don’t even exist. That’s when the real work starts: reviewing, testing, refactoring.
Security is compounded here. People paste sensitive information into these tools without thinking. You have to be extremely careful.
And architecture drift. AI is not your software architect. It doesn’t have all the context. If you integrate it without feeding the right information, it creates chaos.
How to fix it: Log and communicate problematic prompts with your whole team. Have a place where everyone can see what works and what doesn’t. Use LLMs with solid privacy policies. Go with the commercial ones. If you experiment with the latest trendy thing, it probably won’t be as secure.
Review your generated outputs and inputs continuously. Inputs are as important as outputs in AI architecture. Feed documentation to your RAG system or vector database so it has enough context to do better work. Check performance often. Test for performance regularly so you know when it breaks.
7-9: Scalability, Accessibility, and Observability
Many developers forget about scalability and are reminded once they have thousands of users. Tech debt piles up and piles up.
Accessibility is commonly overlooked. If you forget about it, customers will find defects and have a bad user experience. They churn.
And observability. If you don’t have logs, metrics, or traces in the AI-generated code, you don’t know why things are happening.
How to fix it: Take the time to onboard AI properly. Embody it as a tool and learn continuously. Designate strong, responsible owners of the AI tools. Usually someone in DevOps or product management. Include UX and accessibility in your QA strategy. Include your senior devs to instrument observability from day one.
10-15: Ownership, Code Quality, and Developer Burnout
Clear ownership is missing. If you ask who owns Cursor, three people shrug. No one owns it. There has to be accountability.
More code means more bugs. AI is generating code like a junior developer mostly. It produces a lot of code with a lot of bugs. Less mature code is being committed, causing a lot of refactoring and increasing time spent on reviews.
And here’s the burnout problem. Senior devs have to review five times more code from junior developers using AI. That’s burning developers out.
How to fix it: Developers need to continue owning unit testing. I’m starting to see companies forget about it, and that’s not good. Set clear expectations on code quality from the beginning. Define what is good for your developers.
Monitor and adjust the extra load they’re carrying. Senior devs are now reviewing five times the code they were before, and that’s unsustainable.
The Five Things That Actually Work
- Choose your AI tool wisely and manage closely. Pick one stack, centralize it, and enforce it.
- Set up the right guards. Standards, logging, communication, and clear ownership.
- Take the time to onboard the tool properly. Don’t just turn it on and hope. Feed it documentation. Test continuously.
- Define clear roles and responsibilities from the beginning. Someone owns this. Someone reviews this. Someone optimizes this.
- Continuously learn and adjust. Monitor developer load. Watch for burnout. Keep refining how you use it.
The vibe is only off if you treat AI like a replacement for thinking instead of a tool that requires careful integration, clear governance, and continuous optimization.
Ivan Barajas Vargas
CEO Founder, MuukTest
Ivan believes that AI will not replace QA, but it can certainly accelerate it. With 20 years of experience in software testing and QA engineering, he has seen first hand how slow, resource-heavy, frustrating, and flaky testing can be. So Ivan teamed up with Renan Ugalde in 2019 to launch MuukTest, an AI-powered and expert-managed solution that automates testing in days, not years. Since then, the company has been backed by top accelerators like MassChallenge and TechStars, VC funded by Contour Venture Partners and others, and awarded grants from the NSF and Google for Startups. He first joined the BoS Conference community as a CED Scholar and has been an active attendee ever since.
Next up
Online workshops
Can’t make it? More dates coming up