There’s a term making the rounds in developer circles this year: “vibe coding.” It describes a way of building software where you lean almost entirely on AI tools to generate code, accept the suggestions that look right, and ship, often without fully understanding what the generated code is actually doing.
It’s fast. It’s tempting. And for a lot of use cases, it’s a real liability.
Search interest in the term has climbed sharply over the past year, and it’s easy to see why. AI coding assistants have gotten good enough that a working prototype can come together in an afternoon. But there’s a gap between “this runs” and “this is something you’d want in production,” and that gap is where most engineering organizations are quietly accumulating risk right now.
So instead of debating whether vibe coding is the future or a passing trend, it’s worth asking a more useful question. What does engineering discipline actually look like now that AI can write code faster than any of us can review it?
There’s a tempting story that AI assisted development means we need fewer strong engineers, because the tools handle the hard part now. The data tells a more complicated
story. Developer surveys consistently show that most developers are willing to use AI tools but still reluctant to fully rely on them. That reluctance isn’t stubbornness. It comes from experience. Teams that lean on AI generated code without oversight tend to build up technical debt fast, sometimes faster than they can track it. Some in the industry have put it bluntly: AI can multiply a team’s ability to create tech debt just as easily as it multiplies output.
None of this is an argument against using AI. It’s an argument for treating AI generated code the same way you’d treat code from a very talented but very junior engineer. It’s useful, it’s fast, and it’s occasionally wrong in ways that aren’t obvious at first glance. It always needs a second, more experienced set of eyes.
This is where the “vibe” part of vibe coding falls apart. Vibes don’t scale. They don’t hold up in a compliance audit. And they definitely don’t hold up when a finance team asks why a reconciliation job quietly dropped decimal points for three weeks straight.
Discipline holds up. That’s the difference, and it’s worth unpacking what discipline actually means in practice.
Reviewing code as ifit might be machine written, and reviewing it more carefully because of that. There’s a growing conversation in engineering circles about what “code smells” look like when part of a codebase came from an autonomous agent rather than a person. Often the smells are different from what a senior engineer might expect. Overly generic error handling. Two functions that were clearly generated in separate prompts and don’t quite share the same assumptions. A dependency nobody on the team can explain the reason for. Catching these takes deliberate practice and a review process built for this reality, not a quick glance and a rubber stamp.
Treating quality engineering as a strategic function rather than an afterthought. There’s a reason the idea that AI’s real return on investment depends on strong quality engineering has struck such a chord recently. AI is good at producing volume. On its own, it can’t guarantee that volume is correct, secure, or maintainable. The organizations actually getting value out ofAI tooling are the ones that invested in QA and testing discipline before they scaled up AI assisted development, not after something broke in production.
Protecting the architecture and system design skills that don’t get commoditized. AI is genuinely strong at implementation. It’s much weaker at deciding how five services should talk to each other, where data boundaries should live, or what happens to a system three years from now when transaction volume is ten times what it is today. As implementation gets faster and cheaper, the ability to design the shape of a system correctly becomes more valuable, not less. This is arguably the single biggest shift in what makes a senior engineer valuable right now.
Building a culture where slowing down is allowed. The pressure that comes with AI tools is often less technical than cultural. When a suggestion appears instantly and looks plausible, there’s an implicit pressure to accept it and move on. Teams that do this well have made it normal to pause, question a suggestion, and trace through why it works before merging it. That’s a leadership problem as much as an engineering one, and it’s worth addressing directly rather than assuming it will sort itself out.
In healthcare, fintech, and life sciences, a plausible looking function that hasn’t been properly understood, tested, or reviewed isn’t a small risk. It can turn into a compliance incident, a data breach that takes months to trace, or an outage nobody can explain because nobody actually understood the code that caused it. The cost of skipping review doesn’t show up immediately. It shows up later, usually at the worst possible time, and usually bigger than it would have been if someone had caught it early.
This isn’t a reason to avoid AI tools in these industries. It’s a reason to be more deliberate about how they’re introduced. A few practical starting points for teams working through this:
There’s an optimistic version of this story too, and it’s worth saying out loud. Contrary to the fear that AI shrinks the need for developers, a lot of people in the industry argue the opposite is true. Demand for code is close to infinite, and AI is expanding what’s possible to build. That expansion also increases the number of places where skilled engineers are needed to make sure what gets built actually works the way it’s supposed to.
The engineers and teams that do well in this environment won’t be the fastest prompt writers. They’ll be the ones who can hold onto two things at once: real fluency with AI tools, and the discipline to slow down and question the output when it matters. No amount of vibe substitutes for that, and no tool, however capable, removes the need for it.
Healimpilo is a technology advisory firm working with companies across healthcare, fintech, life sciences, and SaaS on engineering strategy, talent, and delivery.
