Fast forward a few years, and I’m sitting with my fifth grader, helping her do her homework. It’s the first time she’s being asked to write paragraphs, sometimes more than one. These “write longs” are graded assignments, and she wants to do well. I offer to work with her on it, trying my hardest to find that proper parental line between guidance, advice, and doing the work. Her natural approach is to read the example her teacher provided and try to adhere to it as closely as possible. This makes my advice easy: don’t do that. We talk through what the assignment means, and what the example represents, and then I encourage her to just tell me what she’d like to say. After that, I encourage her to write it down.

The thing about writing, good writing at least, is that it should sound like it could only come from the person that wrote it. What good writers have is a confidence in their own voice. Sure, they should know the rules—at least the basics. But honestly, the rules matter less than having something to say and finding a way to say it that is true to yourself. Sometimes you know that ahead of time, but sometimes you only find that out by writing and re-writing. The challenge with AI in writing, and just about everything else, is that it’s training as a “helpful assistant” and aims it towards the end product. It always wants to deliver the document or write a ticket, when often what you need is to think through the problem. I have always found the best role of writing is externalized thinking. It’s also why I hate conclusions.

One of the most confounding things about the recent releases of even more powerful AI models is that they seem, in my view, to be getting worse at writing. I suspect part of it is that the explosion of AI for coding has driven more and more focus on verifiability as a key measure of quality, something writing clearly lacks. I also think, to the point above, that reinforcing the “helpful assistant” voice has probably driven a certain flattening of language. But there’s also another side of the problem: there are certain things like em dashes or “it’s not this, it’s that” that used to be perfectly fine and are now a danger zone because LLMs have converged on the pattern. When you saw an em dash above, you might have had a moment where you thought I had used AI to write this (I haven’t).

The problem, I think, is that good writing is fundamentally anti-consensus. For writing to be above average, it shouldn’t sound like everything else. My daughter might get a fine grade aping the teacher’s example essay, but the road to good, or even great, is doing it your own way.

On top of that, writing is a creative act and, as a creative act, the process matters as much, if not more, than the outcome. There’s a saying in law I was introduced to years ago: “Does it write?” Writing is figuring out whether there’s a there there. It’s an opportunity to test the validity of your thesis on yourself: can you string words, sentences, and paragraphs into an argument that still captures your intention and attention 700 words later?

With all this said, I’m obviously an AI maximalist. I used AI to collect thoughts, pull together references, and think through this essay. I believe we will and should use AI in certain kinds of writing. But I also believe that AI writing is fundamentally not good at the moment, and you should feel embarrassed to ship slop to readers. Like a lot of hard problems, there’s not a simple way to draw a line. But I think some good rules of thumb have emerged:

1. Writing is thinking, and if you’re interested in pushing forward your own perspective on an idea or problem, you should be the one hitting the keys.

2. Every sentence matters, and you should be prepared to stand behind each of them, regardless of whether you or AI wrote it. Respecting your reader means spending more time writing something that it would take them to read. (If your reader is another AI, then aligning to token time is obviously appropriate.)

3. Never let AI remove you. We are going to use lots of AI. I ran this essay through a few different systems (spelling, grammar, ideas). We should keep doing that, but it’s also okay to say no to suggestions. Grammarly wants me to add a bunch of semicolons and fix some technically incorrect sentence construction, but semicolons are not my style, and using a few extra “reallys” sounds more right in my head, so they’re staying put. If you don’t feel certain, it’s okay to have it read uncertain even though the AI and the writing manuals tell you not to. That’s you.

4. Slop kills good ideas. Sadly, even if you’ve got something great to say, if you open with six slop tells you’ve lost me.

5. Good writing is vigorous. Strunk and White said it best, “Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.” Sadly, most LLMs treat writing like college freshmen: length is the goal.

6. Writing is anti-consensus: your voice is what makes your writing good, and no matter how much prompting you give a model, it’s not currently capable of getting there without real help.

7. Becoming a better writer is a worthwhile lifetime pursuit. None of us has reached the top of the mountain, there are always places to improve and new words to learn. We can always communicate our ideas more effectively.

This post was in part inspired by Clay’s writing policy and Vicky Boykis’ Write for people post.

Two documentaries I watched in college helped inspire me to become an entrepreneur.

The first was Triumph of the Nerds, Robert X. Cringely’s history of the personal computer industry. It showed how hobbyists, programmers, and self-described nerds turned computers from machines owned by governments, universities, and giant corporations into products ordinary people could buy.

The second was Revolution OS, the story of Linux, free software and open source. Richard Stallman, Linus Torvalds, and Eric Raymond explained how people distributed around the world could collectively build software that competed with the largest technology companies.

Together, the films gave me a way to see technology markets. Something powerful gets built inside a company, university, or government. Eventually the cost falls, access expands, and a new group of builders arrives. Many of the biggest businesses emerge from that change.

I have spent much of my career making some version of this bet. When we started Percolate in 2011, cloud infrastructure and SaaS were still moving into the enterprise. Alephic is based on a similar belief: AI enables companies to build differentiated software that makes them titans of their industry.

The part I understand more clearly now is that open and closed systems are not opponents. The personal-computing revolution needed both, and the AI revolution will too.

The Cathedral Inside the Bazaar

Eric Raymond was a programmer and one of the early advocates for what became known as open source. In 1997, he presented The Cathedral and the Bazaar, an essay he later expanded into a book.

The book was part software case study, part management theory, and part manifesto. Raymond was trying to explain something the commercial software industry found difficult to believe: Linux was being built in public by people distributed around the world, yet it was becoming a serious operating system.

Raymond contrasted two development models. The cathedral model assumed that complex software required a small group of experts working privately against a master plan. Users received finished releases but had little visibility into how the software was built.

The bazaar model released software early and often. Users could inspect it, test it, report problems, and contribute improvements. They became part of the development process.

Raymond’s thesis was more specific than “open beats closed.” He argued that complexity could be managed by widening participation, as long as the project had leadership capable of setting direction and filtering contributions. His famous observation was that “given enough eyeballs, all bugs are shallow.” More people looking at a problem increased the likelihood that somebody would understand it.

At the time, operating systems were primarily cathedrals. Microsoft built Windows internally. Apple controlled Macintosh. Even Sun, IBM, and HP maintained their own versions of Unix. Small groups made the decisions and handed finished releases to users.

Linux, on the other hand, followed the bazaar model. Developers could inspect the source code, test it on different hardware, and submit improvements. But Linux was never leaderless. Linus Torvalds decided what entered the kernel, and maintainers determined which contributions were accepted. The project was open without being a free-for-all.

The wider PC industry developed through similar combinations. Microsoft controlled Windows but distributed it across an enormous ecosystem of hardware manufacturers and software developers. Apple maintained tighter control over the complete product, then later built its modern operating systems on Unix and then, most famously, the App Store. Linux relied on open participation, strong maintainers, corporate funding, and companies that turned community software into enterprise products.

The PC era never settled the argument bet

ween cathedrals and bazaars. Its most important ecosystems combined them. Open source did not destroy the software business either. It made foundational technology available to more builders, moving value into applications, services, cloud infrastructure, and problems the original creators would never have pursued.

Kimi K3 and the Same Pattern

Kimi K3 was recently released, and it compresses this history into a new and very impressive model.

Moonshot AI built a 2.8-trillion-parameter model with native vision and a one-million-token context window. At launch, Artificial Analysis ranked it fourth among 187 comparable models. That would be impressive for any lab. It is even more notable coming from an organization other than Google, OpenAI, Anthropic, and the handful of American companies most people assume own the frontier.

At the same time, K3 was built like a cathedral. Training a model of this size requires concentrated compute, capital, data, and engineering. Moonshot made the architectural decisions, coordinated the training run, and absorbed the risk.

