Vibe coding
I have a small confession to make.
I vibe coded this site.
That is a little embarrassing for someone like me.
I spent decades using Unix, writing code, configuring machines, breaking systems, reading man pages and believing — maybe with a certain pride — that understanding things mattered.
I still believe that.
a computer used to feel closer
I did not program this site the old way
I talked about it.
I described what I wanted.
I asked for changes.
I rejected ideas.
I compared references.
Very modern.
Very cyberpunk.
Not very Unix.
Too much like a toy operating system.
I kept adjusting until I recognized something of my own on the screen.
A good part of the code was written by an AI.
And that bothers me a little.
Not because I think there is any special virtue in typing CSS by hand.
But because programming, for me, has always been tied to a particular kind of intimacy with the machine.
You think.
You write.
The machine does something else.
You find out why.
There is knowledge in that friction.
PLACEHOLDER — somewhere underneath
With vibe coding, part of that friction disappears.
Intent no longer reaches the code directly.
Now there is something in between.
Before, I expressed intent in code.
Now I can also express intent about code.
That difference seems small until you start working this way.
At some point I realized I was no longer saying exactly how to implement things.
I was saying what should exist.
I want this to look like an old Unix workstation.
less cyberpunk.
Plan 9 should be drier.
this text doesn't belong in the Lab.
the theme needs to change the identity
without changing the whole site.
That looks less like programming a machine and more like talking to another programmer.
Ideas that stayed in the drawer
Maybe that is why I have been producing so much lately.
I always had more ideas than time to implement them.
Some became notes.
Others became small toy projects.
Many died before even reaching the editor.
Not always for lack of interest.
Sometimes I simply knew the size of the work that came after the idea.
And life has other things.
Work.
Home.
Family.
A finite amount of nights and weekends.
There is a particular kind of project you postpone not because you do not want to do it, but because you know too well the cost of doing it right.
AI lowered that cost of starting.
It did not make ideas automatically good.
It did not eliminate decisions.
It did not create more hours in the day.
But it shrank the distance between:
that would be interesting
and
there is something working in front of me.
That changed my behavior.
I have been able to get out ideas that probably would have stayed as text files, diagrams or loose thoughts.
Some of them will die later.
Others will become real projects.
But now they have the chance to exist long enough for me to find out which of the two they are.
Maybe that is, for me, the most seductive part of vibe coding.
Not writing software faster.
Giving an initial shape to ideas that would not have survived the cost of starting before.
So who made the site?
The question appears sooner or later.
Did I make this site?
I do not know if there is a simple answer.
I could not point to all the lines written by the model.
But I know why there are four themes.
I know why one of them is called Workstation.
I know why I do not want too much neon.
I know why there is a Lab.
I know why a broken TV box deserves a page.
I know why certain things belong in Writing and others in Notes.
I know why I am writing this text.
vladymir.info, 2026
The intent is still mine.
But the translation of that intent into code moved somewhere else.
Maybe authorship moved somewhere else too.
One more abstraction
There is an easy way to discuss vibe coding:
ask whether it is still programming.
I do not know if that is the most interesting question.
Abstractions have always changed the distance between intent and machine.
machine code
↓
assembly
↓
C
↓
libraries
↓
frameworks
↓
...
Each layer let us say less about how and more about what.
AI seems to continue that movement.
But there is a strange difference.
This abstraction answers back.
You can argue with it.
You can say a solution is wrong without knowing exactly where.
You can ask for another one.
You can say:
not that.
simpler.
less pretty.
weirder.
now it's worse.
go back.
And something happens.
intent
↓
language
↓
model
↓
code
↓
machine
The dangerous part
A model fills gaps.
That is exactly what makes it useful.
But those gaps are also decisions.
Structure.
Names.
Dependencies.
Behavior.
Aesthetics.
Assumptions.
The less code I write directly, the more I need to notice when a decision stopped being mine.
It is easy to accept an abstraction.
It is harder to notice when the abstraction started choosing for you.
Maybe that is the part of vibe coding that interests me the most.
Not the possibility of generating code quickly.
But the need to keep intent while something else implements parts of it.
The work changes shape
You write fewer instructions for the machine.
You spend more time describing boundaries.
Saying no.
Recognizing when something is almost right, but not yet yours.
And, curiously, that also lets you experiment more.
Ideas that are cheap to test can stay small.
Toy projects can stay toy projects.
Not every curiosity needs to justify weeks of implementation before showing whether there was anything there.
That, for me, is an important change.
Maybe programming has always been a bit of this.
It just became more visible now.
This site was vibe coded.
I cannot point to all the lines written by the model.
But I know why there are four themes.
I know why one of them is called Workstation.
I know why I do not want too much neon.
I know why there is a Lab.
I know why a broken TV box deserves a page.
I know why I am writing this text.
The code may not be entirely mine.
The site is.
