Forever Goals

I like infinite games. These are things you do over and over because they are fun and you want to get better at it. You want to get better at it so that you can make the game more fun and want to play it more. The game is the point. But I often do have a secondary reason to play them: to make progress on a forever goal.

My podcast, Write While True, is one example. Its name is even a nod to infinite games because it’s an infinite loop. The goal is not to get listeners or make money. The podcast’s forever goal is to make me into a better speaker. Now that I have a co-host, it’s also to make me a better listener and conversation partner.

This blog is another example. I mostly write just to write. But it has the secondary effect of making it more likely that I could express these opinions more eloquently later. The forever goal is something like: to organize my thoughts. This blog has also led to serendipitous opportunities, and I would always want that.

I would also say that cooking is an infinite game for me. I enjoy the activity of cooking, and I do want to do it more to get better at it. But, of course, I have a forever goal of eating regularly and being healthy, which this game supports. Similarly, I go to Crossfit, which has lots of infinite games embedded in it and supports my forever goal of becoming fit.

I also have forever goals that I haven’t figured out a supporting infinite game. One that I struggle with right now is being fluent in Spanish. I started last year, and while I have gotten better, it’s a struggle. The studying I do is not a fun game.

To be clear, I am not looking for something like DuoLingo, which is gamified, but not a game. I use it, and it’s fine, but I wish I could turn off streaks, trophies, badges, leader boards, gems, and treasure chests. These features don’t make the app more fun. They are slapped on. This is also true of Fluent Forever, but not as much. Parts of that app are genuinely fun.

In the next post, I’m going to think out loud about this problem a little more.

My 2021 AI Coding Thoughts Revisited

In February 2021, I wrote Robotic Pair Programmers, which is my description of what I would want out of an AI coding assistant. I am pretty sure I was unaware of any “good” AI coding assistants, but a month later I took a look at Kite, which was an early attempt. I think there must have been something in the air. Copilot was released that June. ChatGPT would be released the next year.

It is now more than five years later, and we’re Approaching Infinity, where the doublings of computing are on a much larger base. We are past the bend in the exponential curve. But, still, there might be things that are constant (or at least aren’t immediately obsolete) in the three doublings we had since I wrote it.

The main thing I got wrong is that I thought the main way to use AI would be as a pair programmer, which was true for the first iteration. Now, it’s more as an independent co-worker that you manage. I still do a lot of pair programming with AI, but this won’t be true in the industry five years from now.

Here are sentences that I think still apply after five years.

Let’s say I index every Xcode project in GitHub, every iOS tutorial, every iOS question in Stack Overflow. Could that be distilled somehow and then shown to me at the right time?

Yup. And distilling is exactly the right word for this. This is how it works now, but that wasn’t clear to me then.

Whatever we do, we need to make sure that nearly every suggestion is useful.

I still think this is important. The ever increasing percentage of times that the agent is exactly correct has been the main thing driving usefulness in the last six months. It used to be true that you had to weigh whether it was better to correct wrong code versus writing it yourself. That ratio has tipped in AI’s favor.

Conserving flow should be the driver for how this works.

This is definitely true when you are coding with suggestions or doing smaller changes. It feels less important when doing a long agent run (or dark factory/loop engineering style systems). But, you see memes about how programmers are watching reels while agents do work, and it makes me sad. Part of the reason I make programs is to make me into someone that is better at making programs. This is true for the way I use AI, but I am not under pressure to be faster. Productivity is a goal, but not at the expense of my enjoyment.

26 for 26 Half Year Update

