git » homepage.git » commit 328f6a7

diff --git a/AGENTS.md b/AGENTS.md
index 83d0b1b..e17e71d 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -27,12 +27,14 @@ When drafting or editing Markdown articles under `md/`:
 - Begin with a level-one heading that matches the filename (e.g., `# HomepageDesign`).
 - Use short, conversational paragraphs aimed at technical readers; prefer present tense and active voice.
 - Link to related wiki pages using relative Markdown links (`./PageName.md`) so the generator can rewrite them.
+- Store article-specific assets in a sibling directory named after the article stem (e.g., `md/PageName/image.png` for `md/PageName.md`) and reference them relatively (`./PageName/image.png`) so `make assets` copies them correctly.
 - For historical notes, include dates or context in plain prose rather than YAML front matter.
 - Tables should follow GitHub-style pipe syntax; the build pipeline will handle them.
 - Avoid HTML unless necessary for layout—stick to Markdown headings, lists, and links.
 - Signatures are not required; rely on the build footer for publication metadata.
 - Skip em-dash pivots like “This isn’t X—it’s Y.” Write the contrast plainly instead.
 - Prefer generic “AI coding agent” phrasing over specific product names when writing about AI unless a brand is central to the point.
+- Excise common “AI sound” patterns during editorial passes: overly balanced contrast templates (`not just X, but Y`, `less like X and more like Y`), generic outline headings (`What Comes Next`, `The Hard Part Moves`), throat-clearing hedges (`of course`, `as far as I can tell`, `in general`), abstract noun stacks, and summary-like aphorisms. Prefer concrete nouns, active verbs, shorter sentences, and headings that sound specific to the essay rather than like a generated outline.
 
 ## Communication Notes
 
