Martin Emde

The Apple Upgrade program is more complicated than it looks. I’ve seen many attempts to explain it away and I don’t think they captured the nuances.

The best way for me to understand what’s going on is to build a tool to help myself. This gives me a clear understanding of the dynamics at play in a system. As we approach the iPhone Duo purchasing frenzy, I hope it helps you decide what works for you.

Apple Upgrade Broken Down - My interactive exploration of the new Apple lease program.

After many iterations, I’m happy enough to release it into the wild. I’ll warn you though, the Apple Upgrade program is not easy to understand, and so while I did my best to make sense of it, it’s still a lot of data that will take a moment to absorb. If you want the short answer, the difference between plans is small and the levers for saving money are the obvious ones.

Simplest answer: pick the longest plan you’re willing to live with: the 24 month lease is the best if you want optionality, the 36 month carrier deal is the best if you want the absolute cheapest no matter the downsides.

We all know all the obvious stuff already, and we usually pick the worse deal anyway:

1. Cheaper phones usually beat any other optimization.
2. The longer you keep your phone, the more money you save.
3. Better trade-in values are the next best saver.
4. After the above, the best plan is the one that lets you hold on to more of your money longer.
5. Private party sale is the highest trade in per phone, but you might get burned like I have.
6. Carrier financing in the slowest cycle, but the best deal for trading in old phones that aren’t worth much.

In short, using crappier products for longer obviously saves money but at the cost of some tax on your day every day. For this reason, this tool is not about picking the cheapest phone or the cheapest upgrade cycle. This tool is here to help you understand which button to press on the iPhone Duo order page so you can stop thinking wondering if you took a bad deal.

If you’re interested in this stuff, like me, then here’s the tidbits this tool helped me figure out:

1. Both Apple Upgrade leases are maybe the best deal for people with liquid wealth that want to upgrade frequently.
2. If you can’t afford a sudden $400 charge, then you may get caught in a lease cycle trap that will be difficult to exit. That last charge to own the phone seems intentionally designed to make you want to avoid it by handing over the phone for a new lease.
3. The lease will never cost more than the cash price of the phone (but that’s not what makes it risky). The risk is overextending yourself because the payment is artificially low at first, especially when you have equity in you phone that discounts the initial payments to nearly zero. You’re using up your equity to lower the price temporarily.
4. AppleCare is really expensive. If you break your screen less than once per year, especially if you and your partner or family can distribute the cost of an occasional broken screen, then you’re much better off without AppleCare. Even a full price fix every other year is a better deal, but 2 fixes, not a good deal. This may change with the iPhone Duo, which seems hard to protect and unpleasant to put a case on.
5. If you upgrade every year, as many people do, surprisingly the best deal seems to be the 2 year lease, paid in full every year. If you pay the 2 year lease in full after 1 year, and then trade in right away you might get a reliably better deal than the lease hand-off. This is marginally better in the long run.
6. Apple’s lease trade-in, where you give your device back for free, is a luxury you pay a lot of money for. Right now a 1 year old iPhone 17 Pro Max will fetch 74% of its purchase price on trade-in. If this were an Apple Upgrade lease, I’d hand it back for 50% of the original purchase price, a $335 loss.

There’s no getting away from this: This tool is complicated. Despite my efforts, there’s some irreducible complexity here. I chose to model each month to give you a sense of your payment per month on each plan, and the months where a big charge hits, but it clutters the overall picture. Send me an issue on GitHub if you want to nerd-snipe me into fixing it some other way.

Apple Upgrade Broken Down is built to compare financing options across the same approach, but doesn’t make it super easy to compare different devices or different refresh periods. I figure it’s pretty obvious when something costs more, and buying a more expensive phone more often costs more. Anyone with the liquid wealth to pay for a full price phone repair should consider dropping AppleCare unless they know they use it. Unless you raw dog your phone every day (in which case your willingness to break your phone is a signifier of your wealth) then a good case is a better investment than AppleCare.

I used to be really good at editing code.

I was 12 when I learned VIm. I asked my dad “how do I jump to a line number in a file?”

If you open it in vi [instead of pico] I can show you. It’s just :123.

Amazing! So I learned VIm and I used it for 30 years. It’s the only editor I ever got good at.

It’s almost useless now.

Thirty years of editing code. I typed every character by hand until Co-Pilot. Instead of a single word, the ghost sometimes typed the rest of the line. I switched (with the VIm plugin, of course). Amazing!

Progressively less and less of my code was typed character by character. What used to be a macro or a clever motion became Tab Tab Tab. Coding became comments for the ghost to fill in the rest. Inevitably it was a little wrong, but I was good at editing code. AlmostRight turned to Quality with a few VIm motions. I was a lot faster this way.

Then the chat on the side got better. The end was near. It was more efficient to ask for the fix than find and edit the code. My wrists, always a little sore, savored the fewer key presses.

I typed prose into the chat.

I stopped writing code.

I stopped editing code.

I stopped using VIm.

Mastery intact and barely a reason to use it.

I still use it sometimes. I go through the VIm motions of editing code. Obsidian, bless its code, and the lovingly thorough emulation in Claude Code, are now my outlet for VIm. The skills and mastery of 30 years of hjkl and :%s/vim/claude/ have become a simple trick now that comforts my muscle memory. The motions are a permanent part of my brain, but they don’t make me better at my job. Hours of modal efficiency are no more than a few minor minutes of savings now.

That era of hand editing has ended. I wouldn’t trade my new powers for the sore wrists of the past. I was good at text editing. I still am. It feels good to have mastery. It just doesn’t matter anymore.

My mastery of VIm has become vestigial.

:wq

Today, I noticed I could no longer find the Slash commands documentation that I was using. The link is still named Slash commands, but it renders the Skills docs.

I had been looking closely at Claude Code’s Skills and Commands lately as I build skillet, and all today I kept trying to remind myself what was different between them. Sure enough, if you read the big blue box at the top of the docs, it says:

[!NOTE] For built-in commands like /help and /compact, see interactive mode.

Custom slash commands have been merged into skills. A file at .claude/commands/review.md and a skill at .claude/skills/review/SKILL.md both create /review and work the same way. Your existing .claude/commands/ files keep working. Skills add optional features: a directory for supporting files, frontmatter to control whether you or Claude invokes them, and the ability for Claude to load them automatically when relevant.

They merged some of the command-only features into skills. You can now use hooks in skills which were previously command only, and they added support for injecting command output into the prompt. Check out this example from the docs (note the ! preceding the inline commands).

---
name: pr-summary
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh:*)
---

## Pull request context

- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

## Your task

Summarize this pull request...!`gh pr diff`

The inline commands will be processed and interpolated before evaluating the skill.

One thing that is still missing is support for numbered arguments, like $1 and $2. These were complicated, and may have been under-utilized. I chose to skip it myself when I went to implement command support.

I’m excited to see this merger. It seemed inevitable and their timing, at least for me, is impeccable. Skillet will keep command support for now, as commands still exist, but I suggest migrating all your commands now to take advantage of the newly combined set of features.

At Gusto we have some big repositories. Many tools struggle with large codebases and Claude Code is no exception.

File suggestion, when you type @rea and it suggests @README.md, is one area where the number of files in a project has an outsize impact on a UI interaction. Filtering 110,000 files every time you type a character can make claude choppy and slow.

Anthropic has offered a worksround for this problem by providing the fileSuggestion setting to allow customization for big repositories.

The built-in file suggestion uses fast filesystem traversal, but large monorepos may benefit from project-specific indexing such as a pre-built file index or custom tooling.

I hacked my own solution for our giant repo with claude: file-suggestion.sh is a custom file-suggestion command which builds a cache from git ls-files, if available. It falls back to fd or find outside of a git repository. These results are filtered with ripgrep and fzf, allowing fast fuzzy searching.

As a surprise bonus, using a custom script seems to fix the choppiness and UI lag that plagues big repos. My guess is that the need to spawn a custom script forces the app to run the filtering async. In a repo like Gusto’s core product, this can lag input considerably to where your keypresses stop rendering. Deleting characters is even worse, slowing to a crawl as the search space expands.

Hey, claude code devs, if you’re reading:

Move the file suggestion filtering off the main
UI thread so suggestions are returned async,
following an approach similar to spawning a
process for a custom fileSuggestion command.

If you want to try my script, make sure you have ripgrep, fzf and optionally fd installed.

Grab the script below (or point your own claude at it and ask for a version that works for you). You can also view the latest version if I didn’t already break the link by the time you get here.

curl -o ~/.claude/file-suggestion.sh https://raw.githubusercontent.com/martinemde/dotfiles/36f670bda583065f634f1e83c4a195b9ac39c17b/home/dot_claude/executable_file-suggestion.sh
chmod +x ~/.claude/file-suggestion.sh

