Vibe coding

What is Vibe Coding? Why Engineers Must Still Own the Architecture

Introduction

Alright, so hey everyone, welcome back, welcome back to another exciting article, and in this particular article , let’s talk about Vibe coding, and specifically, how to Vibe code. So, let’s be honest, let’s agree that AI is shipping a lot of code, and it’s doing great. Okay, in our company, we also use a lot of AI tools in our day-to-day tasks, like cursors and a lot of models to generate code, and this code generation is really great and really fast, but there’s a small catch. I am not here to say that this is going to replace and it is going to take away your job, no that is all a different thing, let’s talk about how we can use Vibe coding effectively, what are some do’s and don’ts about Vibe coding and why and how you should Vibe code, how you can use AI tools for better building stuff for better outputs, okay and don’t worry there is no need to be scared of this, there is no FOMO, it is a very practical article, it is a very engineering oriented article, so sit back, relax and just read completly. So the first thing I noticed about the people who are coding the problem is that they’re fully relying on it. What they do is just create a single, one-shot project that says, “Hey, I just want to build this X-Wise application that looks something like this and I can do this, and I enter and that’s it.” They think, “I just created a one-shot project, I gave my AI what I wanted to build, whatever I wanted, and it’s just going to do an end-to-end task.” It really does, okay, it can do it. It will give you an MVP, a minimum viable product, but that’s not anywhere close to shipping. That’s not anywhere close to pushing it to production. Even if you get 10-15 users, it will easily crash, and that’s not maintainable code at all. You can’t add more features to it, so it’s like a working PoC. It’s good for that, but that’s not how you should write code.
So point number one is that you always do the boilerplate code setup. That means you should have an opinion on the design and structure of the code. That means as a developer, you should write all the boilerplate code.

Most Repeated Questions

  • How are you arranging the folders?
  • What files are you putting in which folders?
  • Are you modern?
  • Are you using Model View Controller?
  • Are you using MVVM?
  • Whatever pattern are you using?

You have to do that.

Secret Weapon of Google
Gemini

What you need to do?

If you’re setting up a mono-repo, make sure you maintain your ES lent files, your TypeScript configuration files, your packages, your package lock files, because that gives structure to the code. That gives a solid backbone. Because if the skeleton of your code isn’t good, no matter how good your entire code is, it’s going to break one day. So, the foundation—the skeleton, the structure—has to be solid, and that’s only an engineer can do. So, make sure that if you’re starting to build a new product, the boilerplate code setup is done by you, the configurations are done by you, and you should take over the design and those design choices of the code. If your code structure is good, the AI ​​actually works really well. If your code structure isn’t good, then nothing inside it works very well. So, that was our point number one. Point number two, this is very different: you have AI implement features, you have AI implement the back end, you have them write API routes, you have them write the front end, you have them write CSS, but one thing you should never let AI do is design your database.
So, if we take any example of a full-stacked application, what is a full-stacked application? The pattern is very similar: the user will have a front end. The user will interact on the front end. You have a post call or a get call going to your back end.
The back end will do something from the database, either a create operation, an update operation, or a read operation, and you return that data to your front end.
This is 99% of the time, this is how full-stacked applications are made. Now the thing is, this is a repeating process. For everything, you have to create a code route that creates, reads, updates, and deletes. You create a front end for the user. You can hand over these repeating processes to your AI. You don’t want to do the repetitions of tasks.

But the database design, which is the core of your application, the database design, the database schema, is something you should always code by hand. You should always design the database schema by hand because number one, the AI ​​doesn’t know what problem you’re solving. The AI ​​doesn’t know what application you’re trying to build. What your vision is, because that’s in your brain.

Even if we get the work done by interns or humans, we don’t tell them everything at once because I know my vision. If you’re a builder, only you know the vision. You know what features you’re going to include in the future, and what directions you want to take it in. So, if your database design is bad, if your database design is just limited to today’s knowledge of AI, it’s going to ruin your application and cause a lot of problems later. Because changing the database design is very difficult, so scaling the application will be difficult.

Professional Claude Skills

Leave a Comment

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *