I'm amazed at how quickly AI is changing the way we build software. It's undeniably boosting productivity. "Vibe coding" is everywhere — you describe what you want, you get code, you ship. It can feel like software engineering turned into prompt engineering overnight.
I'm not here to dunk on it. AI is great for quick PoCs, for unblocking yourself, for generating boilerplate and exploring ideas. The question that keeps coming up for me is different: do you actually understand what you're shipping?
And if the person who built it doesn't understand it, how does the product stay sustainable?
Why this matters at scale
When a junior engineer (or anyone) leans heavily on AI without ever having spent time writing and debugging code by hand, a few things happen. They get fast at producing output. They might not build the muscle for reading unfamiliar code, tracing a bug through several layers, or making deliberate tradeoffs. They might become good at prompting and weak at reasoning about the system. That's not a character flaw — it's what happens when you skip the reps.
The risk isn't "AI is bad." The risk is that we optimize for speed and forget to build the foundation. Then we end up with a codebase that only AI or a few people can fix, or a team that can add features but can't own incidents. The product might work today. The question is who keeps it working in a year.
What we can do about it
1. Set the bar in review: "you own it if you ship it."
If someone ships code they can't explain, that's a failed review. It doesn't mean "no AI." It means: by the time it lands, you can walk me through the important parts. Why this structure? What happens when X fails? What would you change if we had more time? If they can't answer, they're not ready to merge. This isn't about gatekeeping — it's about making sure the person who wrote the prompt is also the person who can debug the result.
2. Use AI for exploration, not for hiding gaps.
Encourage using AI for PoCs, for learning, for getting unstuck. Discourage using it to avoid understanding. "I don't know how it works but it passes the tests" is not acceptable for production. As a lead, you can make that explicit: we're fine with AI-generated code as long as you've read it, understood it, and can change it. If you couldn't have written a worse version of it yourself, you're not ready to own it.
3. Protect time for fundamentals.
When the default is "ship faster," developers often don't get the space to struggle with a hard bug or read a codebase they didn't write. However, we should create that space deliberately — for yourself and for the team. That might mean pairing on a nasty production issue instead of handing it to the usual expert, or carving out time for "read and understand this module" instead of only "deliver this feature." The goal isn't to slow people down. It's to make sure the people who build the system can also maintain it.
4. Separate "quick win" from "long-term asset."
Not every line of code needs to be understood to the bone. Prototypes, one-off scripts, internal tools — sometimes "it works" is enough. But the moment something becomes part of the product, runs in production, or blocks other teams, the bar goes up. Make that distinction clear. Vibe coding for a throwaway experiment is fine. Vibe coding for a service that others depend on is not, unless the owner has put in the work to understand it.
5. Model the behavior.
If you're a tech lead, the team watches what you do. If you paste AI output into the codebase without reading it, they'll do the same. If you say "I don't know how this works, let's dig in," they'll see that it's okay to not know and then learn. The biggest lever you have is your own standard: understand your code, ask others to explain theirs, and treat "how does this work?" as a normal question, not a gotcha.
The bottom line
AI is going to keep making us faster for sure. This is the trends and we shouldn't resist that. It's to make sure we're not trading away the ability to maintain and evolve what we build. Vibe coding is powerful. So is the discipline of understanding what you ship. We need both.