Then add the following to ~/.claude/settings.json (ensure the path matches and the file is executable).

  "fileSuggestion": {
    "type": "command",
    "command": "~/.claude/file-suggestion.sh"
  }

Restart Claude Code, then test out the search by typing an @ and the start of a file. Fuzzy matching should let you match any fuzzy path after the first slash.

On our biggest repo, this drops the search time to about 62ms compared to around 1000ms without the index (one full second per bounce). The script watches for the .git/index or .git/HEAD to be newer than the cache file and automatically refreshes the cache.

The cache is stored in the project’s .claude/ directory, so you’ll want to ignore the .claude/file-suggestions.cache in your global gitignore file.

In order to attain speed and retain fuzzy matching, it pre-filters based on the first directory segment using ripgrep to cut down on results. This allows you to type pac/payroll to find packs/products/payroll/... but if you type pks/payroll or papay it may not return any results. This is a trade-off for speed that I’d don’t love since I was expecting neovim level fuzzy find.

I may experiment with dropping the pre-filter and accepting the slower results just to get more reliable fuzziness. Please let me know if you find a better way around it.

What if you could have that sick Ghostty CRT effect but only on unfocused windows, or a rad flaming cursor highlight but only once when you focused the window?

Introducing the iFocus and iTimeFocus uniforms

My recent contribution to Ghostty enables new focus-based shaders. You can use these new input variables, iFocus and iTimeFocus, known as “uniforms” in Shadertoy GLSL, to allow shaders to react to focus and blur events.

Note: Until the next Ghostty release, you’ll need to install a recent Ghostty prerelease version to try this out.

Example: CRT Shader on Blur

Here’s the shader I use in Ghostty for unfocused surfaces.

Try clicking into and then outside of the “terminal” (yes it’s upside down). You should see a CRT-style effect that clears when you focus the terminal.

Here I’m emulating Ghostty’s iFocus uniform to apply a CRT shader only when the canvas is unfocused. It may not render in every browser. Try it directly on my site with a modern browser or zoom in really close on your phone.

Example: Focus Animations

Here we emulate the iTimeFocus and iFocus uniforms to create a cursor highlight effect.

Click into the “terminal” and a cursor focus zoom effect triggers. Click around more, the effect only plays once. Defocus the “terminal” then focus it again and you’ll replay the focus animation.

If you’d like to play with these shaders more, check out my Ghosty Shaders demo page.

Toggle between the shaders using the menu button in the top-left of the demo canvas, or look at the debug overlay (bottom right) for uniform details.

How it works: Focus/Blur Effects

The iFocus uniform is an int set to either 0 (blurred) or 1 (focused). This uniform is useful for controlling whether a shader renders on focused or blurred surfaces (panes or windows).

To save resources, Ghostty shaders do not run on every frame for unfocused surface. This is generally a good thing and saves resources, except sometimes unfocused surfaces receive frames anyway. This can cause stutters and skips in a paused animation or cursor effect on blurred surfaces.

With iFocus we can intentionally apply blurred styles to unfocused surfaces or run shaders only on focused frames. This fixes the stutters and skips by allowing the shader to ignoring these deceptive frames.

Example Usage

The following if statement can be added to any shader to make it render only when blurred. You can check if (iFocus == 1) to run something only when focused instead.

void mainImage(out vec4 fragColor, in vec2 fragCoord) {
    vec2 uv = fragCoord.xy / iResolution.xy;

    // Early exit when focused
    if (iFocus == 0) {
        // Render normal texture when
        fragColor = texture(iChannel0, uv);
        return;
    }

    // The rest of the shader goes here...
}

This example disables all shader effects when the surface is focused, allowing unfocused states such as CRT scanlines, vignettes, shadows, or faded colors that render only on the blurred surfaces.

On the other hand, if you invert the logic you can run something only when the surface is focused, which I have used to make my cursor effects only appear on focused surfaces.

Focus Resume Animations

The iTimeFocus uniform is a float, set to the iTime when the surface last received focus. We can use this to render effects that need to animate when the surface is focused.

Here’s an example of how to use iTimeFocus to create a resume animation.

const float PULSE_DURATION = 0.15;  // Animation duration in seconds

void mainImage(out vec4 fragColor, in vec2 fragCoord) {
    vec2 uv = fragCoord / iResolution.xy;

    // Quick exit: only run during active focus animation
    float timeSinceFocus = iTime - iTimeFocus;
    if (iFocus == 0 || timeSinceFocus < 0.0 || timeSinceFocus > PULSE_DURATION) {
        fragColor = texture(iChannel0, uv);
        return;
    }

    // Render focus resume animation...
}