diff --git a/md/NextGenerationMobilePersonalComputing.md b/md/NextGenerationMobilePersonalComputing.md
deleted file mode 100644
index 4bfe06a..0000000
--- a/md/NextGenerationMobilePersonalComputing.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# NextGenerationMobilePersonalComputing
-- Created Thursday 14 May 2026
-
-Over the past several months it's become clear to me that a revolution in mobile, personal computing has begun, spurred by recent advances in AI model capability and/or coding agents. Until around December of last year, me and most of the programmers I knew had plenty of ideas for mobile apps to make some aspect of their life easier. But few had time to invest in the mobile ecosystem - learning the frameworks, the platforms, the programming languages, to ship either iOS or Android apps in a competitively low (with respect to other obligrations or pasttimes) investment.
-
-I've always been a little frustrated personally by the fact that I carried a powerful computer on my person at almost all times, and yet I couldn't easily write software for it, nor program on the device in a meaningful way, on the go. 
-
-At least the first of those problems changed for me when GPT-5.2 was released on December 11, 2025. Shortly after I finaly gave a terminal coding agent, OpenAI's codex, a fair shake, and was wildly productive with Rails.
-
-Then in January of 2026 I had an idea for the kind of calculator iOS I wanted, and went from a UI sketch on a sticky note to a release in the App Store 9 days later of [GridCalc](https://gridcalc.app), an RPN spreadsheet with all sorts of whizbang features. I've used it every day since.
-
-I'm not the only one going nuts building stuff for mobile. Last month it was reported that [the App Store saw an 84% surge in new apps in Q1 2026](https://9to5mac.com/2026/04/06/app-store-sees-84-surge-in-new-apps-as-ai-coding-tools-take-off/?utm_source=chatgpt.com). My friend Conrad Barski has abuilt a series of utility apps for himself on Android, at least [one of which takes input from a smart ring](https://x.com/lisperati/status/2021651117202104634).
-
-Another acquaintance of mine, Chris Meiklejohn, has been publicly building a mobile app and sharing tons of great stuff around agentic coding research and his own experiences on [his blog](https://christophermeiklejohn.com) (strong recommend).
-
-Still other of my friends built fitness tracking apps to interact with their heart rate monitors in order to maximize the benefits of aerobic training - the apps collect heart rate info from a connected sensor, and run in the backrgound to provide real time heartrate metrics in a way that cooperates with other apps and audio playing on the device.
-
-I even know an active duty Army infantry officer developing an app in his spare time, productively, and he has no coding experience whatsoever.
-
-There are slight differences in ease of setup of the build tools between platforms. Currently Android is slightly easier. Conrad builds his apps in the cloud on [Expo](https://expo.dev). Others of my friends have the Android tools on their Macs, leveraging the ease of sideloading. I wanted to make a product in the app store, so I installed XCode locally and published GridCalc to the app store (I even made a [YouTube demo video](https://www.youtube.com/watch?v=M0HwzrGGuyc) in iMovie with substantial AI guidance, and an ElevenLabs voice, but that's for antoher post). But for AI-powered mobile personal computing, just building the utility you need and shipping it to your device of choice, that part isn't strictly required.
-
-I love it. The computers we physically carry and physically touch and stare at, all day, finally doing *our* bidding.
-
-There are problems, of course, but as far as I can tell they are those inherent to AI coding generally. Currently, AI agents work well with established languages, toolkits, and platforms. But like any software, mobile apps are vulnerable to self-induced bloat that can eventually bring any software project - especially an aggressively AI-coded one - to a grinding halt, as the state space/complexity exceeds both the context window of the LLM and time budget of even automated QA.
-
-UI and interaction toolkits on mobile might be especially prone to this, do to the complexity added by touch interaction, multiple device support, and screen size/capability differences across devices.
-
-Ratcheting up your linters and build hygiene requirements is a way to mitigate bloat paralysis, but to make high performance reliable apps, you still have to just plain know what you're doing, at least at a high level.
-
-For my part I'm leveling up on state machines, model checking, dependent types and theorem provers (again; currently looking at [Lean](https://lean-lang.org) and statistical analysis. Since I'm not writing the code for my mobile apps, but still staking a side business and my personal reputation on them, they have to be damn good. I used [hierarchical state machines for GridCalc](https://tailrecursion.com/~alan/GridCalc.html) and that thing has been rock solid. A lot of what Chris Meiklejohn wrote up in [Getting Up to Speed on Multi-Agent Systems, Part 6: Verification Patterns](https://christophermeiklejohn.com/ai/agents/mas-series/2026/04/29/mas-series-06-verification-patterns.html) connected with my recent experience and thinking around verification and QA.
-
-I'm also taking (another) hard look at [Backus's FL](https://worrydream.com/refs/Backus_1978_-_Can_Programming_Be_Liberated_from_the_von_Neumann_Style.pdf), his stab at a functional language over an algebra of programs (*not* types). I suspect there might be some total, closed programming paradigm like FL that offers the balance of power and restraint these AIs seem like thy need to do a good job without skipping off the rails. I should be able to see patterns, infer behaviors, state postulates. For example, with GridCalc, I didn not see a bug in any of the thousands of lines of Swift generated from my state machine. I did, however, spot bugs and omissions in a visualization of the state machine, and in boundary tests implied by the state machine.
-
-At least that stuff seems like it's potentially useful to master when it comes to the high risk, high reward activity of shipping code. For log/metric surveillance, monitoring tool development, research, code review, and bug hunting, AI is more than paying for itself in my workflows. These I'd call low risk small-medium reward, but you can have a lot going at a time, and you can create durable artifacts like Grafana dashboards, Playwright or Maestro suites, and feature extraction pipelines. These things are quick to create and incur minimal maintenance overhead, and can continue to provide value without additional token burn.
-
diff --git a/md/ProgrammablePhones.md b/md/ProgrammablePhones.md
new file mode 100644
index 0000000..44ad5fa
--- /dev/null
+++ b/md/ProgrammablePhones.md
@@ -0,0 +1,63 @@
+# ProgrammablePhones
+- Created Thursday 14 May 2026
+
+<figure style="float: left; margin: 0 1.5rem 1rem 0; width: 220px;">
+  <img src="./ProgrammablePhones/gridcalc-iphone17-bezel.png" alt="GridCalc running on an iPhone" width="100%" />
+  <figcaption style="font-size: 0.9em; font-style: italic;"><a href="https://gridcalc.app">GridCalc</a> in its current layout.</figcaption>
+</figure>
+
+## The Phone Becomes Programmable
+
+Over the past several months it's become clear to me that a revolution in mobile personal computing has begun, spurred by recent advances in AI model capability and coding agents.
+
+Until around December, most programmers I knew, myself included, had plenty of ideas for mobile apps to make life easier. But few had time to invest in the ecosystem: learning frameworks, platforms, and languages in order to ship either iOS or Android apps with an amount of effort that made sense compared to other obligations or pastimes.
+
+I've always been a little frustrated by the fact that I carried a powerful computer on my person at almost all times, and yet I couldn't easily write software for it.
+
+That's changing. The device in my pocket is starting to feel less like a sealed appliance and more like a personal computer again: something I can shape around my own habits, sensors, workflows, and annoyances.
+
+## The App I Actually Wanted
+
+Things started changing for me when GPT-5.2 was released on December 11, 2025. Shortly after I finally gave a terminal AI coding agent, OpenAI's Codex, a fair shake, and was wildly productive with Rails.
+
+Then in January of 2026 I had an idea for the kind of iOS calculator I wanted, and went from a UI sketch on a sticky note to a release in the App Store 9 days later: [GridCalc](https://gridcalc.app), an RPN spreadsheet with all sorts of whizbang features. I've used it every day since.
+
+## I Wasn't Alone
+
+I'm not the only one going nuts building stuff for mobile. Last month it was reported that [the App Store saw an 84% surge in new apps in Q1 2026](https://9to5mac.com/2026/04/06/app-store-sees-84-surge-in-new-apps-as-ai-coding-tools-take-off/?utm_source=chatgpt.com).
+
+My friend Conrad Barski built a series of utility apps for himself on Android, including [one that takes input from a smart ring](https://x.com/lisperati/status/2021651117202104634).
+
+Chris Meiklejohn has also been publicly building a mobile app and sharing a lot of good work around agentic coding research and his own experiences on [his blog](https://christophermeiklejohn.com) (strongly recommend).
+
+Some others built fitness tracking apps to work with their heart rate monitors and maximize the benefits of aerobic training. One friend said he felt the shift with Claude Opus 4.5: work that had previously seemed too annoying or time-consuming suddenly felt tractable. His apps collect heart rate data from connected sensors and run in the background to provide real-time metrics in a way that cooperates with other apps and music on the device.
+
+I even know an active duty Army infantry officer developing an app in his spare time, productively, and with no coding experience beforehand.
+
+## Getting It Onto a Phone
+
+There are slight differences in setup across platforms. Currently Android is a bit easier. Conrad builds his apps in the cloud on [Expo](https://expo.dev). Some of my friends keep Android tools on their Macs, taking advantage of sideloading. I wanted to make a product in the App Store, so I installed Xcode locally and published GridCalc there (I even made a [YouTube demo video](https://www.youtube.com/watch?v=M0HwzrGGuyc) in iMovie with substantial AI guidance and an ElevenLabs voice, but that's for another post).
+
+But publishing is not the whole story. For AI-powered mobile personal computing, the important loop is simpler: build the utility you need, get it onto the device you use, and let it become part of your day.
+
+I love it. The computers we physically carry, physically touch, and stare at all day are finally doing *our* bidding.
+
+## The Hard Part Is Still Hard
+
+There are problems, of course, but as far as I can tell they are those inherent to AI coding generally. Currently, AI agents work well with established languages, toolkits, and platforms. But like any software, mobile apps are vulnerable to self-induced bloat that can eventually bring any software project, especially an aggressively AI-coded one, to a grinding halt, as state space and complexity exceed both the context window of the LLM and the time budget of even automated QA.
+
+UI and interaction toolkits on mobile might be especially prone to this, due to added complexity from touch interaction, multiple-device support, and screen size and capability differences.
+
+Ratcheting up your linters and build hygiene requirements is a way to mitigate bloat paralysis, but to make high-performance, reliable apps, you still have to know what you're doing, at least at a high level. When AI makes code cheaper, correctness and maintainability become the bottlenecks.
+
+For lower-risk internal tools, AI already pays for itself in my workflows. Shipping mobile apps is different: higher risk, higher reward, and much less forgiving. Since I'm not writing the code for my mobile apps, but still staking a side business and my personal reputation on them, they have to be damn good.
+
+## What I'm Learning Now
+
+For my part I'm leveling up on state machines, model checking, dependent types/theorem provers (again; currently looking at [Lean](https://lean-lang.org)), and statistical analysis. I used [hierarchical state machines for GridCalc](./GridCalc.md), and that thing has been rock solid. A lot of what Chris Meiklejohn wrote up in [Getting Up to Speed on Multi-Agent Systems, Part 6: Verification Patterns](https://christophermeiklejohn.com/ai/agents/mas-series/2026/04/29/mas-series-06-verification-patterns.html) connected with my recent experience and thinking around verification and QA.
+
+I'm also taking (another) hard look at [Backus's FL](https://worrydream.com/refs/Backus_1978_-_Can_Programming_Be_Liberated_from_the_von_Neumann_Style.pdf), his stab at a functional language over an algebra of programs (*not* types). I suspect there might be some total, closed programming paradigm like FL that offers the balance of power and restraint these AIs seem like they need to do a good job without skipping off the rails. I should be able to see patterns, infer behaviors, and state postulates. For example, with GridCalc, I didn't see a bug in any of the thousands of lines of Swift generated from my state machine. I did, however, spot bugs and omissions in a visualization of the state machine, and in boundary tests implied by it.
+
+That is the tradeoff I keep coming back to. AI lowers the cost of getting something working, but it does not remove the need for taste, discipline, testing, and some theory of correctness.
+
+Still, this feels like a good trade. The next generation of mobile personal computing is not just better apps from companies. It is useful software made by the people carrying the devices, for the lives they are already living.
diff --git a/md/ProgrammablePhones/gridcalc-iphone17-bezel.png b/md/ProgrammablePhones/gridcalc-iphone17-bezel.png
new file mode 100644
index 0000000..4ec40dd
Binary files /dev/null and b/md/ProgrammablePhones/gridcalc-iphone17-bezel.png differ