For debugging or small tasks, I sometimes treat it like a lottery. Maybe it will produce something amazing. Sometimes, it does.<\/p>\n
Vibe coding helps me brainstorm what the solution could look like, even if I don’t adopt the final solution it proposes. Vibe coding also speeds up the time spent rewriting code when you realize a requirement wasn’t covered.<\/p>\n
![\"Chong](\"https:\/\/www.newsbeep.com\/nz\/wp-content\/uploads\/2026\/02\/67bfbe5469253ccddf97b897.jpeg\")
<\/p>\n
\n Every time Lee Chong Ming publishes a story, you\u2019ll get an alert straight to your inbox!\n <\/p>\n
\n Stay connected to Lee Chong Ming and get more of their work as it publishes.\n <\/p>\n
Vibe coding is faster, even with double-checking<\/p>\n
When I vibe code, it’s always iterative. I give it the basic information it needs, it produces a version, then I check it \u2014 similar to a code review with coworkers. I might say, “You missed this part” or “You missed that part.”<\/p>\n
The AI sometimes fixes issues<\/a> but introduces something new. You have to keep an eye on it.<\/p>\n For complex tasks, you need more double-checking. But even with the extra checking, it’s still faster.<\/p>\n I was working with a partner team and ran into complex locking issues. Without an LLM, I might have taken a day to research possible solutions, especially since it was relatively new to me.<\/p>\n Within 15 minutes, I brainstormed with the LLM about possible solutions. I pointed out weaknesses in its suggestions and asked it to improve them. In 15 minutes, I had a proposal to send to the team.<\/p>\n Technical knowledge helps \u2014 you know what’s a good solution and what’s not. You know what tastes good, but you don’t know what dishes are available. The LLM brings up all the dishes, and you choose.<\/p>\n Vibe coding for scale might not work, and technical knowledge still matters<\/p>\n Still, I’m hesitant to use vibe coding directly in production.<\/p>\n LLMs are very good at solving problems, but sometimes they make implicit assumptions you don’t realize they’re making. If you don’t tell it explicitly, for example, that something needs to work for multi-threading, it might just produce the minimum version that works, but when it’s large-scale or productionized, it could crash.<\/p>\n Non-technical builders could tell an LLM to build something that handles millions of users. But if you have zero technical knowledge, it’s hard to anticipate constraints upfront. If you don’t tell the model the implicit assumptions, it won’t respect those constraints. Later, you’ll run into problems<\/a>.<\/p>\n Non-technical people<\/a> might use the LLM to fix issues reactively. But technical people can anticipate constraints proactively and prevent problems in the first place.<\/p>\n Technical people also understand vibe-coded content better, and they’re in a better position to understand what LLMs are good at and not good at. For example, knowing how they’re trained and why they’re weaker at certain tasks like math. That understanding helps you master them as tools.<\/p>\n When you scale to one million or 100 million customers, systems need to be coded differently to handle that scale.<\/p>\n Vibe coding is hard to resist<\/p>\n Initially, leadership pushed vibe coding. Our team is a GenAI team, so we were naturally more receptive. In non-GenAI teams, engineers initially reacted like, “No, I won’t let AI do my job. I don’t trust AI-generated code.”<\/p>\n After people tried it, attitudes shifted<\/a>. People realized it’s pretty good sometimes. Now it’s more widely adopted.<\/p>\n