Simplicity is not the opposite of complexity
Complex systems do not become simple because we hide their controls. Useful simplicity exposes the right boundaries, names the important pieces and leaves a path toward deeper understanding.
vladymir@home: ~/writing/
·2026-08-24-vibe-coding.md·2026-08-23-computer-became-a-place-again.md·2026-08-20-freebsd.md·2026-08-17-knowledge-belief.md·2026-08-12-small-software.md·2026-08-04-computer-son.md·2026-07-29-simplicity-complexity.md
7 articles — select one to read
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.
For now, almost everything is still halfway done. The workstation is still waiting for its case. The TV box became an experiment before it became anything useful. The local network keeps changing. The rack already exists, but it is still being organized. The cloud infrastructure grows in parallel. Nothing is really ready. And maybe that is the most interesting part.
For a long time, my computer kept mattering less. The browser became the interface. The servers went to the cloud. Software became a service. The machine on the desk became mostly a way to reach computers somewhere else.
Lately I have been going the other way. I want to run my own models locally. I want to build agents from scratch. To understand the loop. To understand memory. To understand how tools are chosen. To understand what an agent knows, what it inferred and what it only assumed. I want these things to run on machines I control.
That is when the network, the servers, FreeBSD, OpenBSD, jails, WireGuard, the rack, used parts, a TV box I decided to try turning into Linux, ESP32s scattered across the desk and too many plans for too few outlets started to appear.
At some point the workstation appeared. It is not even finished being assembled. But its role is already clear.
I do not just want a faster computer. I want a machine I can understand, modify, break, fix and reshape for whatever comes next. A machine where I can compile software, boot a VM, run a model, write an agent, test a network and then tear half of it down because a better idea came along.
Around it, other things are taking shape. Local infrastructure. Cloud infrastructure. Repurposed machines. Networking. Electronics. Models. Agents. Software. Some of these will work. Others will probably be taken apart. Some may never get past being an experiment.
I have been documenting part of this process here. Not as finished projects. More as traces of things being built.
The workstation is not ready yet. Neither is the lab. The agents even less so. Good.
Twenty-five years ago, at sixteen, I first tried FreeBSD. I had come from Slackware, where simplicity was the point, and FreeBSD felt the same: one system, built together, nothing extra between you and the machine. I liked it immediately and never quite unlearned it.
For years I worked with other things. Then, on purpose, I decided to go back to the origins — the Unix philosophy and the fundamentals. I started reading FreeBSD's internals, the VFS layer and the vnode, how a file really works. Understanding how the pieces fit made the machine legible again.
Two practical reasons closed the decision. ZFS, because a filesystem should have a memory — snapshots, checksums, a mistake that can be undone. And jails, because isolation should not mean running a second operating system for every service.
So the plan is simple: host as much as I can inside jails, on ZFS, and keep following that philosophy. Small, legible, assembled from parts I can still see.
Belief can be stubborn; knowledge has to remain answerable to evidence. The interesting part is not sounding certain, but building habits that let us notice when reality disagrees.
Small software can be read in an afternoon, moved without ceremony and repaired by the person who depends on it. Its modest scale is not a lack of ambition; it is an invitation to ownership.
We built the computer slowly enough to ask what each part did. By the time it booted, the result was not merely a working machine but a map of questions we could continue exploring together.
Complex systems do not become simple because we hide their controls. Useful simplicity exposes the right boundaries, names the important pieces and leaves a path toward deeper understanding.