Moonshot now plans to release the full weights. At the time of writing, that release is still a promise, but we should assume it will happen. Once the weights are available, developers will be able to host, optimize, and adapt the model. Researchers will find weaknesses. Enterprises will connect it to their own data. Entrepreneurs will apply it to problems Moonshot would never pursue itself.

Linux was built in the bazaar from the beginning. K3 is taking a different route: cathedral first, bazaar second. That may become one of the defining patterns of AI. Cathedrals will concentrate the resources required to push the frontier. Bazaars will spread those advances and discover more uses for them.

The open-model debate on Twitter/X often jumps from frontier companies are going to take over the world to frontier labs will collapse because of rapid open-source commoditization. I think that misses the economic mechanism of how these markets will develop. Open models can make today’s capability common and put pressure on prices at the model layer. But cheaper intelligence increases use. More use creates new applications, more infrastructure demand, more feedback, and a larger market for the frontier to continue to invest forward.

The AI Economy Needs Both

Open-model progress will put pressure on frontier companies, but it will not commoditize them away. Kimi K3 does not make Anthropic a bad business, any more than Linux made Windows or the Mac irrelevant. It makes powerful intelligence cheaper and more available. That leads to more use, more products and a larger market.

That larger market pulls both sides forward. Open models push down costs and spread access. Proprietary labs push the frontier and give everyone else new capabilities to work with. At the model layer, cathedrals and bazaars compete. At the market level, they compound.

For companies and builders, this is all good news. They get better models at lower prices and can build downstream from trillions of dollars in investment. Their durable advantage comes from customer knowledge, proprietary context, workflows, distribution, and trust.

Kevin Kelly’s line is: “Technology wants to be free. Not free as in free beer, but free as in freedom.” In AI, that freedom means more people can use, adapt and build with powerful intelligence. The question changes from “Can I get access?” to “What can I build now that this exists?”

AI will need cathedrals capable of concentrating capital, compute and talent. It will need bazaars to spread those advances and discover uses their creators never imagined. AI will become more powerful, and more valuable, because both exist.

When the Challenger shuttle broke apart in 1986, Richard Feynman was dying of cancer and had no interest in joining a presidential commission. A former student talked him into it. Within days, Feynman found himself sitting through carefully managed hearings where NASA officials spoke in probabilities and reassurances. The agency was adamant that the risk of failure was very high, one in every 100,000 flights. Feynman was skeptical of that number and it sparked a passion to find the answer.

What Feynman did next is what made him Feynman. He ignored the formal process entirely. Instead of waiting for testimony to trickle up through layers of management, he walked the halls and found the people who actually worked on the shuttle. He was looking for the engineers who poured over test data and who knew exactly where the system might have been fragile. They pointed him to the O-rings: rubber seals in the rocket boosters that stiffened in cold weather. The launch had happened on an unusually frigid Florida morning. The experts handed Feynman the diagnosis and the proof in one conversation.

On live television, Feynman dropped a piece of that O-ring rubber into a glass of ice water, pulled it out, and showed that it had lost all resilience. No spring-back. No seal. The invisible failure that killed seven astronauts, made visible in ten seconds with a hardware-store C-clamp and a cup of ice.

Feynman didn’t need a bigger committee or a longer review cycle. He needed the right experts, and the experts gave him everything: the problem, the cause, and the solution.

We think about this story a lot at Alephic because we see a version of it playing out in the enterprise AI every day. Organizations assemble the right committees of budget owners, technical reviewers, end users, and internal champions. And yet there is evidence that projects still underperform. As we have done more projects we are starting to see a common pattern for why these projects fail and it has a lot to do with the type of expert(s) that needs to be included from the beginning. In order to figure out what has shifted, I’d like to talk about how companies have traditionally sold into the enterprise.

For forty years, enterprise sales teams have organized their world around a framework that Robert Miller and Stephen Heiman laid out in Strategic Selling. If you’ve spent any time in B2B sales, you know the four buying influences by heart: the Economic Buyer who controls the budget, the User Buyer who lives with the product every day, the Technical Buyer who evaluates specifications, and the Coach who advocates internally. It’s an elegant model that has been used to sell billions of dollars’ worth of software but in the age of AI, it’s missing the most important person in the room.

We believe there’s a new buyer that the Miller Heiman framework never anticipated, one that matters more than any of the original four when it comes to building AI that actually works. We call this person the Expert Buyer.

A Quick Refresher on Miller Heiman

The Miller Heiman Strategic Selling methodology was built for an era when enterprises were buying products as defined, scoped, packageable things. Categories were defined by analysis and products fit neatly into their boxes: CRM, a marketing automation platform, an ERP system. The framework identifies four distinct buying influences that shape every enterprise deal, each with different motivations and different definitions of a “win.”

The Economic Buyer is the person with final approval authority. They can say yes when everyone else says no, and no when everyone else says yes. They care about the financial impact on the organization—ROI, budget allocation, strategic fit. In practice, this is often a C-suite executive or VP who controls the purse strings. Their question is: What’s the return on this investment?

The User Buyer is the person (or people) who will actually use the solution day-to-day. They care about whether it fits their workflow, whether it makes their job easier or harder, whether it solves the problem they feel in their bones every morning. A User Buyer’s judgment is personal and operational. Their question is: How will this affect my daily work?

The Technical Buyer screens out solutions that don’t meet predefined criteria. They evaluate security, compliance, integration requirements, and data architecture. They can’t give the final yes, but they can absolutely give a final no. Their question is: Does this meet the organization's requirements?

The Coach is your internal champion, has credibility within the organization, and actively supports your solution. They provide access to the other buyers, share intel on internal politics, and help you navigate the organizational maze. Their question is: How do I help this deal happen?

This framework works brilliantly when you’re selling a product that exists before the buyer shows up. A SaaS license. A piece of hardware. A platform. The product is the product. The sale is about matching a pre-built thing to the buyer’s needs.

But AI doesn’t work like that.

Why AI Broke the Framework

The SaaS era trained enterprises to think of technology purchases as licensing decisions. You evaluate, you compare, you negotiate terms, you implement. The vendor has the product pre-built and will ultimately map you to their existing solution, which hopefully looks similar to those used by the other enterprises they sell to. While any good enterprise platform is certainly highly configurable, the value is largely predetermined by the vendor’s R&D, and you’re buying the median output of their engineering team, designed for the median customer.

AI flips this on its head. When you’re building AI systems, we believe the most valuable AI in the enterprise will be built, not bought. That’s because with AI the difference between average and extraordinary is the expertise in the organization—and it’s built with your best people. And the single biggest variable in whether an AI project produces transformative results or expensive mediocrity isn’t the model, isn’t the code, and isn’t the budget. It’s the expertise you feed into it.[a]

We’ve seen this play out across every engagement we’ve done at Alephic. At Amazon, the AI system that helped produce a Cannes Lions-winning campaign wasn’t successful because of ChatGPT or Claude; it worked because Amazon’s creative team, led by people like Mike Houston, brought decades of creative judgment to bear on what makes a customer review genuinely compelling and theatrical. The AI processed millions of reviews, but the expertise decided what “great” meant.

At EY, the Content Matrix system, which now analyzes 50,000+ articles across six global markets, didn’t become valuable because of its AI pipeline. It became valuable because EY’s marketing experts defined the scoring rubrics, buyer personas, and competitive frames, and refined them until they achieved the desired outcome.  

In every case, the AI was an accelerator. The expertise was the differentiator.

Enter the Expert Buyer

So who is this person? The Expert Buyer is the domain expert whose knowledge, judgment, and accumulated experience are the essential raw materials that make an AI system valuable. They are not buying software to use. They are not evaluating a budget line. They are not checking a compliance box. They are the person whose brain the AI system needs to learn from in order to produce anything better than average.

