Last Saturday I sat at the dining table in Bangalore with twenty files open. Each file was a SKILL.md. Each one told Claude Code how to do one job for the bakery: how to compile WhatsApp orders, how to send payment links through Razorpay, how to write a blog post in the voice of Fika B’lore, how to close the monthly books and email them to the CA. I had built these files over weeks. On that Saturday I was sorting them into three tiers, labeling which model Claude should run them on. Opus for the creative work. Sonnet for the procedural. Haiku for the lookups. I tagged each file in its frontmatter and moved on.
Halfway through the third file, I realized what I was doing. I had done this work before, with suppliers. For twenty years, actually. Line cards. RACI charts. Process FMEAs. Routing tables. Decide what is common, what is specific. Decide which rule belongs to which operator. Decide the altitude of the instruction. I had written a supply chain configuration, not a software configuration. I had just written it for a new kind of vendor.
This is what I want to talk about. Because a year into the “vibe coding” conversation, almost no one is calling it by the right name.
The two framings, both slightly off
On February 6, 2025, Andrej Karpathy posted a tweet that now has 4.5 million views. He called it vibe coding. “You fully give in to the vibes,” he wrote, “embrace exponentials, and forget that the code even exists.” He described accepting diffs without reading them, copy-pasting error messages back into the chat, shipping whatever worked. The phrase landed because it gave a name to something many people were already doing. It also alarmed serious software engineers, which was probably the point.
Eight months later, in October 2025, Simon Willison pushed back with “vibe engineering”. His version is the grown-up one. “Vibe coding is the fast, loose and irresponsible way of building software with AI,” he wrote. Vibe engineering is the opposite: “seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce.” In other words: if you want AI to help you build real things, be a real engineer first.
Both framings capture something true. Neither gets to the shift I have actually experienced, and I do not think they will hold up. The axis is not how loose or how tight your process is. It is whether you can describe your own operations clearly enough that a machine can execute them.
Ethan Mollick put it most cleanly in his January 2026 essay on management as an AI superpower. “What’s scarce is knowing what to ask for.” The next sentence is the one that matters. “The people who thrive will be the ones who know what good looks like, and can explain it clearly.”
That is not coding. That is not engineering. That is specification.
That is not coding. That is not engineering. That is specification.
The gap is wider than it looks
Jeff Sauer runs an analytics education company called MeasureU. In a 2025 post that circulated well outside his normal audience, he described rebuilding his entire platform in eleven days: the website, ten courses, eleven workshops, every sales page, every checkout flow. The earlier scope had been six months and north of fifty thousand dollars. His team had no developers. The person who rebuilt the CRM and sales pipeline, he wrote, “designed it, spec’d it, had Claude execute it.”
Spec’d it. That verb is quietly doing the whole work of the case study.
In October 2025, Wells Fargo’s chief equity strategist Ohsung Kwon published a comparison I have not been able to stop thinking about. Since ChatGPT’s late-2022 launch, real revenue per worker on the S&P 500 was up 5.5 percent. The same measure on the Russell 2000 was down 12.3 percent. Larger firms were putting AI into actual operations and compounding. Smaller firms were subscribing to chatbots and stagnating. The divide he called out was not between companies that had AI and companies that did not. By late 2025 that line had more or less dissolved. The divide was between companies that had turned AI into a system and the ones that had turned it into a tool.
The failure mode of the subscriber is almost always the same. They can write a good prompt for a meeting summary. They cannot describe their own invoice workflow well enough for a machine to automate it. The skill they are missing is not technical. It is observational. They have never sat down and watched what actually happens when a customer places an order in their own company, and then written it down.
A supply chain manager can feel this gap from a hundred metres away. We have been writing down how work happens for four decades, because ERP implementations do not configure themselves and nothing in a warehouse runs without instructions somebody wrote on paper. The work of “pick a receiver, specify the inputs, specify the outputs, specify the exceptions, specify the escalation path” is not new. What is new is that one of the receivers can now be a language model.
The honest concession
There is a cost to my framing that I should name.
METR, a research organization that runs careful evaluations of AI systems, published a randomized controlled trial in July 2025 that should make any specification evangelist pause. Sixteen experienced open-source developers, 246 tasks, frontier models. Result: AI access made them 19 percent slower on average. Their own perception was that they had been 20 percent faster. The gap between experience and reality was the widest I have seen in a study of this kind.
One reading is: specification does not save you. Another reading, which I find more persuasive and which sits in METR’s own discussion, is that the slowdown happened where the tasks were complex and the prompts were, to quote the researchers, “overly simple.” That is not a failure of AI. That is a failure of specification. When you skip the step of telling the machine what good looks like, you end up reviewing output that does not match what you wanted, which is slower than writing the thing yourself.
The sharper concession is this: you can over-specify. A forty-page SOP handed to an LLM produces worse output than a five-line intent statement handed to someone who understands the goal. I have watched this happen. The first version of my blog writing skill was nine pages of rules. Claude wrote turgid, rule-salad posts. I cut it to three pages of voice examples and a short list of bans. The posts became readable. Specification, done badly, is worse than no specification at all.
Which brings me to what the supply chain profession actually trains you for. Not to write more rules. To write rules at the right altitude. Know when to specify the exact step, and when to describe the desired outcome and let the operator figure out the rest. Know when to codify the checklist, and when to preserve the judgment call. This is the art. It is not a discipline anyone from the AI industry invented in 2025. Atul Gawande wrote a book about it in 2009 called The Checklist Manifesto, and he was writing about surgery, not software. The WHO 19-point surgical checklist cut major complications by 36 percent across eight hospitals globally. A longer checklist would have made things worse.
This has happened before
Every twenty or thirty years, the same shape of shift runs through business. It looked like Lotus 1-2-3 in 1983. By 1987, one in four of the fifteen million Americans using a PC at work was running 1-2-3, and the leveraged buyout boom that reshaped that decade ran on spreadsheets built by analysts, not by IT departments. IT did not recover ownership of business modeling after that.
In 1993, Microsoft introduced VBA in Excel 5.0, and operations staff who had been Excel users became Excel programmers. Nobody called it vibe coding. They called it “the finance team’s workbook.”
Before that there were CNC machinists who learned to write their own tool paths rather than send them to an engineer. Before that, the original system administrators who wrote job control scripts on mainframes. Before all of them, there was Auguste Escoffier, who in 1903 published Le Guide Culinaire: five thousand professional recipes, each one a compact specification, each one an act of converting a specific chef’s tacit knowledge into a form that could travel to any competent kitchen in the world. The brigade system was the RACI chart. The guide was the SOP library. French cooking spread the way it did because he wrote it down.
Michael Polanyi called this “externalization” in 1966. Ikujiro Nonaka built an entire theory of how companies create knowledge on the same concept thirty years later. The move from tacit to explicit is where organizations compound. It is also the rarest move. Most people who know how to do something have never written down how they do it, because writing it down feels slower than just doing it. Until someone else, or something else, needs to do it too.
The unfair quadrant
The quadrant I think a lot of people are missing is small.
There are engineers who can build with AI. There are operators who use AI. There are engineers who understand operations, which is rare. And there are operators who can specify their work with the precision of an engineer, which is rarer. The last group sits in the most useful corner of that grid, and almost nothing in the current AI discourse is written for them, because most of the current AI discourse is written by people who came in through code.
I say this from the corner. I have no engineering background. I cannot write Go. I can write a specification. And when I drop that specification into a system that can execute it, what comes back is software that runs my bakery.
Today is Monday, April 20. The kitchen in Bettahalsoor, about fifty kilometres north of where I am sitting, produced 180 saffron buns this morning so our delivery van can leave on Wednesday instead of Friday. We just moved the weekly cadence from Friday-only to Wednesday and Friday. Three hundred and thirteen customers are on the list. Leanne, who started as our baker in January, wrote a recipe document that specifies every dough weight, every proving time, every hydration ratio, and which of those numbers grow linearly with batch size and which ones not to. She is a baker, not a software engineer. She writes specifications.
Niklas and I have a skill library with twenty skills, a credentials file, a webhook pipeline on Google Cloud Functions, a Razorpay integration that went live six days ago. None of this was built by a developer. It was built by two operators writing down what they wanted, at the right altitude, until a machine could execute it.
The question I am still sitting with
The thing I cannot let go of is this: supply chain managers, operations directors, industrial engineers, manufacturing planners, the entire boring middle layer of global business, have been doing this for forty years. Quietly. Unglamorously. Writing the instructions that make the physical world move. It was never a sexy job. Nobody optioned any movies about it.
Now it is the skill of the moment, and I watch the AI conversation reinvent vocabulary my profession has used for decades. Context engineering. Spec-driven development. Intent capture. These are things we called work instructions and control plans.
I do not quite know what to do with that. Part of me thinks it is the single biggest career opportunity of my generation for anyone who came up through operations. Part of me suspects the gap closes quickly, that agents will get good at eliciting requirements the way a decent consultant does, and the advantage shrinks to twelve or twenty-four months.
But there is a quieter question underneath the strategic one. If this is true, what does it mean for the people who never learned to write down their own work? The knowledge economy always had a hidden cost for them. The allocation economy, as Dan Shipper called it, has a sharper one. You do not get to hire the machine if you cannot tell it what you want.
I think often about the difference between Karpathy’s framing, where you give in to the vibes and forget the code exists, and the version of the same work that happens in every reasonable kitchen every morning. The baker does not forget the recipe exists. She wrote it down last week. That is why someone else can help her bake.