The term "Vibe Coding" is often used by developers. It means that the developer uses their big AI tools in a way that they are "describing the vibes" of an app and are able to make large amounts of code instantaneously. This is great for getting the app to market, but it leaves open the possibility that code that looks right is not architecturally correct.
The Foundations vs. The Shortcuts 🧠
In the professional development process, how we deal with logic changes in steps:
The Syntax Phase:
This is where we learn the syntax of the language, how to write a for loop in Java, how to connect to Oracle SQL, etc. At this stage, the role of the AI is that of a super smart autocomplete.
The Architecture Phase:
This is where the real engineering takes place. It’s where we reason about why we prefer one way over another. If we have an app that’s super “slick” and “vibe-coded” but uses a transitive dependency that violates Database Normalisation, then the app remains shaky even though it looks nice on the outside.
Why Vibes Don’t Cut It in Production🏗️
The problem with relying solely on auto-generated code is that it does not reveal how it’s generated. While an executable code is essential in production, the real challenge lies in making it maintainable.
The Vibe trap is real. The tendency of AI code is to only work on the “happy path.” The “happy path” is where everything goes right.
Vibes-only coding might get you a login screen that works.
An engineer might build a login screen that’s not only functional but also includes BCrypt for password hashing, try-catch for database timeouts, and an MVC structure with validation.
The Plan: Augment, Don’t Replace 🛠️
To use AI to improve our engineering advantage, we should strive to establish a consistent and disciplined process:
Pseudocode First:
Before we ask the AI, let’s try to write the logic out in plain English or with a basic flowchart. If the logic is indescribable, then we’re unlikely to engineer it well.
The Line-by-Line Rule:
Don’t write code that you can’t describe in excruciating detail. If the generated lambda is confusing, then take a moment to understand how it works at a basic level.
Architectural Refactoring:
AI tools seem to favor “monolithic” code blocks. Use the principle of Separation of Concerns to divide the code into separate, more digestible parts.
Final Thought: Keep the Architect in the Loop 🏢
The idea is to work smarter, not harder. Let AI handle the boilerplates and repetitive tasks, but retain ownership of System Design and Architectural Strategy. This way, your portfolio - and your career rests on actual engineering prowess rather than your ability to quickly prompt AI.
Top comments (0)