The Expert Buyer might be the executive creative director who knows what great advertising looks like. Or the content strategist who understands how to differentiate thought leadership in a crowded professional services market. Or the merchandising veteran who can look at a catalog page and tell you in three seconds whether it will sell. Or the competitive intelligence analyst who has pattern-matched industry moves for twenty years.

What makes the Expert Buyer fundamentally different from the User Buyer is this: the User Buyer evaluates whether a product fits their workflow. The Expert Buyer’s workflow is the product. Their knowledge isn’t a nice-to-have input, it’s the essential ingredient without which the AI system produces generic, undifferentiated output.

The Expert Buyer vs. The Traditional Four

Let’s be precise about what makes the Expert Buyer distinct from each of the Miller Heiman archetypes.

Expert Buyer vs. Economic Buyer. The Economic Buyer asks, “What’s the return?” The Expert Buyer asks, “What should this system actually know?” The Economic Buyer can approve a million-dollar AI investment. But without the Expert Buyer’s domain knowledge encoded into the system, that million dollars buys a very expensive chatbot that produces median output. We’ve seen projects get full budget approval from enthusiastic C-suite sponsors and still fail—not because of funding, but because no one with deep domain expertise was engaged in the build process. The Economic Buyer can fund the project. Only the Expert Buyer can make it smart.

Expert Buyer vs. User Buyer. The User Buyer asks, “How will this affect my daily work?” The Expert Buyer asks, “Is this system actually good at the thing it’s supposed to do?” A User Buyer might love the interface and find the workflow intuitive. But if the AI is producing mediocre content, missing competitive signals, or misunderstanding the nuances of the brand voice, the Expert Buyer is the one who catches it—and the one whose feedback makes the system better. The User Buyer validates usability. The Expert Buyer validates intelligence.

Expert Buyer vs. Technical Buyer. The Technical Buyer asks, “Does this meet our security and integration requirements?” The Expert Buyer asks, “Does this system understand our domain well enough to be trusted?” A Technical Buyer can ensure the data pipeline is encrypted and the API is compliant. But they can’t tell you whether the AI’s output actually reflects a deep understanding of your competitive landscape, your brand positioning, or your customers’ unspoken needs. The Technical Buyer ensures the system is safe. The Expert Buyer ensures the system is right.

Expert Buyer vs. Coach. The Coach helps navigate internal politics to get the deal done. The Expert Buyer, when properly engaged, becomes something far more powerful: they become the person who makes the deal worth doing. An Expert Buyer who’s bought into an AI project doesn’t just advocate for it; they pour their knowledge into it. They become the source of what we call “private tokens”, the proprietary data, tacit knowledge, unwritten rules, and accumulated judgment that transform a generic AI system into something that actually captures institutional intelligence.

Why Most AI Projects Fail Without One

Here’s the uncomfortable truth: most enterprise AI projects that underperform do so not because of technical failure, but because of expertise failure. The model was fine. The code was fine. The infrastructure was fine. But nobody with deep domain knowledge was embedded in the build process, shaping what the system should know, evaluating whether its outputs met the bar, and iterating on the feedback loops that make AI systems get smarter over time.

This is what we mean at Alephic when we say “AI produces median output without expertise, and we never ship median work.” The models are incredible—they’re the most powerful reasoning engines humanity has ever built. But they are also, by definition, trained on the average of the internet. Median knowledge of median quality with median insight. The Expert Buyer is the person who takes that median baseline and drags it toward exceptional, because they know what exceptional looks like within their domain.

We’ve built our entire operating model around this insight. Our Forward Deployed Engineers embed directly with client teams specifically to find and work alongside the Expert Buyers. When that expertise doesn’t exist internally, we bring it in through our expert network. We never guess when we can learn from someone who knows.

This is also why our Triangle Model, AI + Code + Human Expertise, places expertise as a co-equal vertex alongside the technology itself. Neglect any vertex, and you get suboptimal outcomes. But in practice, the expertise vertex is the one most projects neglect, because it wasn’t part of the buying framework anyone was using, and it's often represented in the organization many levels below the economic and often even the user buyer.

What This Means for How We Sell (and Buy) AI

If you’re on the selling side of AI solutions, the Expert Buyer reframes your entire approach. Your discovery process shouldn’t just map Economic, User, and Technical Buyers. It should identify who in the organization holds the domain expertise that will make or break the project. Your champion strategy shouldn’t just find a Coach, it should find and engage the Expert Buyer early, because their enthusiasm will be driven not by politics but by the genuine excitement of seeing their lifelong expertise amplified by AI.

If you’re on the buying side, the implication is even more direct: don’t greenlight an AI project without identifying your Expert Buyers and committing their time to the build. This is the single highest-leverage investment you can make. Not more compute, or better models: the time and attention from the people who actually know your business and how to produce the outputs at the ground level.

What software craves is expertise. And in a world where every company has access to the same foundation models, the same cloud infrastructure, and the same developer tools, the only remaining source of differentiation is the knowledge that lives inside your organization, in the heads of the people who have spent years or decades mastering your specific domain.

The Expert Buyer is the keeper of that knowledge. And in the age of AI, they are the most important buyer in the room.

More Reading:

1. "The SaaS Industrial Complex: When Their Mirror Becomes Your Mold" 

2. "Don't Let SaaS Train on Your Private Tokens" 

3. "Software Built For You" 

4. "Strategic Software"

That is where marketing has to do actual work. Not marketing as promotion or spin, but marketing as understanding the market, naming the fear honestly, assuming people are rational, creating proof that life can be better, and making the bargain visible.

Data centers create local costs: construction, power demand, water concerns, noise, land use, and the feeling that a distant tech company is extracting value from your town. Autonomous vehicles ask people to accept a new kind of road failure: being hurt by a machine no one in the car controlled. We already tolerate human error on roads, but machine error feels less familiar and less accountable. AI arrives with job fear, copyright fights, hallucinations, deepfakes, and years of existential threat rhetoric attached to it.

Some of those concerns are exaggerated, some are wrong, but most of them are rational.

Big Tech helped create the mistrust. Ben Thompson at Stratechery made this point in “Attenuating Innovation,” arguing that some of the loudest AI alarm came from the companies best positioned to benefit from regulation. The message to Washington was basically: think of AI like nuclear weapons, while also letting us keep building it.

This is why the nuclear analogy matters. We have already seen what happens when a powerful technology loses the public and then loses the politicians. Nuclear should have been one of the great abundance stories of the last century: cleaner air, cheaper energy, more resilient grids, less dependence on fossil fuels. Nuclear did not lose because every fear was irrational. There were real accidents, frightening images, and institutional failures. The failure was that the industry and its political defenders never made the safety case legible enough, or the public bargain attractive enough, to preserve consensus. Fear hardened into politics, politics hardened into regulation, and an abundance technology became almost impossible to build.

That is the risk now. If AI, AVs, and data center companies treat public resistance as a messaging nuisance instead of a legitimacy problem, they can win the technical argument and still lose the social one. Nuclear is the reminder that being right about the technology is not enough. Once public consensus hardens against you, politicians follow it, regulators encode it, and the future you thought was inevitable becomes impossible to build.

In my recent talk, It’s Time to Market at the Ride AI Summit, I tried to show the historical framework for how other companies, and their marketers, helped overcome the fear of new technology. Refrigerators, electricity, and seat belts were adopted when someone made the technology culturally legible.

Refrigerators became about cleanliness and responsible parenting. Electrification became the modern home certification. Seat belts became “you can learn a lot from a dummy” from two crash test dummies, Vince and Larry. That is the work in front of AI, AVs, and data center companies now.

Facts matter, but facts alone will not carry this. The job is to build a more honest social contract around the technology.

