# Jake Quist > Jake Quist's blog about software engineering, AI, and technology. --- # IDEs Are for Micromanagers Six months ago, if you’d asked me whether a terminal-based coding tool could compete with a full IDE, I would have chortled into my coffee. Six months ago, Cursor (and friends) had it all: slick interfaces, deep integrations, and massive funding. Claude Code was just a TUI. It felt like Anthropic wasn’t being serious about the space and threw a half-baked product into the wild. Yet, here we are. The above chart is Google Trends for “Cursor” vs “Claude Code”. Claude Code went from essentially zero to overtaking Cursor in about twelve months. This is the source of much anxiety amongst founders in Silicon Valley right now. You spend years building a product, and then a big lab walks into your market and eats your lunch. The CC vs Cursor story seems to validate that fear perfectly. Anthropic decided to compete, perhaps as an afterthought, and now they’re winning. But it dawns on me: Claude Code isn’t winning because they have a secret LLM. Cursor uses the same Claude models through the same API. The raw intelligence powering both tools is basically identical. Anthropic does have some structural advantages here: they can fine-tune for their own agentic loops and whatnot, but I don’t think it’s sufficient to explain what’s happening. Cursor is a company laser-focused on developer tools, and you would think they’d be better at building the last mile of polish that would make them win. For example, I’m sure Cursor has some really smart people who think all day about the right system prompt for a coding agent. I’m not sure Anthropic had those resources to spare 6-12 months ago. Cursor is the specialist, Anthropic is the generalist. You’d expect the specialist to win. And yet I think Claude Code is winning not because of its access to better models, but because of UX. The TUI. When I first used CC, I thought the minimal interface was a limitation. Now I realize it’s the superpower. Working in CC doesn’t feel like programming. It feels like delegating. I describe what I want at a high level, and the agent executes. I regularly run five CC sessions in parallel across different parts of a codebase. I don’t write code. I provide vision and milestones to the team. Cursor, for all its polish, still puts me in the programmer’s seat. I’m watching diffs, approving line-by-line changes, tabbing through suggestions. It’s pair programming with a very fast partner. That’s useful, but it’s a fundamentally different mode of work. The IDE, by its nature, keeps you in the weeds. You’re a micromanager with a really good assistant. The TUI removes all of that. There are no diffs to review inline, no gutters full of suggestions, no tabs competing for your attention. There’s just a conversation and a codebase. That spareness, which I mistook for laziness, actually pushed me into a completely different relationship with my code. I went from line-level thinking to system-level thinking. This matters for founders because it inverts the conventional fear. The worry is that the big labs will crush startups because they have better models. But CC isn’t winning on models. It’s winning on DevEx. Specifically, it’s winning because someone (perhaps accidentally) discovered that removing features could be more powerful than adding them. The best developer experience innovation of the past year wasn’t some space-age way to navigate your code. It was the revival of a text-based interface that frees you up to think at a higher level. This suggests the defensible ground for startups isn’t where most founders think it is. If you’re building on top of LLMs and your moat is “we have better prompts” or “we fine-tuned on more data,” you’re competing on the same axis as the labs. They will eventually do it better than you and will crush your soul in the process. But the labs are big, bureaucratic machines. They are structurally hindered from taking big risks on dimensions like interaction paradigms. They’re not thinking about the weird, counterintuitive product decision that changes how people relate to their tools. Anthropic stumbled (I believe) into this one and I think it’s going to be really hard for them to do it again (innovators dilemma, if you will). The next version of this insight is sitting there waiting for someone to find it. I think the founders who survive the age of AI labs won’t be the ones with the best model access. It will be the ones with crazy-enough ideas that win on the non-obvious dimensions. --- # Now Is a Great Time to Be a People-Oriented Engineer Right now I’m running four instances of Claude Code on different projects, one instance of Codex, and one of Gemini. Two of the projects are serious. The rest are toy apps I may never ship. I glance at each one every few minutes, approve a change, redirect an approach, catch a hallucination. It feels like spinning plates. It also feels familiar. This is what happened when processors went from single-core to multi-core. The individual cores were actually slower than the single-core chips they replaced. Measured in isolation, it was a downgrade. But it didn’t matter, because you could run things in parallel, and the aggregate throughput was so much higher that it felt like magic. That’s what programming feels like now. Each AI “core” is worse than me at writing code. If I sat down and wrote everything myself, the resulting codebase would be cleaner, the abstractions more elegant, the architecture more coherent. I know this. And I also know I’d get far less done. So I don’t sit down and write everything myself. This is a strange thing to come to terms with if you spent years caring about craft. For a long time, the thing that separated great engineers from average ones was taste in abstraction. You’d look at a massively distributed system and find a way to position the blocks so the whole thing became easy to reason about. It was a puzzle, and a beautiful one. You could look at someone’s code and know within minutes whether they were good. We built identities around this. The elegance of the solution was the work. That kind of intelligence is becoming less valuable. Not worthless, not yet, but less valuable, in the way that beautiful handwriting became less valuable after the printing press. The press didn’t make handwriting ugly. It just made it matter less. I think most engineers feel this and don’t want to say it out loud. So let me say it: if your sense of professional pride is grounded in the craft of writing elegant code, the next few years are going to be painful. That deserves to be acknowledged, not hand-waved away. But there’s something on the other side, if you’re willing to care about people more than you care about code. A friend of mine runs a small accounting firm. A couple of years ago, he wanted custom software: a client tracking system that would tie into Canopy and his tax tools. Simple enough, he thought. He just needed an engineer. What he actually needed was a PM, a designer, and a small team of developers. He couldn’t afford that, so the project died. This is the normal outcome for small businesses with software needs. They settle for generic tools that half-fit, or they go without. Now the world is different. A single engineer with a multi-core AI setup could build what my friend needed in a week or two. No PM, no designer, no team. Just someone technical enough to wrangle the AI tools and curious enough to sit down and understand the actual problem. My friend was ready to pay for this. And he’s one accountant. Every niche professional, in every small town, is overpaying for generic software that half-serves them. The long tail of underserved businesses isn’t just long, it’s deep. There are so many real problems that were never worth solving before, because the cost of building software was too high. Most people are missing something: the engineers are the ones with the most power right now. Despite all the coverage about AI replacing programmers, we’re the ones who actually know how to use these tools well. We know when Claude is hallucinating. We know what good architecture looks like even if we’re not writing it by hand. We know when to approve a change and when to redirect. My accountant friend cannot do this yet. Neither can most product managers, designers, or entrepreneurs. But they will. The tools will get better. The supervision will get lighter. The window where technical fluency gives you an unfair advantage at building products, not just writing code, is real, but it’s finite. Maybe two to five years. Maybe less. The question is what you do with it. My first instinct was to do nothing. To keep writing my own code, keep polishing my abstractions, and wait for the hype to pass. That instinct was pure self-preservation. The old craft was the thing I was good at, and I didn’t want it to stop mattering. I think a lot of engineers are in that same place right now. Or you could do the other thing. You could go find that accountant. You could sit with them and understand their actual problems. Not the abstracted, generalized version of their problems that enterprise software solves, but their real, specific, messy ones. You could build something for them in a week. And then you could do it again for someone else. The obvious objection is that this is just consulting. And in the old world, software consulting was something most engineers avoided for good reason: it was expensive to deliver, hard to scale, and the margins were thin. You needed a team and months of work for every client. But when the cost of writing the software drops to nearly zero, the economics change. You can serve clients who could never have afforded custom software before. You can maintain what you build in a few hours a month. Retainers, hosting fees, ongoing support: there are ways to make it recurring. I won’t pretend this is as sexy as “my SaaS just hit $5M ARR.” It’s not. But at this point, when nobody knows what the winning model even looks like, maybe that’s fine. Nobody knows exactly how the economics of this new world will shake out. Maybe consulting with retainers is the thing. Maybe you build for 15 accountants and notice they all need the same feature, and that becomes a real product. Maybe it’s something nobody has a name for yet. I don’t know. But I’m fairly sure that the engineers who spend the next two years out in the world, talking to people and building for them, will stumble into whatever the model turns out to be. And the ones who stay home writing elegant code will have elegant code and nothing else. Say you take that path. You spend a year building small, tailored tools for real people. The code is mediocre. You know it’s mediocre. But the products are good, because they solve real problems, and along the way you develop something more valuable than clean abstractions: you develop an understanding of what people need. That understanding builds on itself. When the tools get good enough that non-technical people can build their own software, the engineer who spent the window writing beautiful code will have beautiful code and nothing else. The engineer who spent it learning what accountants and dentists and farmers and logistics managers actually need will have something durable: domain knowledge, customer relationships, product instincts. The code was always ephemeral anyway. We just pretended it wasn’t because it was so satisfying to write. I think the new craft is understanding people’s problems. Which, if you think about it, is what software was always supposed to be about. We just got so caught up in the elegance of the medium that we forgot it was a medium at all. --- # What Happens To Developer Tools After Claude Code? If you’re building a developer tool right now, you probably have a launch plan: Post it on Show HN. Grind for GitHub stars. Maybe host a hackathon or two. You know, the standard playbook. I suspect this playbook will soon become obsolete. Not because it doesn’t work on humans, but because humans are no longer the ones choosing the tools. It’s not that humans have left the loop. A human still decides which tools end up in a project. But increasingly, that decision gets mediated by an AI coding agent. Watch how software actually gets built now. A developer doesn’t read your README and evaluate your API. They tell Claude Code “I need to transform this dataset” and Claude Code either reaches for your tool or it doesn’t. This changes the distribution game in ways I don’t think most developer-tool founders have internalized yet. The old funnel was: awareness → landing page → docs → adoption. A human saw your Show HN post, clicked through, skimmed the README, and maybe tried it out. Every step was optimized for human attention and human decision-making. The new funnel looks different. The human says “do X.” The AI agent decides how to do X. If the agent knows your tool exists and understands how to use it, you win. If it doesn’t, you don’t. The human never even saw your name. So the question becomes: how does an AI agent come to know about your tool? There are really two distinct things happening here: The first is training data. If an LLM has seen enough examples of your tool being used — in blog posts, tutorials, Stack Overflow answers, GitHub repos — it develops an intuition for when and how to reach for it. This is the passive channel. You can’t directly control it, but you can influence it. The second is tool integration. MCP servers, CLI interfaces, well-structured APIs — the mechanisms by which an AI agent can actually invoke your tool at runtime. This is the active channel. You control it completely. Most people fixate on the first one because it feels more mysterious. But I think the second one is where the real leverage is, at least right now. If your tool has a clean MCP integration and good structured documentation, an AI coding agent can use it today regardless of whether it appeared in the training data. The training data question matters more for discovery — whether the agent thinks to use your tool unprompted. This leads to what I think is the most interesting question in developer-tool distribution right now: is there such a thing as SEO for LLMs? The cynical framing is: do I need to manufacture social proof? Do I need to convince fifty friends to write blog posts about my tool so that Anthropic’s next training run picks them up? The honest answer is: kind of, but it’s not as sinister as it sounds. LLMs learn from the public web. If nobody writes about your tool, it functionally doesn’t exist to the model. That’s not some opaque ranking algorithm punishing you. It’s just the physics of how these systems work. A tool with a thousand tutorials will be better understood by the model than a tool with three. This was always true for humans too — it’s just that now the “reader” processing all that content is a neural network instead of a person scanning Hacker News. What worries me is the second-order effect. Well-known tools generate more public content. More content means better model understanding. Better model understanding means AI agents recommend those tools more often. Which makes them more well-known. This is a rich-get-richer dynamic, and it creates a brutal cold-start problem for new tools. If you’re an established project with years of blog posts and Stack Overflow threads, the AI era is a tailwind. If you’re launching something new, you face a bootstrapping challenge that didn’t exist before: you need to get into the models, and the models won’t find you until you’re already popular. So what should a developer-tool founder actually do about this? First, we need to treat documentation as our primary marketing channel. Not documentation in the traditional sense — a dry API reference that exists to serve existing users. Documentation as content. Rich examples, explained end-to-end. Common workflows, spelled out verbosely. The kind of writing that a human might find tediously thorough but that an LLM will absorb perfectly. Your docs need to be optimized for a reader with infinite patience and zero intuition. Second, prioritize an MCP server. If a developer’s Claude Code instance can invoke your tool directly, that’s worth more than a thousand GitHub stars. Stars are a vanity metric for humans. Tool integration is a distribution metric for agents. Third, rethink what “content marketing” means. It used to mean writing blog posts to build an audience. Now it means producing the training data you want future models to learn from. Every tutorial you write, every example you publish, every answer you post — it’s all input to the next training run. The audience for your content is partly human and partly statistical. I don’t know if this is the right framework. It’s possible that six months from now, tool discovery will look completely different — maybe there will be an app store for MCP servers, or Anthropic will launch some kind of tool registry, and none of this grassroots optimization will matter. But I suspect the core insight will hold: if you’re building a developer tool in the AI era, your most important user can’t attend your hackathon, doesn’t care about your logo, and will never star your repo. It just needs to understand what your tool does and how to call it. Everything else is noise. --- # What Happens When AI Can Write All Your Software? A few weeks ago, while refactoring some of my old code, I asked an LLM to write a RingBuffer implementation in TypeScript. I’ve written these before in other languages. I know the tricky edge cases, especially around concurrency. To my surprise — and mild horror — the LLM wrote it flawlessly. Better than I could have. No feedback necessary. No vibing at all. Then I asked it to build something slightly more ambitious: a personal CRM. It fell apart. Buttons didn’t work. When they did work, the backend threw exceptions. I eventually vibe-coded the fixes and got it running. But when I looked at the backend code, it read like something an undergraduate might write — technically correct in places, but with no sense of how the pieces should fit together. How can this be? The same system that writes better low-level code than me produces amateur work on what should be a straightforward application? I think the answer is complexity. Note that both prompts were equally vague. “Create a RingBuffer” isn’t much more specific than “Create a personal CRM.” The difference isn’t in the specification — it’s in the internal complexity of the task itself. A RingBuffer is self-contained. It has a few moving parts, clear boundaries, well-defined behavior. A CRM, even a “simple” one, is a web of interconnected concerns: data models, API design, state management, UI flows, error handling, validation — all of which need to work together coherently. My hypothesis: humans are remarkably good at context-switching. When I’m looking at a React component, my attention is tuned to one set of concerns. When I jump to database code, I activate a different mental mode. I can hold the big picture while zooming into specifics, and I can do this dozens of times per hour without losing the thread. Current LLM architectures seem to struggle with this. Maybe it’s a training issue. Maybe it’s architectural. I don’t know. But the pattern is consistent: small, contained tasks get done brilliantly. Complex, interconnected systems fall apart. If this is true, what does it mean for the future of software? LLMs will commoditize the parts of software development that have lower complexity. They’ll continue to struggle with the parts that have high complexity. At first glance, I’m tempted to frame this as a frontend vs. backend issue — frontend code is often considered less complex than backend code. But I don’t think that’s actually right. There are plenty of frontends that are extremely complex with lots of interconnected parts, while the backend is a simple CRUD database. The principle is simpler: humans will own whatever is complex; LLMs will handle whatever isn’t. This suggests an interesting development pattern. Imagine your team builds a super-complex-accounting-rules internal package — all the gnarly domain logic, validated and tested by humans who understand the stakes. Then you hand that package to an LLM and say: “Build me an iOS app that uses this.” The LLM treats the complexity like a black box; it doesn’t have to understand it. It just needs to wire up a relatively simple interface. What might this look like in five years? I suspect most human developers will be working on complexity — wherever it lives in their stack. Business logic. Integrations. The parts where mistakes are expensive and domain knowledge matters. Meanwhile, LLMs will be printing out interfaces. Your company’s ERP system will have a human-built core with predictable, accountable logic. But the accounting department might generate their own Windows desktop client while the sales team gets a native iPad app. Because it’s “just” presentation code and minor bugs are acceptable. The bugs are annoyances, not disasters. And when bugs do appear, users can ask the LLM to fix them — without ever touching the core logic owned by human developers. Counterintuitively, this might be good news for the SaaS giants. If LLMs can’t reliably rewrite Salesforce’s backend — all that accumulated domain logic and integration complexity — then Salesforce’s moat is intact. But now users can print their own interfaces on top of it. The plugin ecosystem might die, but Salesforce would probably make that trade. Picture what this world actually looks like. Salesforce is still around. Your company still runs on its ERP system. But now you get to choose how you interact with it. Maybe you’re a sales manager who wants a podcast-style summary of yesterday’s numbers to listen to on your commute. Maybe you’re a developer that prefers a CLI to submit your expenses. Maybe you have a visual impairment and need a high-contrast, screen-reader-optimized interface that the vendor never bothered to build. The complex parts of the stack remain first-class human concerns. But everyone gets to customize their last mile. I hope I’m right about this. I think this vision is genuinely exciting. I’d love to customize how I interact with the big software systems I’m stuck using. But maybe I’m wrong. Maybe the big vendors will try to block LLM-based integrations — that seems like the obvious knee-jerk reaction. Or maybe LLMs will keep advancing until they can handle the complex parts too, and actually put Salesforce out of business. Who knows. I just have a guess about what the next few years look like. And my guess is that complexity is the bottleneck — for now. --- # Big Tech vs. OpenClaw OpenClaw launched last week. If you haven’t tried it yet, it’s essentially a way for AI to control your computer on your behalf. You describe what you want done, and it does it—clicking, typing, navigating, the whole thing. It’s impressive technology. But the most interesting thing about OpenClaw isn’t what it can do. It’s what it means for the companies that have spent the last fifteen years figuring out how to capture and hold our attention. Here’s the thing about social media that nobody at these companies will say out loud: the product only works if you’re using it badly. Facebook and LinkedIn don’t make money when you efficiently check your messages and leave. They make money when you intended to check your messages but somehow ended up scrolling for forty-five minutes through engagement-optimized content you never asked for. OpenClaw breaks this model. I can now say “notify me when someone sends me a LinkedIn message, but filter out the recruiters and the people trying to sell me marketing services.” That’s it. I never have to open LinkedIn again. I get the utility of the network without the tax of the feed. This might sound minor, but I think it’s actually a very big deal. Consider what LinkedIn has really become. Ostensibly it’s a professional network. In practice, it’s one of the most valuable proprietary datasets on the planet. Most VC firms I know are scraping it, one way or another. It’s one of those open secrets in the industry—a lot of people are doing it, nobody talks about it publicly, and LinkedIn seems to look the other way as long as you’re not too blatant about it. Before OpenClaw, getting useful data out of LinkedIn required either paying a fortune for their official APIs (which are deliberately hobbled), or building and maintaining sophisticated scraping infrastructure that played an endless cat-and-mouse game with their bot detection. Only well-funded companies could do it effectively. Now? Any VC with a spare Mac Mini can fully automate their deal sourcing. OpenClaw will just log in as you, browse around, and extract whatever you need. It’s not even really “scraping” in the traditional sense—it’s just using the site the way a human would, except the human is an AI following your instructions. The obvious question is: how will these companies respond? The first line of defense is CAPTCHAs. LinkedIn and Facebook already have state-of-the-art bot detection. They could turn up those knobs. But there’s a limit to how far they can push this without alienating legitimate human users. Make the friction too high and people stop using your product. And crucially, OpenClaw isn’t really distinguishable from a slow, methodical human user. The patterns are the same. The pixels are the same. My hunch is that we’re going to see a hard push toward native apps. If you’re running a hypothetical native LinkedIn app on your Mac, that app can inspect your machine. It can see what processes are running. It can detect screen recording. It can phone home and report suspicious activity. A native app has capabilities that a website in a browser simply doesn’t have. Why do these companies push their native apps so aggressively? Why does Reddit constantly nag you to install their native app? I always assumed it was just about engagement metrics or notification permissions. But now I wonder if part of the reason is that native apps are defensible in ways that websites aren’t. Longer term, I wonder if we’re going to see something even more aggressive: computer-use DRM. OpenClaw is currently the most popular tool in this space, but it’s really just part of a broader “computer-use” category that’s emerging. Anthropic, Google, and several startups are all building AI that can operate a computer the way a human does. This isn’t going away. If anything, it’s going to get much better very quickly. The question isn’t whether computer-use AI will become ubiquitous—it’s whether platforms will find ways to lock it out. And this isn’t as far-fetched as it sounds. We already have precedent. Try taking a screenshot of Netflix content in your browser. On most systems, you’ll get a black rectangle. The browser, working with the operating system, actively prevents you from capturing DRM-protected video content. This isn’t a bug—it’s a feature, negotiated between content companies and platform vendors. Imagine the same technology applied to social media. Your operating system could expose an API that tells apps whether any automation software is running. LinkedIn’s website could simply refuse to render if it detects OpenClaw. Apple and Microsoft, under pressure from major advertisers, might be convinced to build these capabilities directly into their platforms. Would this happen? A year ago I would have said no. Platform vendors have historically positioned themselves as neutral—they provide the infrastructure, they don’t pick sides in fights between applications. But the pressure from big tech is enormous, and the advertising dollars are real. The optimistic case is that this is the beginning of the end for attention-harvesting as a business model. If users can finally automate away the junk and extract just the value from these networks, maybe the networks will have to evolve. Maybe LinkedIn becomes a pure utility—a directory and messaging service—and finds some other way to make money. Maybe Facebook finally has to compete on actual value rather than addictiveness. The pessimistic case is that we get a new kind of platform lock-in. Not just network effects keeping you on a platform, but actual technical barriers preventing you from using that platform in any way other than what the company intended. An internet where the sites you visit can veto the software you run. I don’t know which way this goes. But it does seem like OpenClaw and tools like it represent something new in the balance of power between users and platforms. For the first time in a long time, users have a tool that lets them interact with these services on their own terms. Big Tech has gotten very good at capturing human attention. Now they may have to figure out how to capture attention from robots. That’s a different game, and I’m genuinely curious to see how they’ll play it. --- # OpenClaw is What Apple Intelligence Should Have Been Something strange is happening with Mac Minis. They’re selling out everywhere, and it’s not because people suddenly need more coffee table computers. If you browse Reddit or HN, you’ll see the same pattern: people are buying Mac Minis specifically to run AI agents with computer use. They’re setting up headless machines whose sole job is to automate their workflows. OpenClaw—the open-source framework that lets you run Claude, GPT-5, or whatever model you want to actually control your computer—has become the killer app for Mac hardware. Not Final Cut. Not Logic. An AI agent that clicks buttons. This is exactly what Apple Intelligence should have been. Apple had everything: the hardware, the ecosystem, the reputation for “it just works.” They could have shipped an agentic AI that actually automated your computer instead of summarizing your notifications. Imagine if Siri could genuinely file your taxes, respond to emails, or manage your calendar by actually using your apps, not through some brittle API layer that breaks every update. They could have charged $500 more per device and people would have paid it. The margins would have been obscene. And they would have won the AI race not by building the best model, but by being the only company that could ship an AI you’d actually trust with root access to your computer. That trust—built over decades—was their moat. So why didn’t they? Maybe they just didn’t see it. That sounds mundane, but it’s probably the most common reason companies miss opportunities. When you’re Apple, you’re thinking about chip design, manufacturing scale, and retail strategy. An open-source project letting AI agents control computers might not ping your radar until it’s already happening. Or maybe they saw it and decided the risk wasn’t worth it. If you’re Apple, you don’t want your AI agent automatically buying things, posting on social media, or making irreversible decisions. The liability exposure would be enormous. Better to ship something safe and limited than something powerful and unpredictable. But there’s another dynamic at play. Look at who’s about to get angry about OpenClaw-style automation: LinkedIn, Facebook, anyone with a walled garden and a careful API strategy. These services depend on friction. They want you to use their app, see their ads, stay in their ecosystem. An AI that can automate away that friction is an existential threat. If Apple had built this, they’d be fighting Instagram over ToS violations by Tuesday. They’d be testifying in front of Congress about AI agents committing fraud. Every tech platform would be updating their terms to explicitly ban Apple Intelligence. By letting some third party do it, Apple gets plausible deniability. They’re just selling hardware. Not their fault what people run on it. It’s the same strategy that made them billions in the App Store while maintaining they’re “not responsible for what developers do.” But I think this is short-term thinking. Here’s what people miss about moats: they compound. The reason Microsoft dominated PCs wasn’t just that they had the best OS. It’s that everyone built for Windows, which made Windows more valuable, which made more people build for Windows. Network effects. If Apple owned the agent layer, they could have created the most defensible moat in tech. Because an AI agent gets better the more it knows about you. And Apple already has all your data, all your apps, all your devices. They could have built an agent that works across your iPhone, Mac, iPad, and Watch seamlessly—something no one else can do. More importantly, they could have owned the API. Want your service to work with Apple Agent? You play by Apple’s rules. Suddenly Apple isn’t fighting with platforms—they’re the platform that platforms need to integrate with. It’s the App Store playbook all over again, but for the AI era. The Mac Mini rush is a preview of this future. People want agents. They want automation. They want to pay for it. They’re literally buying extra computers just to run someone else’s AI on Apple’s hardware. Apple is getting the hardware revenue but missing the platform revenue. That might look smart this quarter. But platform revenue is what built Apple into a $3 trillion company. And platforms are what create trillion-dollar moats. I suspect ten years from now, people will look back at 2024-2025 as the moment Apple had a clear shot at owning the agent layer and chose not to take it. Not because they couldn’t build it—they obviously could—but because they were optimizing for this year’s legal risk instead of next decade’s platform power. The people buying Mac Minis to run AI agents aren’t just early adopters. They’re showing Apple exactly what product they should have built. Whether Apple is paying attention is another question entirely.