|
|
|
|
|
by bigbinary
415 days ago
|
|
I used the phrase recently when my coworker asked me what metrics I use to guide my code decisions, and he gave me the options of sonarqube issues, test coverage (which I found to be configured to exclude huge feature directories of this legacy app), or efficiency metrics. All this after 6 major prod bugs were introduced over 6 months. My response was that I code by vibe, and really I meant that I was improving the nightmare of working in our backend code while trying to learn the business logic, restructuring our backend code structure, hardening our unit tests, and adding swagger documentation. While doing so, I uncovered tons of bugs. All in all, “vibe coding” to me is similar to “smelly code”, where the intuition depends on the implementor, but with the latter, “bad” coders can be silent and aren’t forced to make change smells. Good coders, however, prove their intuition skills when identifying and fixing code smells, even though today we have automated tools to tell us why our code smells feel or look bad |
|