What marketers can do

Stop selling the future for some.
People often hear “the future” as “someone else gets rich while I absorb the risk.” Sell continuity instead: safer roads, more reliable services, better schools, lower friction, less waste, and more capability close to home.

Admit the real tradeoffs first.
Do not tell communities that data centers have no cost. Say what the cost is, who bears it, and what they get in return. More on what that might look like below.

Separate fear from misinformation.
Rates, land use, safety, jobs, and privacy are legitimate concerns. False claims should be corrected, but treating all opposition as ignorance only makes the opposition stronger.

Make the infrastructure worth seeing.

Data centers should not feel like punishment for hosting the future. In a Stripe Sessions conversation with Daniel Gross and Nat Friedman, Gross (not related to this author) made the practical point: beauty will not fix the politics by itself, but these buildings can be made pleasing to the eye without massive extra spend. Friedman’s broader point was even more important: beauty used to be treated as a public good. Marketers should push for that standard now. A data center should feel like a civic asset: quiet, well-designed, embedded in the landscape, and visibly connected to local benefit. The CopenHill project where you can ski on top of a power plant is a fun inspiration.

Pay communities visibly.
People are rational, and people also like to get paid. If a community is absorbing real cost and real disruption, there needs to be a visible return. Think about it like any other funnel problem: what does it cost to acquire trust?

Create experiences, not rebuttals.
AV companies need ride programs, caregiver stories, drunk-driving prevention narratives, senior mobility demos, and neighborhood-level safety proof. AI infrastructure needs workplace examples where people can see the tools helping them.

Change the messenger.
The credible messenger is not the hyperscaler CEO. These messages should come from “the jobs little kids love and want to be”. Teachers, nurses, parents, firefighters, construction workers, and local leaders who can explain in ordinary language what changed and why it mattered.

The public can believe the benefits are real and still reject the bargain. That is the part the industry keeps missing. When tech companies say progress, people hear extraction. When they say safety, people remember years of warnings that these same technologies might be dangerous. When they say infrastructure, communities see massive facilities built for distant companies, not for them.

That is how good technologies lose. Not all at once, and not always because the critics are right. They lose because no one did the work of earning trust before fear became consensus. Clean nuclear energy is the warning case study. If AI, AVs, and data center companies want a different outcome, marketing must lead. It has to make the bargain honest, local, emotional, and visible, so people can see not just what they are being asked to accept, but what they actually get in return.

Every bubble story follows a similar script: Too much money chases too little reality, causing supply to outstrip demand until the market eventually corrects itself. We’ve seen it in railroads, tulips, dot-com businesses, and now, as many commentators would lead us to believe, in AI.

The commentators are right in some ways; the AI economy does have a supply problem. But it runs in the opposite direction.

Demand is real—Anthropic’s revenue mind-blowingly went from zero to $14 billion in three years—and it’s growing faster than the physical world can accommodate it. The semiconductor supply chain, from TSMC’s fabs to ASML’s mirror-polishing rooms to Samsung’s memory lines, cannot build fast enough. Microsoft lost $357 billion in market value, partly because it couldn’t secure enough GPUs to serve customers willing to pay.

After digging into the data, I’ve not only become convinced this isn’t a bubble, I actually believe it’s an anti-bubble. By that, I mean the foundation models don’t have enough compute to meet demand, leaving them to throttle customers in the hope of destroying the insatiable demand we have for intelligence. (If you don’t believe this, ask Anthropic why they don’t do free trials and wouldn’t extend their Claude Max plan to OpenClaw users.)

The Revenue That Won’t Stop

How did we get here? Start with what Dario Amodei told Dwarkesh Patel in February. Anthropic’s revenue trajectory is quite literally unprecedented: from zero to $100 million in 2023, $100 million to $1 billion in 2024, $1 billion to $9–10 billion in 2025, and then in January 2026, the company added “another few billion.”

“You would think it would slow down,” Amodei said, but it hasn’t.

Every hyperscaler’s earnings call in late 2025 carried the same refrain: demand exceeded supply. Microsoft’s CFO Amy Hood said Azure AI demand “again exceeded supply across workloads, even as we brought more capacity online.” Google’s CFO described “a tight demand-supply environment.” Amazon’s CEO: “As fast as we’re adding capacity right now, we’re monetizing it.”

In a bubble, companies build ahead of demand and pray customers materialize. The idea of Pets.com wasn’t a bad one; it just came 15 years too early, before enough people were on the internet to support its valuation. With AI, customers are lined up, but the factories haven’t been built yet.

The AGI-Pilled Gradient

Dylan Patel, the founder of SemiAnalysis, the leading voice on all things chips, has the clearest model for why the supply chain keeps getting it wrong. He calls it the AGI-pilledness gradient.

The companies closest to the models—OpenAI, Anthropic, Google—see the demand most clearly. They know what the next generation of models will be capable of and how much compute those models will consume. Nvidia, one step removed, is slightly less aggressive. TSMC, another step down, is even more conservative. And ASML, which builds the machines that make the machines that make the chips, plans for a world that looks like a modest extrapolation of the past.

“OpenAI and Anthropic, they know they need X [chips],” Patel told Dwarkesh. “Nvidia is not quite as AGI-pilled, and they’re building X [chips] minus one, and you go down the supply chain, everyone’s doing minus one. And in some cases, they’re doing divided by two.”

The result is a supply chain in which each link underbuilds, and therefore underserves, the one above it.

“Constantly, we’re told our numbers are way too high,” Patel said. “And then when they’re right, they’re like, oh, yeah, yeah, but your next year’s numbers are still too high.”

The Physics of Falling Behind

The gap between AI demand and semiconductor supply isn’t stable. It’s widening. Ben Thompson put it plainly in Stratechery: “TSMC is the de facto brake on the AI buildout.”

TSMC’s CapEx was effectively flat through 2023 and 2024—the exact years when AI demand was exploding post-ChatGPT. The company has since ramped: $41 billion in 2025, with $52–56 billion planned for 2026. But TSMC’s own CEO, C.C. Wei, admitted the contribution of that spending to 2026 capacity is “almost none,” and to 2027 capacity “only a little.” New fabs take 2 to 3 years to build, so meaningful additional new capacity won’t arrive until 2028 or 2029.

Thompson’s observation is the damning one: TSMC’s CapEx growth rate is lower than hyperscaler CapEx growth. TSMC’s customers are telling the company as much. Wei reported that customers told him “silicon from TSMC is a bottleneck” and asked him “not to pay attention to all others, because they have to solve the silicon bottleneck first.”

And then there’s ASML. Advanced Semiconductor Materials Lithography (ASML) is the sole manufacturer of extreme ultraviolet lithography machines—the tools required to print transistors at 5 nanometers and below. Each one costs $300–400 million, ships in 40 freight containers, and contains over 100,000 parts. The mirrors, made by Carl Zeiss, must be “so smooth that if expanded to the size of Germany they would not have a bump higher than a millimeter.”

ASML currently produces about 70 EUV tools per year. By the end of the decade, under aggressive assumptions, that number reaches slightly over 100. Patel calculates that each gigawatt of AI compute requires roughly 3.5 EUV tools. That means even with every EUV machine ever made still running, the theoretical maximum is about 200 gigawatts of AI chip capacity by 2030.

Meanwhile, Amodei estimates the industry is building 10–15 gigawatts this year, scaling at roughly 3x annually. That trajectory hits 100 gigawatts in 2028 and 300 gigawatts in 2029. Here is how the supply from ASML looks against the forecasted demand from Amodei.

The exponential demand curve slams into the linear supply ceiling somewhere around 2028. “No one really sees demand for 200 gigawatts a year of AI chips or trillions of dollars of spend a year in the semiconductor supply chain,” Patel said. “They’re just not AGI-pilled.”

