Thoughts on "Vibe Coding": When The Music Stops

It’s been a few months since the race of advanced code assistants started, and we already have a few winners... in one corner or another. I wanted to share my thoughts and some discussions that I’ve had with other Engineers in my profession and social circle.

Vibe coding?

Let’s recall [1] February 2025, and this Tweet from Andrej started it all.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

The keyword is “kind of coding.” The Tweet mentions the scenarios where you can vibe code.

I “Accept All” always
I don’t read the diffs
no comment
throwaway weekend project
mostly works

This cannot work in a professional, high-stakes environment. If you’re trying to justify points #2 through #5, let me remind you that in a professional environment, you must have correct licensing for the code and any resource you use. You are in serious trouble if your organization or you use the code for which you do not hold a license or permissions. Points #2 through #5 don’t matter.

The author suggests a new approach to “throwaway weekend projects”: just test them to see if they can get off the ground.

The constraints

LLMs' biggest challenge is hallucination. In addition, AI is often bold in its claims and confident in its knowledge.

This is a common pattern with most platforms. Where the correctness of the information is checked based on available content. If majority population indicates one thing, that becomes a fact.

To tackle this, platforms offer constraints that can be applied to limit the LLM's actions. Take the Cursor rules, for example.

Hey, reader, a quick question.

Python Engineers: What is the preferred casing for methods?
Java Engineers: How do you ensure two Strings are equal?
C# Engineers: How do you indicate adding a build-breaking change in your packages?
Go Engineers: How do you mark a method private?

If you’ve worked in these languages for a while, you know [2] them at the back of your hands. I won’t need to tell you. I only need to tell you these if you’re new. Or if you’re a junior. If you’re a junior, I won’t ever let you change our production Firewall rules or the database schema.

Finally, this is not just with Cursor or Vibe coding. Almost every prompt has recently contained the part “if you’re unsure, explicitly state.”

Read this for examples of hallucinations.

Vibing the production

Tip: This section ties to the section 1000 juniors below. Read them together.

Vibing the production environment, or as in most cases, wiping the production. I don’t have to tell you why vibe coding your way to production can be a recipe for disaster. And don’t get me wrong, it’s not like humans don’t make mistakes. Seniors and staff-level personnel make mistakes and inadvertently disrupt the production environment. All. The. Time.

Here is an example, I prompted.

Create a class in TypeScript that has methods for average, mode, medium, sum, standard deviation, and document the type as well as the members. The class name must be MathUtils and the methods must be titled accordingly.

Here is the result from,

Before opening any of these links, what bugs do you expect in the generated code?

In all fairness, Gemini did a better job checking for the data than Copilot.

This is a very simple example of how LLMs do not have a standard. They “just do the job.” Of course, we can prompt the Copilot to correct the mistakes, and you can check in the thread that Copilot was able to find the error on the third prompt.

For another take on why adding vibe coding to your production environment is a bad idea, read this article on Medium: 99% of AI Startups Will Be Dead by 2026 — Here’s Why. The article discusses how the entire AI-assisted pipeline is likely to fail due to numerous failpoints and a lack of clear ownership. Only collaborators and “partners”.

Another similar story is from Klarna, where two years ago, they maintained a focus on being an AI-first company and underwent a restructuring. Now they’re hiring again, albeit with a different model, but indicating that humans will be needed. The back-to-human hiring spree might be here for now, but it is not guaranteed to last forever.

One of the most interesting—or scary for Chevrolet—stories is when the ChatBot was tricked to sell the vehicle for $1. Check out this AI Incident database for the story. The costs to fight such claims and to win back the trust of customers are not worth the “vibe”.

Long story short: don’t commit to what you don’t understand.

Is it just naming?

If you have computer science background, please proceed to the next header.

Computer folks are well known for bad naming. This is true at the code level. We ignore the first 8 letters until we find the perfect letter to be crowned the variable name. Because that is the first letter of the word “index”. But from there we don’t follow the same pattern of using the first letter of a sensible word, but use the next letters just to keep the train running… “j”, “k”, and so on.

We build the systems for the real world and often name our components after real-world elements or behaviors. Maybe this is the physically [3] correct thing to do. When we create a system that serves our users, we call it a “server”. The system that stores our data is called a “database”.

The system is inspired by the real world, but it is not the real world.

“Tech Debt” for the Rescue

A prime example of today is “tech debt”. There is tons of content about tech debt on the internet—on Substack, Medium, you name it. But here’s the homework. Ask randomly what tech debt is. There are two possible scenarios:

Everybody shakes their head, indicating they’re confused or want to learn more about it.
Everybody nods. Nobody knows.

The problem with tech debt is that we’re trying to research this term based on the real-world financial debt. We can’t because tech debt doesn’t have the same constraints as real-world financial debt. The day you told me that if an Engineer leaves tech debt in one company, the next company won’t hire them. I’ll admit.

Vibe coding is experiencing the same exposure. Everyone has their own understanding of the term vibe coding. Since 99% of Engineers write code, they understand it as using AI-assisted tools to write code. GitHub Copilot, Gemini Code Assist, Claude Code, and others are just examples. Vibe coding has become a synonym for prompting the LLM to generate the code, or document it, or produce unit tests for the code, and more.

It is interesting to note that vibe coding would produce more tech debt. To avoid such a situation, a guardrail is needed to prevent context loss. Cursor does that. In a scenario, Cursor refused to generate code for the user beyond 700-800 lines. The AI assistant tells the user to “learn programming” instead. I agree. But I do feel bad that you get your 700 lines of code, and then you are blocked. It feels like having to buy a DLC for a game to complete the story that you’re already invested in.