In this example, the shader checks how much time has passed since the surface received focus. If the surface is blurred, or if the focus animation duration has passed, the shader exits early to save resources.

You can see and install my focus-cursor shader for a complete example.

Rendering shaders on blurred surfaces

Ghostty shaders mostly don’t receive frames when blurred. This is for performance reasons and can be disabled with the custom-shader-animation=always config option.

However, it’s inconsistent. Sometimes defocused surfaces get frames when a mod key is press (like command or alt) or when the mouse moves over a link. With iFocus you can intentionally filter these frames out to avoid ugly stutters.

So far it seems blurred surfaces reliably receive at least one defocused frame to render the defocused state. While you can’t ensure that an animation could complete on blur (without custom-shader-animation=always), you can at least ensure that the defocused state is rendered once.

Therefore, I would suggest that all shaders should include this gating if statement unless they are intended to run always. It improves performance and polish on both focused state cursor animations and blurred state rendering.

Installing Ghostty prerelease

Again, if you want to use these shaders, you’ll need to install the prerelease version of Ghostty. It might be glitchy (I immediately submitted another bug fix after this feature because the dev build had a problem)

I notice that the blue bar at the top of the Ghostty terminal can do more than just bounce back and forth (like it does in Claude Code). I was tinkering with Ghostty (to add additional shader uniforms for focus change events) and when Zig builds, it updates the Ghostty progress bar as it builds, turning red if it fails.

I found this “one-liner” (it’s a long line) by @jcollie that outputs the OSC9;4 progress bar sequences:

 counter=1; while [ $counter -le 25 ]; do printf "\x1b]9;4;2;${counter}\x07"; ((counter++)); sleep 0.1; done; while [ $counter -le 50 ]; do printf "\x1b]9;4;1;${counter}\x07"; ((counter++)); sleep 0.1; done; while [ $counter -le 75 ]; do printf "\x1b]9;4;3\x07"; ((counter++)); sleep 0.1; done; while [ $counter -le 100 ]; do printf "\x1b]9;4;1;${counter}\x07"; ((counter++)); sleep 0.1; done; printf "\x1b]9;4;0\x07"

And here’s the breakdown of the escape sequence (quoting from the Windows Terminal docs of all places):

ESC ] 9 ; 4 ; <state> ; <progress> BEL

• ESC is the escape character, ASCII 27.
• BEL is the bell character, ASCII 7.
• <state> is one of 0, 1, 2, 3, or 4.
  • 0 i s the default state, and indicates that the progress bar should be hidden. Use this state when the command is complete, to clear out any progress state.
  • 1: set progress value to <progress>, in the “default” state.
  • 2: set progress value to <progress>, in the “Error” state
  • 3: set the taskbar to the “Indeterminate” state. This is useful for commands that don’t have a progress value, but are still running. This state ignores the <progress> value.
  • 4: set progress value to <progress>, in the “Warning” state
• <progress> is a number between 0 and 100, inclusive.

You can also refer to the ghostty documentation for ConEmu OSC 9;n Escape Sequences

How great would it be to add that to other tools that compile or churn for a while? It’s no replacement for other feedback since not all terminals implement this, but it seems like a good way to give extra information without an excess of printed characters that get picked up by logs.

I still remember a code review I received early in my career. I had just started a new job and my new coworker taught me something in a code review I haven’t forgotten. I think the lesson applies more than ever now that agents are writing more (most?) of our code.

Having freshly joined, I made an commit to address excess white space and improper indentation that were bugging me (painstakingly, by hand, it was the 2000s) and along the way I made a few refactors that seemed obvious to me. I committed this all with the message “White space fixes” and submitted for review.

My colleague quickly called me out. “You said these were just white space fixes, why did this code here change?” My explanation was something about not wasting the overhead of splitting it out. “If I’m scanning for white space changes, I don’t want to suddenly have to review for code correctness.” OK. I reset my commit, added back only the white space changes, and resubmitted them each separately. Both were commits accepted easily.

However, the lesson stuck with me. Even though the code was fine, I had made it much harder for him to review. White space changes are easy to scroll through. Your only job is to catch accidental code changes, which is exactly what I inserted. I had broken his expectation about how long this code review would take, what level of care he needed to use, and how big an interruption this would be to his workflow.

No one has to merge your code. They got shit to do.