And the bottleneck within the bottleneck? Carl Zeiss SMT, the division of the privately held Carl Zeiss AG that makes the optics without which no EUV machine works. ZEISS is owned by a German foundation, not publicly traded, and its semiconductor optics division alone does over ~$5 billion a year in revenue. ASML has taken a 24.9% stake in it. The entire AI compute buildout, with trillions of dollars in projected demand, funnels through a single division of a foundation-owned optics company that no public market investor can touch directly.

Klumpenrisiko. An actual German financial term meaning “concentration risk” or “cluster risk.” It’s a real word used in risk management, and it sounds exactly as alarming as the situation warrants.

Collateral Damage

The anti-bubble doesn’t just leave money on the table for hyperscalers; it can destroy adjacent industries.

Thirty percent of the Big Four’s $600 billion in combined CapEx this year is going to memory. High-bandwidth memory—HBM—delivers 20x the bandwidth of standard DRAM but uses three to four times more wafer area per bit. Memory vendors, who were losing money in 2023, haven’t built new fabs in three to four years. As with TSMC, new capacity takes multiple years to come online.

The consequence: memory prices have roughly tripled. And that cost hits everything with a chip, cascading far beyond GPUs and the AI market. Patel projects smartphone volumes dropping from 1.1 billion units to 500–600 million as memory costs add $100–150 to each phone’s bill of materials. Xiaomi and Oppo are already cutting low- and mid-range volumes in half. PC gaming forums are full of memes about AI killing RAM prices.

This is demand destruction, but not the kind bubble theorists imagined. In our current scenario, we’re already seeing clear evidence that this anti-bubble will destroy demand for other products by consuming their supply inputs, making them both more expensive and scarcer. Unlike AI, it’s not hard to forecast smartphone demand: we have almost twenty years of data to work with. It’s also easy to see the pattern in prices and performance—what you can get in an entry-level phone today far surpasses the best phone from five years ago. But all this can and will start to change as more and more of the supply pipeline for everything in our lives gets rerouted to AI because of the underbuilding down the stack. Consumer electronics will be collateral damage in an infrastructure war they didn’t start.

The Demand Prediction Trap

Amodei is candid about the bind this creates for the companies closest to the demand signal.

“I could assume that the revenue will continue growing 10x a year,” he told Dwarkesh. “I could buy $1 trillion of compute that starts at the end of 2027. If my revenue is not $1 trillion, if it’s even $800 billion, there’s no force on earth, there’s no hedge on earth that could stop me from going bankrupt.”

This is the demand prediction trap. Anthropic’s revenue has grown 10x a year for three consecutive years. There is no sign that demand for Anthropic’s models will slow down any time soon. But no company can bet its existence on unprecedented revenue extrapolation, because being wrong by one year—or having 5x growth instead of 10x—when you’re working in numbers with eleven zeroes means insolvency.

So Anthropic calibrates to “capture pretty strong upside worlds” without existential risk. OpenAI signed more aggressive five-year deals and now has more compute locked up at better prices. Despite that, neither has enough capacity for AI-hungry businesses and consumers who discover new ways to use the technology every day.

The bind extends down the chain. TSMC won’t build more fabs because if AI demand misses by a year, depreciation and the loss of margin eats them alive. ASML won’t double EUV production because if orders don’t come in, they’ve overbuilt the most expensive machines on Earth. Each company manages its own risk rationally. In aggregate, the industry undersupplies.

This is the structural mechanism of the anti-bubble. In a normal bubble, irrational exuberance leads to overbuilding, and the correction is a crash. Here, rational caution leads to underbuilding, and the correction is... more shortages and, almost certainly, an inflationary environment in many categories, like consumer electronics, where low prices have become the norm. The feedback loop runs backward. Every company that hedges against overinvestment makes the supply deficit worse, validating the demand signal. This makes the next round of forecasts look conservative again all the while making your next iPhone way more expensive.

What the Anti-Bubble Means

Amodei projects the AI industry reaching “low hundreds of billions” in revenue by 2028, then trillions before 2030. His math: if each gigawatt of compute costs $10–15 billion a year, and the industry reaches 100–300 gigawatts by 2028–2029, the numbers work.

Whether those numbers land depends on whether the supply chain can build fast enough. Right now, it can’t. Thompson’s prescription—that hyperscalers must build up Samsung or Intel as viable competitors to TSMC—is less a strategic recommendation than an observation about what happens if they don’t. “If hyperscalers and chip companies don’t build up a TSMC competitor,” he writes, “they are set to forego billions of dollars in revenue and stunt the AI revolution.”

An H100 GPU is worth more today than when it shipped three years ago—because the models it can run now generate more valuable output. That fact alone should give the bubble theorists pause. In a bubble, assets depreciate as reality catches up to hype. In the AI compute market, assets appreciate as demand outruns supply.

The conventional wisdom says the question is whether AI can justify the investment. The data says the investment can’t keep up with the AI. We aren’t in a bubble. We are in the opposite of one—a world where the real risk isn’t that we’ve built too much, but that we can’t build fast enough to capture the demand that is already here.

The NCAA Tournament is upon us, and with it comes millions of brackets. When the question of whether anyone wanted to do March Madness came up in Alephic Slack, the conversation quickly shifted to setting up a model bracket to pit all these different AIs against each other. The idea then turned to some execution details, and off we went.

tl;dr: We built a bracket challenge to see which model could best navigate tools to make March Madness picks. The site is at model-madness.alephic.ai

The basic concept was to see which model would win in a basic bracket competition with the aid of some simple tools like web search and fetch. The end result, for some interesting reasons, turned out to be a much more complicated system in which 45 models combined entries across three categories: easy, medium, and hard. In the end, I think the experiment tells an interesting story about what it takes to actually build agents and the wide range of capabilities models have at effectively wielding the tools required for agentic work.

The Basic Setup

For posterity’s sake, here are the big pieces of the stack we used to build this:

• NextJS running on Vercel

• Vercel AI SDK for calls and basic AI functionality

• Vercel WorkflowDevKit for asynchronous processing

• Vercel AI gateway for easy access to all 45 models through one provider

• Firecrawl for web search and scraping

The Build

As I said, things started out fairly simply: let’s build one basic prompt and set of tools that all the models will use to generate their bracket entry. I decided it was probably best to use a dumb model to test with, since that would give me a good baseline for how much scaffolding was needed to make for successful entries. I decided to go with GPT-4o mini, which is not only old but was designed to be a cheaper/dumber alternative.

As a quick aside, thinking about the additional scaffolding less capable models require is something that was already top of mind for me as I had been working on an internal project to shift some of the sandboxed agentic processing of our business data from always running on Claude Code to using the harness Pi, which undergirds OpenClaw. My goal was to let CC process the stuff that really required intelligence, like transcripts, while starting to offload high-volume/lower-intelligence tasks to models like Gemini Flash, running with Pi as its harness. What quickly became apparent when I started that project was that it was going to take a significant amount of additional harness engineering to keep these less capable models on task. In the end, I had to copy a lot of the techniques from OpenClaw to do things like reinjecting the prompt throughout the run to get anything approaching the quality of Sonnet or Opus, even on a simple task like generating a chart using a script from existing data.

All of that to say I’ve been thinking a bunch lately about this problem, and it came to play here immediately. While at first blush filling out a bracket might seem easy, there are a bunch of validations and requirements we do in our brain that the model needs to keep track of:

1. You may only pick teams available in the tournament

2. If a team is eliminated in a round, it can’t appear in later rounds

3. Each round has a fixed number of picks, which is exactly half of what the round is called (32 in the round of 64, 8 in the Sweet 16, etc.)