Vibe everything

It doesn’t take long before “everything” is slapped onto ongoing acronyms.

Guilty as charged. I used this heuristic in my book DevSecOps for .NET Core[4]. The most-read chapter from the book was chapter #4 Automating Everything as Code. I did not realize this until I saw that it was being cited in other research papers for the mention of the term “everything as code”.

In that chapter, the original intention I had to mention “everything as code” was to suggest to keep everything in record, thus Git it.

The same pattern would apply, and we would see tools that allow you to vibe on everything. Above in the article, I mentioned that the term vibe had nothing to do with LLM, or AI, or even smart, for that matter. The vibe in the original Tweet meant not to have to think about the internal implementation details, and focus on going from A to B, not thinking about how it takes you there.

I am not a good designer. I’m being honest. I do not know how to center a div. Suppose AI can do that for me. Please. But I do not expect AI to update the schema for my database. Maybe it can add logs to all my methods. Then add a condition to only print the logs in development mode.

I want my AI to do the drawings for me. Do the logo. Generate the UML diagrams. I am bad at that, so speed me up.

Before you say, but Afzaal, you said vibe coding is not AI-assisted work. That is true, but wait for the second part of the article where I talk about the Engineers who would lose their job.

1000 juniors

I’ve seen the use cases of LLMs and vibe coding in a few Products, and I think using an LLM is a very cheap and simple way to get junior workers. Think of student workers, interns, and contingent workers that you use to scale up repetitive tasks.

One thing I need to be extremely clear on. You cannot use LLMs or vibe coding for “innovative tasks”. That is where a human is needed. It’s not the first time an AI or a bot has taken over the job[5]. You should use AI to brainstorm ideas, get inspiration, or spar with some dilemmas. It is not like Engineers don’t do that already—look at the debug ducks as examples. It is known that a debug duck doesn’t have to be a duck; it can be your favorite plant.

You would not allow 1,000 juniors—or internees, no matter how diverse their experience and skills—to make changes to your platform or touch your customers' data without audit and guardrails. Why should you allow your LLM to touch it?

Should I?

In all honesty, please try it out. Download or install any of the Vibe coding platforms, extensions, or libraries, and just try it out. I’m sure you had an idea for a new app, or a product, or a platform this lunch… Or maybe when the lunch was on its way out. Try building that and try to get a basic MVP to work.

If you want a kickstarter, this article on Medium can be a good headstart for you to review the available vibe coding tools and then go enie meenie miney… Go.

Where I stand, I guess, since I am not looking to hire any junior developers, I do not need Vibe coding tools. That is not to say that I do not need assistance. Of course, I do, and I enjoy the IntelliSense in my Visual Studio. I do not remember the sort methods, or complex methods, and most of the time the IDE provides me with enough support to get it done.

But still… Where should I?

Hmmm, fine, but only since you insist. The following list is not an industry standard, but when you read around, you will identify a common pattern for using AI/AI-driven platforms.

1. Automation

The most notable use case of AI is to build automation. In your next stand-up, ask the question, “What is the one thing that you do manually? Repeatedly? In the same manner? Over and over again?” This could be refreshing the dashboards, syncing all the tickets and issues to your boards, cleaning up test databases, or anything if you have such a job that your team needs to do. That’s your first cue. Automate it with AI.

2. Guardrails

Once you’ve freed your Engineers from the manual chores, the next step is for Engineers to use this time to work with AI and build guardrails. Your webapps that don’t have test scenarios, unit tests, or other quality testing controls. Use the LLMs to bootstrap and add the boilerplate for you.

Your Engineers can go ahead and fill in the content and ensure the important test cases function as expected.

Remember: AI hallucinates. Whether a test passes or not and is of good quality as required by the business, is your call to make.

3. Non-production environment chores

I mentioned a few scenarios that do not impact your customers, such as resetting the test database, refreshing dashboards, or sending out emails. AI is a good candidate for these chores, even if a few do not have a guardrail.

You can also test new ventures for technical viability before developing the apps with the best polished frameworks.

4. Documentation

Engineers write code. Good engineers write code with documentation. Software Engineering is not a practice of pushing features out. It’s writing the code that other Engineers can read and maintain. But, it’s difficult and documentation is done on the last Friday of the month after the code has already been pushed to production. As soon as the feature is merged, the next ticket is prioritized, and the cycle continues. This is one of the biggest opportunities to use AI. Your AI tools can read the code, understand the context, and then restate it in the documentation as a comment.

It is also important to note that AI should generate the documentation for the choice you made, not the choices you did not. The AI-driven documentation is not a replacement for the decision documents, meetings, and architecture plans.

What’s next?

This is one side of the coin. The other side of the coin is, who will be the fall guy? LinkedIn is full of articles indicating that Software Engineering is done for. AI is here to take the jobs. But is it though?

The second side of the coin is about the Engineer who would lose their job to AI—coming soon.

References

1 Shout out to Microsoft Recall.

2 Alright, I admit. The first one was a trick question.

3 See Neil deGrasse Tyson break down the nomenclature used in Physics here on YouTube.

4 I published my book with Apress, covering the “Sec” focus in DevSecOps with the .NET Core framework. You can check it out here.

5 On a lighter note, check out this Thread on how Tom was the first guy to lose his job because of AI.