Beyond “Vibe Coding”

From time to time, I see people dismiss what is often called vibe coding. The term itself already carries a hint of irony. It suggests improvisation, shortcuts, perhaps even a lack of seriousness. Personally, I have never used the term. Not because I object to the practice, but because the label feels inaccurate.

Vector mosaic algorithms apply concentric circular grids to a source image. Part of my CGMCreator app is currently under development, built with the help of multiple LLMs and a diverse team of programmers, designers, and beautifully logical and emotional human minds.

My goal has never really been coding.

Coding is only a language. One of the many ways humans have invented to communicate with machines. Useful, powerful, sometimes even beautiful. But still a language.

The real goal is to build a system that does something meaningful.

Sometimes, a program itself can be admired like a piece of art. Many engineers speak about elegant code with the same affection a poet reserves for a well-crafted verse. I understand that feeling very well.

When I was young, my father tried to introduce me to the beauty of technology. He would show me old electrical relays and vacuum tubes. Small objects, almost humble in appearance. Yet we could spend hours looking at them, their geometry, their logic, the delicate balance between electricity and mechanics.

There was poetry there.

But of course, the engineers who designed those relays did not build them so that two curious people could admire them decades later. They built them to serve something larger: a radio, a control system, a communication device, a machine that solved a problem somewhere in the world.

The component was beautiful. But the beauty was in the service of usefulness.

Before transistors, machines relied on electromagnetic relays. Pictured here are a single relay unit (left) and a sophisticated multi-relay assembly (right), similar to those found in machines such as the Harvard Mark I. (CC Wikipedia).

This pattern recurs throughout human history. We build tools, then we build tools that simplify those tools. We create layers that allow the next generation to start from a slightly higher point.

Machine language gave way to assembly. Assembly gave way to programming languages. Then came compilers, frameworks, libraries, visual tools, and now AI assistants.

At every step, someone declared that the new abstraction would weaken the craft. And sometimes that concern was not entirely wrong. But abstractions also do something remarkable: they allow more people to participate in building systems.

I deeply admire the engineers who understand every layer of the stack, from the physical circuitry to the most abstract architecture. Their knowledge is rare and incredibly valuable. Without them, the entire technological ecosystem would collapse.

Yet our time as humans is limited. None of us can master everything with the same depth: physics, electronics, operating systems, algorithms, psychology, design, and language.

Pintori is an operating system for creative work, built to turn scattered ideas into a clear, living workflow. Inspired by Giovanni Pintori’s precision and visual intelligence, it aims to unify notes, references, tasks, archives, and publishing into one elegant environment where design thinking guides every action. Instead of forcing rigid productivity habits, Pintori is trying to become a studio companion: structured enough to keep momentum, flexible enough to let intuition lead.

So humanity constantly invents ways to simplify complexity. Some people will use these simplifications out of laziness. That has always happened. Others will use them as a doorway.

They might begin by describing a system in human language to an AI assistant. Later, they may become curious about the architecture behind it. Eventually, they may learn the deeper layers that make everything work.

If we need a term for this practice, I would probably call it LLM-assisted development rather than vibe coding.

Terminology is important. Because it gives our brain a direction. 

Therefore, the importance isn’t so much in how people communicate with a system to build an application. What matters is what people build, and whether those systems actually help someone, somewhere.

Because in the long run, technology is rarely judged by the purity of its method.

It is judged by the usefulness of its results and by the quiet verdict of time.