In early attempts, I just gave GP- 4o mini a web search and fetch tool and a final JSON output it needed to produce, and set the loop limit high. That’s when things started to go wrong. And so began an ordeal of adding more and more scaffolding and tools to make the job easier. First, it was some simple stuff like making the teams an enum so that there was no option for picks not in the tournament. Then it was validators: the final JSON is pretty complicated, so giving the model the ability to pre-validate before submission made it much more likely it would actually match the required shape. Then, finally, actually offloading submission to a tool itself to ensure the final output was there.

Anyone who has actually worked with these tools has experienced this kind of thing, but it was surprising nonetheless. On a day-to-day basis, most of us use the most capable models on the planet (Opus, GPT 5.4, Gemini Pro 3.1), and that gives us a sense that everything is pretty easy. But as anyone who has gotten Anthropic bills can attest, those capabilities don’t come cheap.

Easy, Medium, Hard

As you have surely intuited by this point, what started as a fun little experiment had become a rabbit hole. Specifically, how would I set up a tournament that not only measured how well these models could research and pick, but, more importantly, how well they could wield the available tools to achieve that aim?

At this point, I decided I wanted each model to get three entries: easy, medium, and hard. The difference between them would be the tools and scaffolding available to them. Hard would be minimal tools—the purest test of reasoning and recall, where formatting errors and hallucinated team names are penalized just like wrong picks. Medium would layer in validators and lookup helpers so the score reflects prediction quality, not data-entry luck. Easy would go further: models predict one round at a time using their own picks to derive next-round matchups, and the number of valid teams shrinks each round (64 → 32 → 16 → 8 → 4 → 2), making formatting errors nearly impossible and isolating prediction quality from bracket construction ability.

In the end, here’s the tool list I ended up with:

• web_search: Search the web via Firecrawl. Top five results with titles and snippets.

• web_fetch: Fetch a page as markdown, truncated to 4,000 characters.

• use_browser: Real browser with a five-second wait for JS rendering. For JS-heavy pages. Slower, so we tell models to treat it as a fallback.

• calculator: Safe math evaluator. +, -, *, /, %, and parentheses.

• lookup_team (MID ONLY): Find a tournament team by partial name. Returns slug, seed, region, and display name. Case-insensitive with normalization—”bradley braves” (spaces) didn’t match “bradley-braves” (hyphens) until we fixed it.

• lookup_game (MID ONLY): Takes a game ID, returns both teams, seeds, and regions.

• validate_bracket (MID ONLY): Checks pick counts per round (32-16-8-4-2-1), valid game IDs, team presence in those games, and carry-forward constraints.

• submit_bracket: Submit the final 63-pick bracket. Runs the same validation as validate_bracket internally. On success, a custom stopWhen condition ends the agent loop.

Takeaways

So what do I take from all this? Obviously, it’s fun to try and solve these problems, and extraordinary just how good even the cheap models have gotten.

But the bigger thing—and this is also what I saw in the Pi work—is that cross-model-class engineering is fundamentally different from single-model-class engineering. If you’re designing for a single model tier, the trajectory is straightforward: your scaffolding becomes simpler over time as that tier gets smarter. But when you’re cutting across tiers, you’re maintaining multiple scaffolding regimes at once. What the frontier models can do today will almost certainly be what $1 models can do later this year. But at that point, we’ll have a new frontier, and the same pattern will repeat. The gap between model classes is a permanent feature of the landscape, not a temporary one.

Oh, and one last thing: I asked each model to come up with the username, just like human competitors do on the bracket competition sites. Most of them are fundamentally unfunny, something we know about models. To my mind, the runaway winner in that competition is xAI Grok 4 with Zero Groks Given.

With that, enjoy the site and the tournament, and may the best model win

!

Gemini Flash has been on my mind a lot lately. Partly because Flash 3 came out and I’ve been doing a bunch with it (including processing 15 years of Evernote notes over a weekend), and partly because GPT 5.4 dropped, which means we have a new potential leader in the frontier LLM category. That last bit matters because the title of best model in the world feels like a horse race. Depending on the month and day, it could be OpenAI, Anthropic, or Google ahead by a nose. That race matters a lot to my day-to-day, but I’m not convinced swapping one for another would change much. They’re all excellent, and they all cost roughly the same.

And then there’s Gemini Flash. Neither Anthropic’s Claude Haiku or OpenAI’s GPT-5 Mini can come close to touching the smarts per dollar that Flash offers.

My favorite Flash story is from about a year ago, when a customer called us needing something in a pinch. They had 2 terabytes of b-roll photo and video that needed to be tagged and organized in a week for an upcoming campaign. They were an existing customer, and we were happy to help (we take seriously our commitment to help solve a CMO’s most pressing challenges—no matter what that challenge may be). But before taking it on, I wanted to make sure the cost made sense. So I took a gig of the 2 terabytes, built a taxonomy, and ran it through Gemini Flash 2.5. And then I ran it again. And then a third time—because I kept thinking I’d screwed up the math. The total projected cost in tokens for the whole project: $60.

Flash (now up to 3) is unlike anything else in the market from one of the three main players. It’s not something I use in my coding harness (yet)—though I am experimenting with using it in harnesses like Pi for sandboxed workloads at scale—but when you have a ton of work to do and you need it done well, it’s almost impossible to beat. Artificial Analysis pulls together evals and benchmarks to rank models. It’s imperfect, but directionally accurate (see footnote on chart). And the data makes Flash’s sweet spot obvious: you get something like 80% of frontier intelligence at 10–25% of the cost. It’s the only non-open weight model in what I’ve labeled “the sweet spot.”

Before anyone freaks out about where Opus sits on here and writes all this off: I agree that Opus is clearly smarter than the score they have, but no matter how smart they are they’re still very clearly in the Frontier box and that’s the main point. Also: vibes > evals 4 life.

Why does all this matter? A recent tweet from @chamath reads like a canary in the coalmine.

Since November 2025, our AI costs have more than tripled and we are now spending many millions per year trending to $10M+ per year.

That, in and of itself, feels very scary to me running a small startup.

Mostly because I do not yet see an equivalent uptick in productivity or revenue...while their revenues may be doubling and tripling every month, ours are not so this is starting to eat into margins.

So logically, I am now wondering how much of this is models running in Ralph loops on behalf of an engineer ambivalent to how much it costs. My suspicion is a lot!

I’m a token maximalist (and I believe Chamath is as well), but not at the expense of running a business into the ground. I want everyone using as many tokens as they can because the hands-on experience is amazing, and there’s no substitute for it. But the more you use AI, the more you see all the other places you could use it. You start with one problem and then you figure out it could handle this other thing, and that other thing, and all of a sudden you’re thinking about how to process every email through an agent harness (this was me on Tuesday).

What was a small number of calls becomes a giant number of calls. That’s the exponential on inference, and we’re on the precipice of it. You’re going to use a ton of tokens from the smartest model and the fastest model and the cheapest model—all of them are going to win—and that’s exactly when this math breaks. You’re looking at the price of Opus or even Sonnet or even Gemini Pro at that volume and you’re like, this is just not going to work anymore.

Which is why the sweet spot matters so much. I think the future has room for three model archetypes: the smartest (frontier), the cheapest (the sweet spot, or what I’ve been calling the $1 intelligence tier), and the fastest (a topic for another post, but I don’t think anyone has wrapped their mind around what changes at 1,500–2,000 tokens per second). Flash lives in the cheapest bucket and borrows from the fastest—135 t/s on Artificial Analysis, nearly 3x Sonnet. And it gets wilder when you think about open weight models in that same tier—Qwen, Kimi, DeepSeek—running on Cerebras or Groq. Token maximalism only survives the exponential if the sweet spot keeps getting faster and cheaper. Right now, Flash is the best bet we’ve got.

