We’re closing down to our 2 year anniversary of #RBM – yay! But this week has been a bit of a “how good stuff actually gets made” binge lately. We start with how BeOS is the perfect tragedy – technically audacious (dual CPUs, responsiveness-first, proper multitasking) and still crushed by ecosystem gravity, timing, and the harsh maths of compatibility. Then focus on Paul Graham’s point on taste lands the same way: raw IQ isn’t the differentiator; it’s the practiced ability to spot what’s better, iterate hard, and not confuse trendiness with quality. Zoom out and you see the US doing the macro version of this with AI – throwing over $1T annualised at data centres, compute, and software, while importing a huge chunk of the kit and hoping productivity shows up before the bill does. Also, there’s Wall Street Raider, a wonderfully feral reminder that rewriting is a graveyard and that “wrap it, don’t rip it out” is sometimes the most grown-up engineering move you can make. And Zechner’s “pi” caps it off with the same philosophy applied to coding agents: fewer moving parts, more observability, less magic, and tools you can actually trust day to day.
In this issue
5 piecesBradford Morgan White recounts how Jean-Louis Gassée, Steve Sakoman, and Erich Ringewald left Apple and formed Be Inc , including the offhand naming moment: “Be is nice.”
He sketches Gassée’s career path through HP, Data General, and Apple, then positions Be as a reaction against industry “software silt” and slow-moving operating systems. Abort Retry Fail post uses interviews and historical notes to frame Be’s ambition: a fresh OS and hardware designed around performance and developer empowerment. Then they dive into the BeBox and BeOS as a tightly-coupled attempt to leap past Windows and classic Mac constraints. It details unusual I/O, dual PowerPC CPUs, and an OS built for preemptive multitasking, multithreading, and symmetric multiprocessing, with a database-like file system. They also argue the platform failed largely because it was incompatible with dominant PC and UNIX software ecosystems, before tracing Be’s later Apple near-miss, Palm acquisition, Microsoft settlement, and Haiku’s continued evolution.
We start with a bit of nostalgia this week! And this post is basically a love letter to a better timeline where operating systems didn’t accrete into treacle. The “Be is nice” naming bit is funny, - and I didn't knew that, but the real charm is the audacity: dual CPUs, loads of I/O, and an OS built for responsiveness when everyone else was dragging legacy around. Still, the post’s answer to “why it failed” is almost too neat. The Apple near-acquisition thread hints at how acquisition decisions can hinge on timing, internal politics, and perceived integration risk as much as technical fit. The later Palm purchase and Microsoft settlement show how IP and litigation outcomes can become the final monetisation path for ambitious platforms that miss distribution. Haiku’s continuation illustrates community resilience, but the post itself concedes that driver coverage and graphics limitations still gate broader adoption.
Paul Graham argues that “taste” is a real, learnable faculty that matters for people who make things, especially designers, engineers, and writers.
He starts from an MIT professor’s problem: many applicants look smart, but it’s hard to tell who has taste. Graham rejects “taste is subjective” as a social convenience, not a truth, and claims that as makers improve, their tastes change in ways that imply earlier tastes were worse. He then treats taste as practical pattern recognition about what makes work “beautiful,” noting common principles across disciplines. Improving craft requires admitting that quality varies, studying exemplars, and iterating deliberately, rather than hiding behind relativism or fashion.
Paul's essay is really about capability building: organisations and teams need more than raw intelligence; they need judgement about quality. He positions taste as a measurable-by-output competence that develops through deliberate practice, exposure to high-quality references, and fast feedback loops (rewrite, redesign, discard). So, design environments where people can refine taste: shared critique norms, access to exemplars, and time budgeted for iteration, not just delivery. It also warns against incentives that reward ornament, busyness, or trend-chasing over solving the right problem. However, “taste” can become a proxy for cultural similarity if leaders don’t anchor feedback in observable outcomes (clarity, usability, error rates, comprehension). Hiring and promotion should therefore combine portfolio evidence with structured reviews that separate craft reasoning from status signalling. With a pragmatic stance: treat taste as a skill, cultivate it intentionally, and guard against it becoming a vague badge of belonging.
Joseph Politano argues the US is in a historically unprecedented AI-driven investment boom, pouring money into data centres, computers, and software at record levels.
He cites data centre construction exceeding a $42B annualised pace, computer and peripheral investment above $270B annualised, and software investment above $750B annualised. Combined, he says these categories now exceed $1T annualised, roughly 3.5% of US GDP, as hyperscalers keep expanding capacity. He frames the surge as unusually American, with other major economies not seeing comparable acceleration. The buildout is tightly linked to imports of data centre computers and parts, which he says have risen to nearly $400B annualised, shaping trade patterns and muting near-term US GDP impact.
The piece describes an investment cycle with unusual concentration: the US is scaling AI infrastructure faster than peer economies, while much of the hardware value-added accrues to foreign producers. That creates a mixed macro picture: a domestic boom in construction, software, and power demand alongside a leakage channel through imports, which dampens immediate GDP contribution. Politano’s comparison to earlier American buildouts is less about romance and more about risk: the capital stock is being accumulated ahead of proven, economy-wide cashflows. The trade-war exemption detail underlines a policy inconsistency - strategic rivalry coexisting with practical dependence on imported compute. The implied fragility is competitive, not just technological: returns hinge on sustained capability gains translating into paying usage, and on providers defending margin as models commoditise. The strongest analytical takeaway is that the “AI boom” is already large enough to move price indices and electricity markets, so the adjustment costs will be real even if the payoff arrives late.
This page tells the origin story of Wall Street Raider, a long-running financial simulation that began as a Harvard Law student’s board-game idea in 1967 and became a sprawling computer game after Michael Jenkins taught himself BASIC on a Kaypro in the early 1980s.
It describes decades of solitary development, “fits of rationality” coding at 3am, and a system so complex that even Jenkins later avoided touching parts he’d written. It then pivots to the game’s near-collapse and revival: failed modernisation attempts, payments and distribution problems, and Jenkins considering shutting everything down. In January 2024, 29-year-old developer Ben Ward contacts Jenkins, spends a year studying the PowerBASIC code and manuals, and succeeds by “layering” a modern interface over the old engine rather than rewriting it. The piece frames this as a torch-passing towards a Steam release.
I do have a soft spot for these “one person, one obsession” software epics, and this one’s properly feral! The bit that lands is the modernisation lesson: everyone tried to rewrite it and failed; the winner wrapped it and moved on. That’s enterprise migration logic applied to a niche game, and it’s oddly reassuring. Still, the story reads like marketing with receipts: lots of vivid detail, but the big claims (“most comprehensive”, “changed hundreds of careers”) lean heavily on anecdotes. Even so, passing a 40-year codebase across a 50-year age gap is genuinely moving.
Mario Zechner describes why he built “pi” , a minimal, opinionated coding-agent harness, after finding mainstream tools increasingly complex, unstable, and opaque.
He argues that context engineering and observability matter more than feature sprawl, and that many harnesses inject hidden prompt/tooling changes that disrupt workflows. To regain control, he built four components: a multi-provider LLM API (pi-ai), an agent loop (pi-agent-core), a terminal UI framework (pi-tui), and a CLI wrapper (pi-coding-agent).
What a nice critique of agent harness bloat, vendor abstraction pain, and UX “magic” that breaks developer trust. Zechner’s pi-ai treats the ecosystem as fragmented plumbing: different providers speak similar APIs but disagree on fields, streaming, token accounting, and tool-calling quirks, so a unified layer needs constant testing and still leaks. His answer is to minimise surface area: a small system prompt, four core tools (read/write/edit/bash), and explicit project context via AGENTS.md, rather than large evolving prompts and sprawling tool registries. The MCP argument is particularly operational and security is handled with blunt honesty. The broader lesson is that “agent productivity” often comes from predictable interfaces, inspectable state, and constrained abstractions, not ever-more features.
Last Week in AI
- Lambda 2025 AI wrapped | lambda.ai
- Sabotage Risk Report: Claude Opus 4.6 | www-cdn.anthropic.com
- Gemini Deep Think: Redefining the Future of Scientific Research | deepmind.google
- GitHub Actions Is Slowly Killing Your Engineering Team | iankduncan.com
- As AI enters the operating room, reports arise of botched surgeries and misidentified body parts | reuters.com
- Introducing GPT-5.3-Codex-Spark | openai.com