Notes

The MacBook Neo has caused some interesting conversations about ARM and Windows, and that Windows has failed to adopt ARM.

This point is never covered though: The MacBook Neo “iPhone chip” processor is the slowest/cheapest Apple Silicon chip ever made for a laptop but it is faster* than the fastest/most expensive non-Apple ARM chip ever made (Snapdragon X Elite).

The biggest problem with Windows-on-ARM laptops is not the software these days. It is, and has always been, because the other ARM CPUs are terrible.

I owned an OG Surface RT ARM device that Steven Sinofsky mentions in his post. It was the slowest computer at its price point for sure, and definitely slower than the current x86 laptop I had at the time. It was something you’d put up with for the long battery life. Interesting idea, terrible execution.

I have been interested in every ARM-based Surface device since, hoping they’d solve the terrible CPU situation, but they’ve never been competitve with the performance of a good AMD/Intel CPU, much less these incredible Apple Silicon designs. It doesn’t matter if the ARM is Qualcomm, Samsung, Nvidia, MediaTek… not a single one is better than x86, much less Apple Silicon.

I can’t say this enough, Apple Silicon is amazing because of Apple’s incredible CPU designs, not because ARM is inherently so good. Outside of Apple Silicon, the next best CPUs are all x86.

* Single core performance, which is what makes a computer feel responsive.

As I adopt agent coding tools like Codex CLI and Claude Code, one of the biggest shifts I’ve noticed is the latency of iteration: the speed at which work can move through each stage from idea to shipping.

That faster loop is one of the biggest advantages of these tools, but it also exposes a mismatch with existing development processes.

Before AI agents, the process often looked like this, with each step taking at least a day:

idea → spec → backlog → sprint → code → review → fix → ship

With a more agent-first builder mindset, it starts to look more like this:

idea + spec → prototype + PR refinement → test + review → ship

The stages compress and blur together. What used to take days now happens in hours, sometimes minutes.

That creates a real mismatch with legacy processes like PRDs, Agile, and Scrum, which were built around slower cycles. In an agent-first world, process debt becomes product debt.

This point can’t be made enough. I’d generalize it to “Don’t send other people AI output of any kind that you haven’t bothered to fully review yourself”.

Don’t file pull requests with code you haven’t reviewed yourself.

If you open a PR with hundreds (or thousands) of lines of code that an agent produced for you, and you haven’t done the work to ensure that code is functional yourself, you are delegating the actual work to other people.

They could have prompted an agent themselves. What value are you even providing?

https://simonwillison.net/guides/agentic-engineering-patterns/anti-patterns/

One thing I find myself doing a lot when working with LLMs and agents is copy context from other places into text. The problem is that information gets lost if the text has any meaningful formatting to it (tables, lists, links, etc).

I vibe coded a tool I use constantly: it converts your clibpoard into Markdown that it copies back into the clibpard. Give it a try! https://pseudosavant.github.io/ps-web-tools/to-markdown/

One thing I’ve learned working with AI on Markdown: everything belongs in a git repo. Diffs make it instantly clear what the agent changed, and keeping the file open in VS Code makes review and tweaks effortless.

I keep noticing the same pattern: companies that treat AI as an autonomous agent that should “just figure it out” tend to be disappointed. Meanwhile, companies that treat AI as an extension of their existing workforce, an amplifier of human capability rather than a replacement, are seeing genuinely transformative results.

---

Don’t ask “can AI do a developer’s job?” Ask “what are the 47 things a developer does in a given week, and which of those can be amplified?”

Stop Thinking of AI as a Coworker. It’s an Exoskeleton. by Ben Gregory

A table saw doesn’t make you a better carpenter. It makes you faster - for better or worse.

LLMs and agents work the same way. They’re power tools. Skill and judgment determine whether you build more, or lose fingers faster.

I just hit 80,000 miles on my EV.

Compared to my previous gas car, fuel + maintenance was ~78% less.

I spent ~$3,800 on electricity.
The battery weighs ~1,000 lb and took ~10,000 lb of CO₂ to produce (one time).

For context, my gas car would have needed: - ~3,800 gallons of gas
- ~$17,000 in fuel + oil changes
- ~24,000 lb of gasoline burned
- ~75,000 lb of CO₂ emitted

Net: I saved ~$13,000 and ~65,000 lb of CO₂.

One of things I’ve found to be critical for agentic coding/product is managing context so that I don’t have to keep explaining something to the agent. This is a very useful process I’ve adopted to keep track of, and reload, context.

I have a WIP\ folder in my cloud drive on my computer. Whenever I work on something I ask it to use and update the agent WIP log here: C:\Users\paul\OneDrive\WIP\workitem-3141.md. When I come back on another day (spec refinement, new PR to check, etc), even on a different machine with the cloud drive, I can ask it to use that WIP log to pick up right where we left off.

It’s okay to let reality meet you where you are.