Vibe coding definition has become outdated. Long live vibe programming?

I come from a past of 80x25 black terminal screens, keyboards without USB, and even times when mice weren't common. Back then, the term "programmer" was more widely adopted, while "coder" was used as an alternative concept. At least until a whiff of the corporate world wrapped us in a "Developer" label, flavored somewhat with Java and somewhat with Microsoft.

With this article, I'll try to sketch out how patterns repeat in history, and how the vibe coding revolution is bringing us back to the concept of programming.

Coding?

Let's start with the basics...

Code is essentially the expression or expressions we use to trigger a function of any electronic device. Actually, if I give an "assembly code" example, I think it will serve as a bridge between the world of devices (hardware) and programming languages, here you go:

MOV AH, 09h       ; DOS function: print string
MOV DX, msg       ; Load string address into DX
INT 21h           ; Call (execute) DOS interrupt

MOV AH, 4Ch       ; DOS function: exit program
INT 21h           ; Execute

msg DB 'Hi!$'     ; String to be printed ($ = terminator)

Writing these in sequence like this is a "coding" action. The output of what we do is the "code" itself.

Programming?

Programming, on the other hand, is a more result-oriented concept. You might not be able to code your home oven or refrigerator, but you can program them.

Because programming is an action related to configuring a device to your desired settings, making it do what you want.

When I say "you can program your oven using the temperature setting," you'll probably experience disappointment while reading, but bear with me. While an oven gives you an interface with 2-3 variables, programming a computer system is a topic with distances as vast as jumping from the stone age to the space age. I'm reducing my example mostly for the sake of understanding the subject.

Think of it more like mathematics: you can either add 2 and 2, or you can perform complex calculations that require very high processing capacities that give life to 3D models today and enable artificial intelligence.

In programming, you may need to master tons of dynamics and "align," "adjust" these dynamics to your requirements in order to get a computer system to produce "the output you desire."

Programming doesn't just stop at programming a computer system; it creates new "abstract" concepts and layers like "data layer" and "queue system," and enables programming those as well.

As you create layers and position them according to the plane on which your program will run (this can even be across devices), you're doing an "architectural" design;

...And when you do programming at this scale in a "formal" manner according to certain calculations, records, literature, and understanding, you're also doing "engineering."

What's the difference between coding and programming?

Although we don't use it much anymore, a generation ago the profile we called a "coder" was mostly someone who wrote code as a hobby, who didn't master the entirety of systems but took code snippets they read in magazines and ran them on their own computer, who wrote themselves small alarm and calendar software and customized them. I know because I started as one of them! I could even be called a script kiddie, but I won't go into that concept. The curious can research it.

A programmer, on the other hand, was a profile that went beyond hobby, was proficient with computer systems, could produce things themselves, could create a solution in their mind and realize it through "coding." Programming and the concept of "developer" were forgotten and became unused. Perhaps one day we'll address the developer concept as well.

Returning to the essence of the matter and summarizing even further:

• Coding = expression production
• Programming = behavior design

So today?

Today there's a popular concept on everyone's lips: "vibe coding." Vibe coding emerged first inside the IDE thanks to Cursor, and started transforming the functions we wrote as comments in the middle of coding actions into code through auto-complete/intellisense (Cursor Tab)-like features. Together with Cursor's Composer, we gradually transitioned from seeing an AI tool inside code to seeing code inside an AI tool.

I'm aware that the concept of vibe coding, as if it were the antithesis of "Software Engineering," is about producing code without plans, without programs, "according to our vibes, however we feel." While on one side there's jazz arithmetic, the other is pointing to punk. As long as the output approaches what's wanted, it's sufficient. For that reason, I won't expand the concept by adding a crowd that's already fully aware of what they're building to the "vibe coder" action.

Besides, if you think I'm a gatekeeper hostile to vibe coding as someone who spent years writing code extensively, you're mistaken. On the contrary, just as TDD is a "methodology" when writing those codes, I see vibe coding as a methodology where "intention comes before code," and I use it extensively.

My point only indicates the development of tools. What enabled vibe coder work was the models of incoming prompts advancing in the agentic loop toward results, also using what we call Tool Use. But both tools that entered "Tool Use" and the repertoire of models expanded so much that... as I pointed out in the Cursor example, models can demonstrate capabilities beyond "code" in response to prompts.

Therefore, now with a "vibe" approach, we can not only produce or modify code, but thanks to evolving tools, we've become able to use the computer to program it to produce the output we want.

Simple and Advanced Examples

Let me give two examples, one theoretical and one more from the industry:

Today, using any average-level agentic tool, the probability of success for a prompt like "find 10 superhero-themed images from the internet, turn it into a video with background music close to John Williams' compositions, and email it to my cousin" is quite high. We're not producing code here. Actually, we're programming the computer's capabilities to accomplish what we want. Maybe it's writing a script, maybe it's a single-use or multi-use configuration involving many different components from downloads to ffmpeg, from web searches to email calls—handling such complex work goes beyond the scope of coding.

The other example is that in the startup I currently work at, there are colleagues who use Opus 4.5 with Claude Code / Kiro but haven't gotten their hands dirty on the Kubernetes side before. Even though they're amazing developers, operationally, the moment Kubernetes puts an obstacle in front of them, they write prompts like "why am I getting no healthy upstream when I deploy?" to that Kiro window. Five years ago, that would have been a world where everyone downloaded kubectl, read the Kubernetes Manual, and sent "can you come over?" private messages to the Seniors on the team—completely different from the behavior schema described by "vibe coding" that we can observe here. But again, here too there's a world with configurations, live pod/deployment CPU/memory resources controlled with commands, so this is a programming activity, not a coding one.

In conclusion: When Karpathy named the subject last year, "vibe coding" was an accurate definition. But as tools became more powerful, what we could do with the "vibe" approach made it clear that the term itself needed a similar expansion.