I think I've found a kindred spirit on the other side of the planet.
The essay is called Vibe Coding, 30 Years Ago, by Yutaka Tomii, in the engineering journal of Gratice, which publishes from Osaka. It's about three hundred words long, and the first line is the whole argument: "In the 1990s, I was doing it with humans instead of AI."
Tomii wrote everything personally through the 1970s and 80s, from mainframes to CP/M and BSD. "Code was simply an extension of thought." Then, in the 1990s, came a small ISP of his own, and the system got too big for one person to carry. So he split it into functional units and handed those to engineering graduate students at a nearby national university. What he didn't hand over was a written spec. Everything was argued out instead: "Structure, assumptions, edge cases, failure conditions — we argued through all of it until there was no ambiguity left." Tomii kept the whole system in view and did the integrations. Everything else was left to the individual students, and "the structure never collapsed."
In September I wrote AI Is Not the Solution. It's the Tool. My argument was that today's backlash against AI is the 1998 backlash against Google with the nouns swapped. I also described how I use AI: "the way I'd use a very fast, occasionally wrong junior engineer." And I said I still read all of it, and I still own it.
Put the two pieces side by side and you get two people who have been doing this since the 1970s and since 1994, sixteen time zones apart, who ended up in the same place. Neither of us thinks the new thing is new. And we both put the value in the same spot. It isn't in the typing. It's in holding the structure.
Where we agree
The shape is the job. Tomii "decomposed the system in my head into functional units." I keep the architecture and let the tool draft the migration script. In both cases the person in charge decides what the parts are, where they meet and what happens when one of them fails. The integration is the work. The rest is labor.
Direction beats instructions. Tomii's definition of vibe coding is "advancing implementation by sharing direction and structure rather than issuing literal, step-by-step instructions." That's how working with AI goes for me on a good day. I lay out the problem, the constraints, where the piece plugs in and what it must not break. If I find myself giving step-by-step instructions, I'm just typing the code myself with extra steps.
A handful beats a crowd. "Even if you gather hundreds of such programmers, they cannot outperform a handful of people working in this way." I believed that before AI and I believe it more now. Most of what I've shipped this year, a mail server fork with its console and webmail, and a certification study site, was built with this kind of tool in the loop. It held together for the same reason Tomii's ISP did. The structure was settled before anyone typed.
It's also worth noticing that Tomii is being generous with the term. When Andrej Karpathy coined "vibe coding" in February 2025, he described it as giving in to the vibes and forgetting "that the code even exists." Tomii describes the opposite: arguing "until there was no ambiguity left." The popular version skips exactly the part Tomii says made the method work. I'd like the generous meaning to win.
Where it breaks
There's one line in the essay I can't say about AI: "Once they understand, they proceed autonomously in the correct direction."
A graduate student who has argued with you until there's no ambiguity left actually understands. They carry that understanding into next week. They notice when a later decision contradicts an earlier one, and they come back and argue again. A model gives you something that looks exactly like understanding. It will repeat your structure back fluently, then break one of your assumptions three files later in the same confident voice. And unless you write things down, the next session starts from nothing.
Tomii also says the method "does not work with those who require documentation." That's the irony. The AI is the collaborator that requires documentation. I now write down decisions I'd never have had to write down for a person, because the one I'm working with won't remember them.
That's why the details can't be left alone. Tomii could leave details to each student because the students had earned it. With AI, reading every line is the price of the speed. And when I can't review something, the honest thing is to say so. When ihasmail got nine machine-translated languages, I couldn't read any of them, so the app says so, in each language. That isn't a weakness of the method. It's the method working: you know which parts of the structure you're actually holding.
The professors
The essay ends with the line that has stuck with me most. Some of those graduate students are now professors, in engineering fields but not in IT. "That is only natural."
It is natural. Arguing about failure conditions with someone who has run real systems for twenty years is how you become someone who can run them too. The method shipped an ISP, and it also turned out the next generation of engineers.
The model doesn't grow up to be a professor. Whatever it picks up from our argument doesn't come back in twenty years as an engineer who can hold a structure of their own. That worries me more than AI slop does. If the very fast junior engineer replaces the actual junior engineer, who will be doing the arguing in 2045?
In September I said the people who get left behind will be the ones who refuse to build any fluency with these tools. I still think that. Here's what I'd add now: the teams that do well over the long run will be the ones that still hire graduate students and argue with them.
Learn the tool. Keep the judgment yours. And keep a few people around to argue with, because that's where judgment comes from. Thank you to Yutaka Tomii for saying all of that in three hundred words, and for saying it thirty years early.