Luminoid's Site

There’s a strange gap at the center of modern AI. The same systems that pass the bar exam and write working code still can’t reliably fold a towel, plug in a USB cable, or tidy a kitchen. The intelligence that lives in a chat box turned out to be the easy part; the intelligence that moves a body through the physical world is the hard part. And it’s a different field, with its own history, its own methods, and its own brutal form of honesty: in the physical world the grader is physics, and physics does not accept a fluent excuse.

Embodied intelligence is that field. It’s AI that perceives and acts in the real world, in cars, arms, drones, quadrupeds, and humanoids. It is decades older than ChatGPT, and it’s now colliding with the language-model boom in a way that’s pulling in enormous money and a lot of software engineers. This post is a tour of the whole thing for someone who writes software but has never touched a robot. It’s layered: the first part is the mental model in plain language, the middle is how these systems are actually built and why data is the wall, and the last part is what a software engineer can do to get involved without a robotics PhD or a lab budget. Stop reading whenever you have enough.

A complete map of Apple’s AI surface as of May 2026: the design philosophy underneath, the seven layers of framework, the cost model that makes Apple’s approach feel different from every other vendor’s, and what each piece is actually for when you sit down to ship code.

The third post in the series after What is an LLM and Context is the whole game: how LLM apps actually work. Those covered what the model is and what feeding it well looks like. This one is about what happens when you stop typing the next prompt yourself and hand the keyboard over: the model picks a tool, the tool runs, the result comes back, the model picks the next tool. That loop, with a few hundred lines of code around it, is what every product in 2026 is calling an “agent.” The post is written for people who use agent products (Claude Code, Cursor, GitHub Copilot agent mode, ChatGPT’s agent mode) and want to know why their tools behave the way they do. It also has the underlying details (wire formats, MCP server authoring, eval design) called out separately for anyone building one, but the technical detail is opt-in, not the default reading path.

The companion to What is an LLM, written for people who use Claude / ChatGPT / Cursor / Claude Code and want to know what’s going on behind the chat window. That post explained what the model is. This one explains what running one in production actually looks like, and it turns out almost every interesting decision is about the same thing: what tokens you put in front of the model on any given call. The model has no memory between calls. Whatever the model knows about your user, your codebase, your conversation, your tools, is in the prompt or it isn’t there at all. The post explains why Claude “remembers” your project (it doesn’t, the harness re-injects it), why ChatGPT degrades mid-conversation on long threads, why your $40 day on Claude Code happens, why “ignore previous instructions” still works on some agents in 2026. The technical detail (vector DBs, HNSW, chunking algorithms) is in sections you can skip if you’re not building one of these.

A working mental model of large language models, written for people who use Claude / ChatGPT / Gemini / Claude Code daily and want to understand what’s actually running under the hood. The post is layered: the first stretch is the whole thing in plain language, explaining behaviours you’ve already noticed (hallucination, the “let’s think step by step” trick, why Claude can’t count rs in “strawberry”); the middle goes into the architecture with every symbol defined for anyone who wants the math; the last part covers training, inference economics, and what’s actually new at the frontier in 2026. Stop reading whenever you have enough; the architecture section is opt-in.

The thing about 2012 that’s easy to forget is that for the first five years of iOS, UIKit was a junior framework. AppKit had been shipping since 1989; iOS was a phone OS that borrowed Cocoa’s runtime and naming conventions but quietly did without the harder pieces. There was no constraint-based layout on iOS until 2012. There was no NSAttributedString accepted by UILabel until 2012. There was no grid view, no proper view controller containment API, no canonical async substrate. Developers building iPhone apps reached for CGRect.frame, sprung-and-strut autoresizing masks, and Core Text bridges, while their colleagues on the Mac had stopped writing that kind of code years earlier.

The thing I keep coming back to about 2011 is that almost none of the APIs revealed that June are alive in the form they shipped. Core Data’s iCloud integration (the transaction-log mechanism that the 2011 reveal pitched) was deprecated in iOS 10 in 2016. UILocalNotification was deprecated the same year. Storyboards lost the argument in most production codebases. ARC’s __weak keyword survived as a curiosity in mixed Obj-C/Swift bridging headers, and the rest of manual memory management died with Swift. And yet, when I read the seven sessions I revisited this week, every modern iOS app I touch is still organised around the ideas those sessions argued for. The API surface got rewritten. The conceptual model didn’t.

2010 was bracketed by two products. The iPad shipped on April 3 and gave Apple a second iOS device weeks before WWDC had a chance to teach it. iOS 4 shipped on June 21 as the first release where “iPhone OS” was renamed “iOS” to acknowledge a second device on one stack. WWDC 2010 sat between the two releases. The sessions that mattered share a single move: patterns developers had been hand-rolling against touchesBegan:, pthread_create, “is the app foregrounded?” booleans, single-screen iPhone layouts, and folk-wisdom method names finally got named primitives in the SDK to replace them.

WWDC 2008 was the year third-party iPhone development became possible. The SDK opened in March, the App Store opened in July, and Apple shipped four design-principle sessions that year that still describe the shape of every iOS app I write in 2026: 312 (the SDK runtime), 348 (the Cocoa philosophy), 940 (Obj-C 2.0 properties and protocols), and 382 (the GCD preview). Three of the four bets paid off in the form they were originally pitched. One had to be rewritten twice before it stuck.

WWDC 2009 was two releases doing different jobs. iPhone OS 3.0 shipped on June 17 and turned the App Store from a curiosity into a viable place to ship a product. Snow Leopard shipped on August 28 with no new user-facing features at all, marketed literally as “0 new features,” because the work that year went into the foundation: a 64-bit rewrite of every Mac framework, the Clang toolchain replacing GCC, and blocks plus Grand Central Dispatch. The two releases ship eleven weeks apart, in different keynotes, and are usually remembered separately. Reading them together is the only honest way to look at 2009, because each release filled a gap the other left.