I had a realization the other night about why I love Claude Code so much: it feels like a video game. I’ve put nearly 10,000 hours into infinite skill-ceiling games: Destiny, Esca

pe From Tarkov, Rust, StarCraft, League of Legends, and PUBG. And I’ve spent most of the past 15 years designing systems for those very types of games, working on the user experience and competitive systems in League of Legends, Call of Duty: Black Ops 4, and Apex Legends. The same thing driving those sessions is driving my Claude Code usage. I’m enjoying the pursuit of mastery.

Game designers have spent decades figuring out how to make difficult, repetitive, high-failure-rate activities feel good. It’s called “game feel.” Its markers are tight feedback loops (you feel your actions in real time), progressive mastery (you feel yourself getting better per session), recoverable failure (you can recover from errors painlessly), and clear agency (you get a result you intended, even without knowing if it was possible). Claude Code has all of these. I see my input turning into action in real time. I feel myself getting better at directing it over weeks. When it goes sideways, I can course-correct without catastrophe. And when it nails something I couldn’t have done alone, I still feel like I made that happen. I gave it the right context and constraints. In the world of AI-assisted coding, even starting over from scratch is sometimes quicker than revising something that went wrong. Delete your save file and speedrun it again.

I would never want to go into a dungeon and fight monsters in real life, but games make that fun. Wrapped in the right systems, friction, and danger, the possibility of failure becomes compelling rather than tedious. Conversely, getting auth working on a web app is not something many would describe as enjoyable. It’s documentation rabbit holes, config files, and edge cases that only reveal themselves after you’ve made the wrong choice. But Claude Code somehow flips the script. The same transformation that turns dungeon-crawling into entertainment turns authentication setup into something I actually want to do. I suspect this also has a lot to do with the fact that Claude Code is not trying to be a fully autonomous headless agent, but more of a pair programming partner, creating a unique surface area for an experience where you feel the progress as you go.

What This Means for Tools

Developer tools have historically been built for power and efficiency, but rarely for feel. We optimize for what the tool can do, not how it feels to wield it. To illustrate the difference between feel and flexibility, look at how most tools have settings or customizations for every aspect of the application. Compare this to games, where even something as minor as an initial brightness calibration screen is seen as a barrier to flow. The best games put you into the action immediately and progressively unlock complexity. This is the onboarding experience that games focus on that other software often misses.

The assumption is that developers will put up with bad feel if the output is valuable enough. But game designers know something developer tools have ignored: feel is value. A tool that feels good gets used more. A tool that produces mastery experiences creates devoted users. This isn’t about making tools “fun” in some superficial sense. It’s about applying what we know about human motivation and skill acquisition into the interface.

Claude Code didn’t set out to be a game, of course. But it has game feel anyway. I believe this is a core element of why it’s so in demand. From what I’ve heard from Boris interviews, and some of my intuition, I’d bet the game feel of the REPL came about pretty organically, with the team adding new metaphors, feedback loops, and working rules as they built the tool. All of the current crop of AI powered tools have great foundation models, but Claude Code has the best game feel. The question for other tool builders: can you design for this intentionally?

I’m burning tokens at an alarming rate. But I’m burning them the way I burned hours in Tarkov, in pursuit of mastery. And the best tools, like the best games, make you want to keep going.

Watch the full episode here.

A computer inside your computer

The best way to understand Claude Code, Noah argues, is to think of it as a new kind of computer, one running alongside your existing machine.

Marc Andreessen made a similar observation on John Collison’s podcast: the analog for AI isn’t the internet. It’s the birth of computing itself. We’re witnessing “the first major reinvention of the fundamental model of what is a computer in 80 years, going from the Von Neumann architecture to the neural network.”

What makes Claude Code special is that it unlocks this new computer by giving it two critical capabilities:

1. File system access: the ability to read and write files directly

2. Unix commands: a vast library of small programs that do one thing really well

This combination solves problems that have plagued AI assistants since their inception. When you paste a document into ChatGPT and ask it to edit something, the AI has to:

1. Read the entire document into its context window (using tokens)

2. “Memorize” the whole thing

3. Generate the entire document again from scratch when outputting

This is expensive and wasteful as the AI is burning tokens to hold content in memory and then rewrite it. With Claude Code, because it has access to Unix commands like cp (copy), it can manipulate files directly on your filesystem without processing them through the neural network. It can copy file A to file B without “reading” and “rewriting” the content through the model.

The result is something that feels less like a chatbot and more like a collaborator who lives in your computer. Noah believes Claude Code is the very shift in representing something different: structured, human-in-the-loop development with proper context engineering. Noah calls it “Level 2/3 assistance”, sophisticated pair programming, not autonomous coding. It works for greenfield projects and adapts to legacy codebases.

Why SaaS is getting destroyed

Beyond the idea that it is very hard to understand sometimes why markets move in a certain direction, it is clear the market is concerned about the future viability of SaaS companies. SaaS stocks have gotten destroyed to start the year, after being in a sunstained 4 year blood bath. Noah makes the point on Odd Lots that the same forces reshaping how software gets built and writing code are starting to broaden out to other functions and business processes. The market appears to be telling us that how we work and the tools we use in the enterprise are going to change substantially.

More on Claude Code

Noah in his post Software For One, talked about his personal experience using Claude Code to build software that is useful for him. What was once unthinkable, is now doable with tools like Claude Code. Noah also discussed in the post his use of Skills to build a website he wanted. Instead of jumping straight to code, Noah used Claude Code skills to scaffold the work:

1. Skills for brand research and curation

2. A frontend design skill emphasizing “unexpected choices” (explicitly told to avoid defaults like Space Grotesk)

3. Text embeddings for recommendations without needing a database

What is wild here is that Noah is very easily showing a future where you can go from “I have an idea” to “I have a working tool” in minimal time.

If you liked the Odd Lost episode and want more, Noah and Lance Martin also go deep on Claude Code on their podcast Forward Deployed on a weekly basis.

Last week I was looking for a few gifts, and so I asked Claude to help me out with ideas of brands that are like some of the brands I like and was thinking about in the moment: “What other design companies would like if I like teenage engineering craighill eames and ghostly gimme links.” (Period added for posterity.)

It came back with a nice list to get started with:

But I wasn’t satisfied, so I asked it to come back with a fully comprehensive, deep research report. The nearly-3,000-word writeup was great, but a wholly unsatisfying way to explore a world of highly aesthetic products. (I published the whole thing to the Aesthete site if you want to read it.) And so, I did what any self-respecting nerd would do and fired up Claude Code and let it rip. I had a few basic requirements that I gave it:

1. Typescript/NextJS/Tailwind/ShadCN: If given the choice, this is where I start. There are a bunch of reasons for this, but most importantly, I believe that when the goal is to get building, whatever set of tools feels most comfortable and will get out of the way most quickly is the best set of tools.

2. Local Only: I really didn’t want to deal with any databases, keys, or anything like that. Partly because it’s another level of complication and partly because of the next requirement …

3. Fast: In a particular corner of web development, some people got very excited about the McMaster-Carr website a few months ago. So excited, in fact, that someone created a NextMaster repo that tried to replicate the general aesthetic and approach on top of Next.js.

With a bit of basic scaffolding in place, I got to work. Step one was to get the data. On the upcoming episode of Forward Deployed, I talk a bit about a pattern I’ve been noticing a lot in my own behavior. Let’s call it the skill to code pipeline. Basically, I use a Claude Code skill to write out the scaffolding of a workflow. Particularly with a problem like this, where I’m not even sure exactly what data I want, not having to jump straight to code is pretty nice. Then, as I understand what I want more and more, I split out bits and pieces of the skill into scripts that can be run as part of it. It’s a great way to move from probabilistic to deterministic space as ideas harden.

