In the 1970s and 80s, I wrote everything myself.
From the era of mainframes to CP/M and BSD, nothing changed in that regard. Design, implementation, and operations all existed entirely within my own head. Code was simply an extension of thought.
In the 1990s, I became involved in ISP establishment support, largely uncharted territory at the time. That work eventually reached a natural conclusion, and once I began operating my own small-scale ISP, it became clear that a single person could no longer carry the entire system.
So I changed my approach.
I decomposed the system in my head into functional units and assigned them to graduate students in engineering at a nearby national university. The key point was that I did not hand over written specifications.
Instead, everything was driven through rigorous debate.
Structure, assumptions, edge cases, failure conditions —
we argued through all of it until there was no ambiguity left.
With highly capable people, this method is the most efficient.
Once they understand, they proceed autonomously in the correct direction.
This approach does not work with those who require documentation.
But even if you gather hundreds of such programmers, they cannot outperform a handful of people working in this way. That was my actual experience.
I oversaw the whole and handled only the necessary integrations.
Details were left to each individual, yet the structure never collapsed.
The result was extremely high productivity.
What is now called "vibe coding" seems essentially the same to me: advancing implementation by sharing direction and structure rather than issuing literal, step-by-step instructions.
Back then, I was simply doing it with humans instead of AI.
Some of the graduate students who worked with me at the time are now professors in engineering fields — not IT.
That is only natural.