At the beginning of the year, I made a 26 for 26, which is a list of 26 mini-goals for 2026. Here they are with their status. I use ✅ for done, 👌 for easy, ⚠️ for hard but possible, 🛑 for probably will not get done.

  1. ⚠️ Bench my weight: getting closer but at a plateau — might need to lose 10 pounds :)
  2. ⚠️ Be able to do 10 pull-ups: I think I might get there. Losing 10 pounds would also help this
  3. 👌 Make a meal with soy curls: Not done
  4. 👌 Find a place locally where I can get Fermented Bean Curd and Nattō: Farmer’s market had Nattō. Still looking for bean curd
  5. Add A+ Content to the Amazon page for my book: Done
  6. Try Amazon ads: Done (wasn’t worth it)
  7. Go to an intermediate Spanish meetup: I use iTalki instead, but I’ll probably try this too.
  8. Cook one new thing from each vegan cookbook I have: Done
  9. Leave 10 books in the donation mini-libraries around town: Done
  10. 👌 Hang pictures of my family in my guest room: Not done, but my excuse is that I moved apartments. Should be easy though.
  11. 👌 Go to a live musical: Not done yet, but did go to a play about Earth Kitt. Should be easy.
  12. Go to a NY Liberty game: Done. Went to opening day in NY.
  13. ⚠️ Go to at least one arena-sized concert: Not done.
  14. ⚠️ Have a coffee or lunch with someone who lives in my building (see Improving My Social Connection Index): Not done, which is a little embarrassing
  15. Join a gym that has a social component: Done. Crossfit.
  16. ⚠️ Host someone new for dinner at my place: Not done yet, but maybe doing #14 will fix this.
  17. Try three new restaurants for dinner in Sarasota: Done
  18. Try two new restaurants for dinner in NYC: Done
  19. ⚠️ Go for a weekend away to a new place in Florida: Not Done
  20. Attend a local political gathering: Done.
  21. 👌 Release something new to open-source: Not done, but my raylib game could either be a candidate or spawn off something.
  22. ⚠️ Get App-o-Mat on current Django and back to being a live server (not static pages): Not done.
  23. 🛑 Publish 10 articles on third-party sites: Not done, and probably will not happen.
  24. 🛑 Appear on 5 podcasts: Not counting my own, I’ve been on two.
  25. Publish 10 episodes of my podcast: Write While True Podcast: Done, and more are coming
  26. 👌 Write 10 Amazon Book reviews for books I love: Done some, should knock this off soon

So 11/26 done, which is less than 13 at the halfway point. Not horrible.

Siri AI is a Malware Vector

I hope you are able to use the latest Apple OSs with Siri AI completely turned off. I believe that, as described, it will be a fertile ground for malware reminiscent of Windows 20 years ago.

I would love if anyone has information about the details of Siri AI that refute this.

1. Stopping prompt injections is impossible right now.

To back this up, read Anthropic’s system card for Opus 4.8. Page 77 shows the various top model’s probability of stopping prompt injections. Opus 4.8 is just under 10% with 100 attempts. Gemini (which Siri is based on) is 45% with 100 attempts.

This may be an inevitable and unsolvable problem. So …

2. We must assume that any Agent that has been exposed to text that we don’t trust is under the control of an adversary.

This is a design constraint right now. The rest of the system must be architected around this assumption.

I would never run an agent on my personal machine, because …

3. There is a lot of untrusted text on my personal devices.

Here is a partial list: All incoming emails and texts, all documents I didn’t write, all e-books, sites I browse. Siri AI can “look” at apps I am running. If you code on your machine, then all dependencies (every README, skill, etc).

This means that any file type with text is potential malware, not just executables or scripts.

But that’s not the only thing on your machine …

4. There are also a lot of “secrets” on your machine

The partial list above also includes your trusted text with your secrets. Things like: your passwords (if you let Siri AI reset them as shown in the keynote), your emails and texts, photos, financial information, personal documents, and bitcoin wallets.

So, you have a high potential to let an AI Agent that is under an adversary’s control see a secret. This is not ok, because …

5. The Agent is able to “do things”

For example: form a URL and make a network request with it, control applications, show an image from the internet (which is a special case of requesting a URL).

Siri AI will likely ask for approval, but …

6. Approval-based permission models don’t work

There is no way to make an informed decision about what is safe for an AI Agent to do. Even so, you won’t likely be asked to approve URL requests. Also, approval fatigue is real.

Apple didn’t show any permission prompts, but I assume that there will be some because they are not using …

7. The “better” (not perfect) solution is sandboxes, firewalls, OS-level auth