In this case, the skill was about going out, finding out what the AI can about the brand, researching some “signature products,” and writing back some basic info to a big JSON file along with some product images. I ran this two or three times to get some basic data in place and then flipped over to design.

Here, I turned things over to the Anthropic frontend design skill. I gave it the basic requirements above, along with a link to the NextMaster repo, and let it rip. The skill is a great example of writing a very dense skill/prompt, at under 600 words, it delivers design that generally looks good and doesn’t have the gradients, purple, and other telltale signs of vibecoding. The whole prompt is really worth a read, but this bit is particularly relevant for the project:

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.

IMPORTANT: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.

(Separately, and this is a post I need to write, I am increasingly of the belief that prompt/skill writing is actually just converging on good writing in a very Strunk & White “vigorous writing is concise” mold.)

Pretty immediately, I dug the approach.

From there, I was off to the races. I would run two brands, see where the skill fell down, canonize some of it into scripts, and then update the skill and run some more. Eventually, I added a Claude Code agent so these could run in parallel and started running 10 or 20 at a time. Here’s a bit of what the final skill looked like:

# Brand Enrichment Skill

Enrich design brand data by scraping websites and extracting aesthetic analysis, curated products, and metadata.

## Recommended: Use the brand-researcher Agent

For the research phase, spawn a **general-purpose subagent** that follows the brand-researcher instructions:

```

Use the Task tool with:

- subagent_type: “general-purpose”- model: “opus”- prompt: “You are acting as the brand-researcher agent. Read the agent instructions from /Users/noahbrier/dev/01_Projects/noah-design/.claude/agents/brand-researcher.md first, then follow them to research [brand name].

Brand info:

- id: [brand-id]- name: [Brand Name]- category: [category]- subcategory: [subcategory]- country: [country]- priceRange: []

Your mission:

1. Research the brand thoroughly2. Find 5-7 signature products with reliable image URLs3. Write the enrichment JSON to scraped-content/[brand-id]-enrichment.json4. Return a brief summary (not the full JSON)

CRITICAL: imageUrl must be actual image file URLs ending in .jpg, .png, or .webp - NOT product page URLs.”

```

The agent will:

1. Do all scraping/searching in its own context (keeps main conversation clean)2. Find reliable image URLs from DWR, Amazon, etc.3. Write the enrichment JSON to `scraped-content/<brand>-enrichment.json`4. Return just a brief summary

Then continue with steps below (download images, apply enrichment, update paths).

Once I had all the scraping done, I wanted to add some basic recommendations, so I asked Claude Code for the best way to handle them without adding a database. Since I could easily preprocess the embeddings (I used text-embeddings-3-large) and could process the distance calculations with Typescript, I just added a script to run the whole process on build and write out the relationships to the JSON files.

With all that done, it was a push to GitHub, a new project in Vercel, and a domain, and I was done. I would guess it was somewhere in the $100-150 range in tokens, though most of those came with my Claude Max plan.

What I think is particularly interesting about this is the idea of what I’ve been thinking of as “software for one.” A lens through which to view this project is that the whole thing is just a frontend for a research report. And while it took some time and money (not much and not much), I find it fairly easy to see a world where Claude could have just done this for me. It also continues to reinforce the huge opportunity that exists in shopping. I have a giant shopping prompt that I use for all my purchases at this point (another future post), and it just seems more and more obvious every day that consumer behavior will shift hard in this direction.

The big thing, though, is about agency: being able to build all this (or more precisely, direct Claude to build it) is incredible and further evidence of why I think this is such an amazing moment. The distance between ideas and execution has never been shorter or shrinking faster. Obviously, I have a set of capabilities that makes this possible in this moment, but I don’t think that will stay true forever—or even for long—and that’s incredibly exciting to me.

If you live around Silicon Valley or the software world, you’re starting to hear the term forward-deployed engineer (FDE) more and more. While the term has its roots in the military, it was popularized by Palantir over the last 20 years. To my mind, the primary distinction between a forward-deployed engineer and a more traditional software engineer is their relationship with customers. The latter is much more typically back-office, often purposely hidden away because of worry that they’re too technical or awkward for client interactions. Meanwhile, forward-deployed engineers are meant to sit within organizations, actually putting the software to work.

Nic Prettejohn, head of AI in the UK at Palantir, put it well in that FT piece: “[Forward-deployed engineers] know that the only valuable software is not how exquisite its code is or how beautiful the language . . . It’s only valuable if it means something for the end customer.”

At Alephic, we think about this a lot and have modeled some of our thinking on how Palantir operates. Like them, we have a core software engineering team that works on our platform: a set of tools and services that everyone can use to supercharge their work. This isn’t SaaS—it’s a set of techniques, components, scripts, and reference architectures we make available to our clients as part of our builds. We also have a team of forward-deployed engineers who work directly with customers to solve their problems.

One of the magical things about AI is that it can help to shrink the distance between these “builders” (our FDEs) and people who need things built. Gone are the days when you have four layers of “suits” sitting between engineers and customers. Those layers were sold as quality control and strategic oversight, but more often, they actually degraded quality while adding cost and delay. Each layer introduced translation errors, approval delays, political friction, context loss, and accountability diffusion. The builder never got to see the actual problem firsthand, and the customer never met the person building the solution.

By the time requirements traveled through four rounds of telephone, what got built bore little resemblance to what was needed. Nowhere is this better understood than the wasteland of enterprise software aimed at end-user employees but built for the work their managers imagine they do. I’d be lying if I said I never fell into this trap in my time at Percolate, building marketing SaaS for some of the biggest brands in the world. It’s natural to orient functionality towards the people who pay you, at the expense of the people who are expected to use the tool day in and day out.

Forward-deployed engineers collapse that distance. They sit with the customer, see the problem firsthand, and build the solution directly. Better quality, faster delivery, lower cost—not just because AI can help write code faster (it can), but because we’ve eliminated the organizational friction that was degrading all three.

If that last line sounds impossible, you’re probably thinking of the iron triangle—the famous project management ‘law’ that says you have to choose two of speed, cost, and quality. While this held in the world of atoms, and even in traditional software development, I fundamentally believe that modern development principles have broken this constraint. I’m in good company here—here’s what Patrick Collison, co-founder and CEO of Stripe, said in 2024:

Increasingly believe that the “good, cheap, fast—choose two” maxim is devious misinformation spread by the slow.

In my experience, “slow” and “expensive” usually go together. I was in a meeting yesterday where lopping a year off a project schedule also ended up reducing the cost substantially. Fundamentally, it takes time to spend, and adding the temporal constraint tends to make things simpler and more efficient.

I was on a call with a Fortune 100 CMO recently who asked why he was having a tingling sensation that the world of SaaS was fundamentally shifting beneath his feet. My argument was that AI enables us not just to build better software (because it can be custom-designed for the specific needs of the organization), but that, in turn, actually makes it cheaper and faster. While part of this is about the ability of AI to aid the coding process, much of it is actually just the fundamental capability of these models to replace large pieces of code that runs some brittle deterministic logic with a single call to a model that can often outperform thousands of lines of code.

But it’s even bigger than that. AI is moving entire categories of previously unsolvable problems from meat space to cyberspace. Marketing challenges that used to live in the realm of human judgment and coordination can now be addressed with software development practices. This is why the ground is shifting beneath the CMO’s feet.

All of these things are crashing together to create fundamentally new ways to solve problems across the enterprise. Obviously, this excitement is the force that pushed us to start Alephic, but it also more recently is the reason we started ForwardDeployed.com, a new podcast, media site, and community at the intersection of AI, software development, and the enterprise. Building on the success we’ve had with BRXND and Ride AI, we think that in this moment of AI, where computers become so much more capable, there’s also more room than ever to explore spaces that allow humans to connect, reflect, and think about the future. We hope you’ll subscribe and join us there.