The burden is on the author to submit code that can be reviewed easily. This is an often unspoken part of the senior engineer skill set, transferred by working together rather than explicitly taught. Before you learn this skill, you’ll sometimes notice than your larger commits and clever refactors take a long time to get reviewed. You may even think this is the fault of your team or your process. Maybe it is, or maybe the whole team assumes that code review always takes forever so they should do it in big batches.

The requirement to make your code reviewable does not change when agents write your code. Your responsibility for making your code reviewable is more important than ever. And what makes code reviewable? Put simply, show your work!

Before agents, your work was a stream of reasonably concise commits, comments, tests, and code, submitted as incremental updates. Now, while all of the old stuff still matters, your work includes the specs, prompts, decisions, and references that you used to supply context to your agent. Combined these artifacts prove that your change does what you claim it does.

When a reviewer tries to understand the code, they need to assess whether you effectively achieved your goal. The larger your change the harder it is to understand all the various goals you had while making it. As the author, it’s also much harder to prove, since there’s so much more code to justify.

Share your PLAN.md early and seek feedback. I’d much rather critique 2 pages of PLAN.md rather than 20 pages of code. You’ll have a easier time generating code that can be reviewed effectively when someone has already seen what you’re trying to achieve.

Reviewing the plan, and including it with your code for review, also give the reviewer a chance to see your words and approach, and to offer real feedback about the work you’re actually doing. Resist the urge to add more than one plan to a unit of reviewable code. If you want to keep building after completing a plan, wait! Go review someone else’s code first, then develop your next plan.

Prove that you did what you set out to do, show it clearly in your code, tests, and commits. Separate refactors from features and cleanup. If something you find out you need to do after can be done before, reorder the commits. Break code into smaller chunks to make them easier to review, build them in layers of abstraction and keep changes focused.

A common complaint about the usage of AI coding agents is the burden it places on code reviewers. Engineers often resist switching their mental context to review code. Finding out that you’re now expected to review someone else’s low-effort slop can almost feel like an insult.

Code review has long been a bottle neck and agents are making it worse. More code, produced faster and with less oversight increases the burden on reviewers. And yet, code reviews are an essential part of sharing knowledge in software engineering. They follow an etiquette that is meant to respect the effort of the author and encourage sharing of knowledge.

Meanwhile, the expectations placed on the code reviewer, and the bleak future where all we do is review the output of coding agents, feels impossibly unbalanced. Much of this etiquette, and the expectations placed on the reviewer, assumes that writing code is slow and hard. This poses a problem if we want engineers to be effective with AI agents. We need code review to teach, learn, and ensure quality.

How can we address the increasing demand for review without destroying code review or creating new bottlenecks?

Review Etiquette Must Change

The length of a PR is no longer a good predictor of effort. If you’re staring down an angry bowl of vibe soup, you’ll do the author a service by explaining the words they need to say to their agent to produce the quality you’re expecting.

Normally reviewers might shy away from asking for a big architectural change in code reviews. Don’t. Big architecture changes are not as difficult as they once were and vibe code can be re-vibed easily with better requirements. Reviewers should reject sloppy code as long as they make their expectations clear.

How do we balance the effort to review the code with the effort to generate the code? My advice, keep the effort proportional. If a day of work in the before times took 20 minutes to review, then an hour of work should take only a few minutes. Allowing that hour to take 20 minutes threatens the balance of work between author and reviewer. This means the burden of quality, and the obligation to prove that quality, must remain on the author.

If the author submitted a big mess, ask for a big solution. If the slop is high, simply scan to understand their goal and then respond with the architecture or solution you expected and why. Leave high level comments for code that lacks deep consideration. Ask questions that help you both understand the problem and the possible solutions. Focus on what would make their code easier to review.

This isn’t a blank check to be a jerk. Kindness and respect are still table stakes. If something doesn’t meet your quality standards, nitpicking every problem line-by-line is counterproductive. Be direct about what you expect overall, ask questions about their goals, and learn how they arrived at the solution. Your input may help improve the quality and readability of the author’s future code and maybe you’ll even learn something yourself.

If an author drops a giant review on your lap without warning, vibe coded or not, don’t be afraid push back. Careful code review is limited resource. It’s OK to expect the author to make code review easier. You’re not imposing on the author. This isn’t their blood, sweat, and tears, it’s just their tokens.

My first draft of this blog post was about 4x longer and half as good. Thanks to my teammate Denis and my “infinitely patient with me wife” Kewe for their reviews. You both helped me merge a better blog post.