git » homepage.git » commit 16673cc

diff --git a/md/NextGenerationMobilePersonalComputing.md b/md/NextGenerationMobilePersonalComputing.md
new file mode 100644
index 0000000..4bfe06a
--- /dev/null
+++ b/md/NextGenerationMobilePersonalComputing.md
@@ -0,0 +1,35 @@
+# 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.
+