My opinion is the best way to run agents is in sandboxes with their own accounts (not as you or super-user) with OS-level authorization and firewalls in place. And then … just let the agent go.

The agent will be exposed to prompt injections, but there are no secrets in the VM and I limit its actions the same way I would limit a logged in user on a shared machine. This is just normal system level user access control.

I wrote about this more in Escaping the Lethal Trifecta of AI Agents and Limiting the Chance of Code Agent Prompt Injections

Write While True Episode 57: Writing Tools for Publishing

Brian: And today, once again, we’re talking about tools, but this time focus on tools for publishing and collaboration in writing, which is all a bit more complicated than what text editor do you use? 

So, to start at the simpler end of the spectrum, though, there’s blogging and then there’s publishing things like books and pamphlets and whatnot. So let’s talk first about blogging tools, publishing to the internet.

Transcript

Write While True Episode 56: Writing Tools for Drafting

Brian: I’m Brian Hall. And today, I can’t wait, we’re talking about writing tools, talking about your writing stack.

And we’ll actually spread this out over two episodes.

Today we’re talking about the idea phase, outlining, collecting notes, and drafting. So just the writing part. We’ll save publishing, editing, collaboration tools for a future episode.

Transcript

Write While True Episode 55: Reader Archetypes

Lou: Today, I would actually like us to look back two episodes where we talked about reader profile, so writing towards a specific reader, and to maybe double-click on that a little and talk a little bit more about the archetype readers that you might be writing towards.

So a lot of the way I’ve come to think about this came from Amy Hoy. If you don’t know her, Amy Hoy, she’s one of the proprietors of the 30×500 e-course and methodology of product making.

Her idea is that if you have a $30 per month product, and you find 500 customers, that that would be enough to build a small business. And the way that she wants you to get towards that product is by creating educational content for the audience that you intend to serve with the product. And then you’re going to, along the way, find your product after having done this educational content.

Transcript

Write While True Episode 54: Negative Feedback

Brian: Today we’re talking about negative feedback.

Lou: Oh boy.

Brian: Yeah, yeah. No, this one’s gonna hurt. When you write something and you share it, and then somebody tells you that it’s absolute trash in some manner or another, and there’s really no avoiding it.

Transcript

Write While True Episode 53: Pick a Reader

Brian: And I’m Brian Hall. And today we’re talking about reader profile, the person or people for whom you are writing, which is a really powerful concept to spend some time on, preferably before you start writing, at least if it’s a big project.

I think this came up in the last conversation and your example was, I do B2B SaaS. If you’re in gaming, things might be a little different, something like that. I just want to talk more about that because of how useful it is to make those distinctions. 

And I guess the basic point I want to make about reader profile, and we’ll get into what it is and how you do it, but it should make your writing easier to produce.

Transcript

Limiting the Chance of Code Agent Prompt Injections

Yesterday, I wrote about the Lethal Trifecta when using coding agents and how I am escaping it via sandboxing. I built a place to code where there is nothing valuable to lose. The agents might be poisoned by prompt injection and able to phone home, but there’s nothing to send. I can wipe the entire VM at any time and rebuild it from a snapshot or from scratch easily.

This deals with one leg of the trifecta, which is sufficient, but I don’t ignore the other two.

To limit the chance of an agent being exposed to a prompt injections, I build on an architecture of very limited dependencies. My current project is to build visualizations in JS on D3. I only include D3 on pages in the browser (it’s not on my machine). I don’t use npm, and I have no other dependencies.

The thing I miss most is jest, but I decided to build a minimal testing framework (just need to run functions and make assertions). I run the tests in a browser, so I get access to a DOM too, which I could test against. All of the code for this project only makes sense inside of a web page in the browser, which is another sandbox. It’s like Inception up in here.

My other projects are python based and live in their own VM. I need some dependencies there (pandas, numpy, matplotlib and more). The main thing I am doing is keeping that separate from the visualization project so that any issue in one doesn’t affect the other.

Nothing else that I need for the project (that I didn’t create) lives in that VM.

My main exposure to untrusted text is that I let the agent browse the web. I don’t see how I could avoid this, which is why this leg of the trifecta could never be the one I eliminate.