ROSHEDEN

Category: AI in Practice

What I built, how, why, and what happened

  • The Operating System Is Not the Moat

    Last Saturday I sat in Obsidian and created seven notes. One each for Tarento, Trelleborg, Wibe Group, Autoliv, Elof Hansson, EMPE Diagnostics, Bluefish Pharmaceuticals. Swedish companies with offices in Bangalore. Each note had a status field, a priority field, a source field, a contact name I did not yet have. I typed them out manually. None of my twenty skills could help me. The AI operating system I had spent six months building was useless here, because this was not a process to be executed. This was a second channel to be constructed.

    I had been avoiding this work for many weeks.

    The reason is quietly embarrassing for a supply chain guy who spent twenty years advising companies on single-supplier risk. Fika B’lore has one distribution channel. Ten WhatsApp communities, three hundred and thirteen customers, one hundred and eighty orders a week, zero physical retail, no Swiggy, no Zomato, no wholesale contracts worth the name. The WhatsApp pipeline is beautiful. It is also, viewed through the lens of the thing I am supposedly building toward, a liability.

    The goal is to be acquisition-ready by August 2027. That is fifteen months from today. And somewhere around the fifth Obsidian note, it became clear that the single biggest threat to that goal is not a skill I haven’t written yet. It is the fact that I have been pointing my attention at the operating system and not at the thing the operating system is supposed to defend.

    The diligence room

    Here is the scene I keep running in my head.

    A private equity associate, two years out of an MBA, is doing the first read on Fika B’lore. She has a template. The template is more or less the one ChrysCapital used when they acquired 90 percent of Theobroma Foods in July 2025 for 2,410 crore rupees, about 275 million dollars. She is looking at the revenue breakdown. Channel split, she notes. And then she sees what I see every Monday: one hundred percent through WhatsApp community groups managed by two co-founders.

    The template has a number for this. John Warrillow, who spent fifteen years studying what makes small and mid-sized businesses actually sellable, calls it the Switzerland Structure. “Try to work your customer concentration down to a point where your largest customer represents no more than 15 percent of your revenue,” his Built to Sell system recommends. Above 20 percent, the deal softens. Above 30 percent, according to FOCUS Investment Bankers, “transaction valuations can be substantially reduced, perhaps 20 to 35 percent.” Above roughly that line, many PE firms decline entirely.

    Here is the thing the associate’s template does not do. It does not distinguish between a customer that is 100 percent of your revenue and a channel that is 100 percent of your revenue. It treats them as the same category of risk, because they are. The question she is asked to answer is not “who pays you.” It is “how quickly and how catastrophically could this revenue disappear.” A single channel answers both questions identically to a single customer.

    I have been building, with real pleasure and real skill, the wrong asset.

    I have been building, with real pleasure and real skill, the wrong asset.

    The thing I keep missing

    The uncomfortable part is that I know better.

    I have written single-sourcing risk assessments for Tier-1 suppliers. I have built dual-sourcing strategies for Swedish multinationals. The Swedish word for this kind of dependency, rävsax, captures it better than English: a trap you willingly step into, where the jaws snap shut, leaving you entirely at the mercy of your environment

    I have been running my own bakery stuck in a rävsax and calling it a strategy.

    The operating system is not nothing. Building it was not a mistake. A 2025 FTI Consulting survey cited by EisnerAmper found that 59 percent of PE funds now rank AI as a top driver of value creation, and they give examples of businesses whose EBITDA multiples moved from 7x to 9x after AI implementations in forecasting and operations. The EisnerAmper report says it plainly: “Strong metrics get companies into the conversation; technology and positioning determine whether buyers lean in.” The operating system is a multiplier on the right underlying assets. It is not the asset itself.

    The honest concession

    There are counter-examples I cannot wave away, and it would be dishonest to write this essay without taking them seriously.

    In 2012, Starbucks paid $100 million for La Boulange, a 19-outlet San Francisco bakery chain founded by a French baker named Pascal Rigo. Within three years Starbucks had closed every retail location. What they wanted was not the channel. They wanted the recipes and the brand signal. The entire acquisition value, once the reporting chrome was scraped off, was the intellectual property. A single-channel artisan bakery delivered a nine-figure exit by being the thing worth stealing, not the thing worth buying.

    In August 2020, General Atlantic valued Gymshark at over a billion dollars. At that point Gymshark was a decade-old DTC fitness brand that had grown primarily through Instagram, influencer seeding, and a community of athlete ambassadors. The diligence team knew exactly what they were paying for. Not distribution breadth. The community itself, unit economics that held under pressure, and what Jason Cohen calls the “mutually reinforcing” operating logic no competitor could replicate cheaply.

    Both cases say: the channel is not always the point.

    What unites the cases that worked is that something other than the operating system was also durable. La Boulange had recipes people would pay to steal. Gymshark had a community that belonged to the brand rather than to the platform. In both, the buyer could answer a question the diligence template does not name but always quietly asks: if we took away the current channel tomorrow, would the demand still be there?

    That is the real test. Not channel count. Channel independence.

    The chicken farmer

    There is a metaphor that has been sitting on my desk for a week and I cannot stop coming back to it.

    In 1950, ninety-five percent of chicken farms in the United States were independent. Farmers owned the birds, sold into open markets, negotiated with multiple buyers. Five years later, the number was ten percent. Today, over ninety percent of American chicken production runs through contract grower relationships with vertical integrators. A 2011 USDA survey found that 21.7 percent of contract growers had exactly one integrator in their area with whom they could sign.

    The farmer builds a poultry house, a purpose-built structure designed around a specific integrator’s birds, feed system, biosecurity protocols. The shed is operationally excellent, modern, efficient, profitable for as long as the contract runs. The problem is the asset. A poultry house has no alternative use. If the integrator terminates the contract, the farmer does not lose a buyer. The farmer loses the ability to use the asset at all.

    I am not a chicken farmer. I am also not as different from one as I would like to be. Meta owns the pipe, and that would be true of any platform a business rests on. Terms change, policies tighten, reach gets throttled, algorithms shift. The specifics matter less than the structural fact: the asset I have built, elegant as it is, has one narrow mouth to feed through, and I do not own the mouth. Resilience is not about distrusting the platform. It is about not being one policy change from silence.

    What Theobroma actually sold

    The deal most often cited as evidence that Indian bakeries are now acquirable is Theobroma. The number is real. The path is worth sitting with.

    Theobroma opened its first store in 2004, on Colaba Causeway in Mumbai. For six years, that was the entire business. One outlet. No second location until 2010. ICICI Venture invested in 2017, taking a 42 percent stake for 120 crore rupees, presumably because by then the multi-city footprint had started to compound. By the time ChrysCapital bought them out in 2025, Theobroma had 225 stores across more than 30 cities. Roughly 60 percent of revenue came from online and delivery orders. Roughly 40 percent from physical footfall.

    What the acquirer paid 2,410 crore rupees for was not a single beautifully-run channel. It was a multi-channel physical distribution asset that had taken 21 years to compound into a number that mattered. The operating system, the recipes, the brand, the delivery infrastructure, all of these multiplied the asset. None of them substituted for it. You cannot compress 225 retail outlets into a skill library.

    There is a Scandinavian version of the same logic. Lagkagehuset, the Danish bakery chain that Nordic Capital acquired in 2017, sold on “flexibility of concept”: multiple store formats, urban food-to-go outlets, international expansion under the Ole & Steen brand. The operating model was good. The thing the acquirer actually paid for was that the operating model could be pointed at more than one kind of channel.

    The metric that moved

    Somewhere in the last two weeks my internal scorecard for this business has begun to shift.

    The number I used to track on Monday morning was how many new skills I had added, how many automations had shipped, how many steps of the workflow had been pulled from manual to systematized. The number I am starting to track instead is what percentage of reoccurring weekly revenue comes from outside the WhatsApp communities. Today that number is very low. If the business is going to be sellable in August 2027, that number cannot be close to zero. It needs to sit somewhere between 25 and 50 percent.

    Which is why Saturday’s seven B2B leads mattered more than the twentieth skill I could have written this week. Tarento is the Bangalore arm of a Swedish tech consultancy. Trelleborg has a local engineering unit. Autoliv’s Indian subsidiary has Swedish leadership. Most of the pipeline is Swedish-linked, because that is the version of me that can walk into these offices and sound like something familiar. The angle is defensible. The work is unglamorous. It is also the work the operating system cannot do for me, because the operating system lives downstream of demand. It cannot create demand where none exists.

    The skill library and the B2B pipeline are doing different things. One is a multiplier. The other is the asset being multiplied. I had been spending Saturday mornings on the wrong one.

    The question I am still sitting with

    If the operating system is a multiplier, and the distribution is the asset, and the asset has to be diversified enough to survive a diligence room, what does a second channel look like for a pre-order bakery in Bangalore that does not want to live on Swiggy?

    Theobroma’s answer was physical retail density. We do not have 21 years. Gymshark’s answer was an owned community on someone else’s platform, with exceptional product economics underneath. We might be able to approximate that. La Boulange’s answer was that the recipes were the asset and the channel did not matter; Starbucks closed the stores and kept the book. That is a possible end-state, and I have noticed lately that our recipe document is starting to look like the sort of thing an acquirer might quietly want.

    I keep coming back to the B2B move. Corporate gifting, office fika deliveries, Swedish-linked companies that want a credible fika offering without the friction of running it themselves. Seven notes on a Saturday is not a channel. It is the beginning of one. By December I will know whether it is a real second leg or a founder’s hobby that the calendar ignored. Nordic Capital’s “flexibility of concept” phrase keeps coming to mind. You do not need four channels. You need one channel plus a credible capacity to build a second one.

    Maybe the real skill the operating system has been training me in was never the automation itself. Maybe it has been the reflex of asking, every time, what exactly I am multiplying. The AI is very good at running the operating system. It cannot tell me whether the asset underneath is the right asset. That part is still, for now, the boring middle-aged founder with the laptop on a Saturday morning, typing out the names of Swedish companies one at a time into an Obsidian vault.

  • Vibe Coding Is the Wrong Frame. What You’re Actually Doing Is Specification.

    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.