Stream

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.

Vibe coding is allowing a new category of junior programmers to emerge from unlikely places. Engineering is going to change. Here’s the TODO items that I think will help address the shift that I see happening.

As I addressed in my previous article, in the era of Opus vibe coding, junior engineers aren’t useless. We need them to fill in the gap between domain experts and senior engineers so that we can realize the efficiency gains that we want to see from coding agents.

I’ve extracted the TODO list here since the previous article got very long. As per the article, I’m using “domain expert” here to indicate someone that has years of experience in your company but little to no experience writing code. Many of these experts are excited about fixing their own problems, and this motivation is special and valuable. Let’s empower them.

Technical TODOs

1. Template projects that encode best practices and security controls from the start, these are your blessed paths that every new Cursor project should start with.
2. Push-button deployment paths that work safely for non-engineers. Make it one click or it’s too complicated. Look at Fastly, Cloudflare, or Heroku to see how they approach push-button deployment. They’re surprisingly easy to get started despite targeting engineers.
3. Agent rules and context that guide AI coding agents toward your company’s blessed paths before anyone writes a line of code.
4. Guardrails that catch sensitive data access and security issues automatically.
5. Code review agents that help onboard people into safe practices and explain what they’re catching and why.
6. Tiered GitHub organization structures that give power to the right people without locking people out. Access to GitHub is no longer an indicator of good engineering judgement. Not everyone needs the same access to GitHub, but everyone needs a safe place to share code.

Organizational TODOs

1. Create a reach-out team to find the vibe-newbs in your organization who are already using AI tools to code. They’re already there, in operations, in customer support, in finance. Find them before they create shadow IT problems.
2. Hire supportive junior engineers who are familiar with AI-assisted coding. Hire them explicitly with the mandate to teach. Value tutoring or mentoring experience.
3. Pair these early-career engineers with domain experts who are vibe coding. Their primary job is to support the domain experts to contribute and bridge the gap with platform engineers.
4. Senior engineering talent should guide and support these entry-level engineers. As you build the platform, grow your early career engineers to contribute to the platform.
5. Invest heavily in your platform. Are you ready for non-engineers to deploy new applications?
6. Investments in better bootstrapping, templates, context, and blessed paths support ALL engineers, not just the most junior. The investments we made in generators have already paid off, but be prepared to support them.
7. A repeat of the above, but go look at how Fastly, Cloudflare, and Heroku provide templates for new projects with push-button deploys. You need to create your company’s preferred templates and push-button deploys that reinforce your company’s best practices. AI agents will build to the structures you give them.

The domain experts turning to vibe coding are showing that they’re up for a challenge and they’re willing to solve problems that no one has solved for them yet. This of the inside of your company as a microcosm of the outside world. The bigger your company is, the more you need to create on-ramps for people to grow into stronger contributors.

If senior engineers ship 2.5x more AI code than juniors and AI Savy music producers outperform their peers, then how might your most experienced marketers, corporate financiers, or business developer perform if they’re supported with the tools and team mates they need?

Vibe coding is allowing a new category of junior programmers to emerge from unlikely places.

When a vibe coder joins an engineering channel and asks a simple question: “How do I get a domain name so I can share this with my team?” it’s all too easy to assume a level of engineering know-how that isn’t yet developed.

When this happened at my work, I joined a Zoom meeting to try to help. What I saw both inspired me and shifted my view about the role of engineering in larger organizations.

Most people think that the massive shift that’s coming will put junior engineers out of a job. I disagree.

We’re facing a massive shift in how engineering teams need to work, and if you think we’ll just fire all the juniors and then sit around guiding swarms of coding agents, you’re going to be surprised.

The Gap Between Vibes and Infrastructure

The traditional engineering answer to “how do I share this?” goes something like: “Work with platform ops to get a deployment set up. Make a PR to the terraform to allocate a new internal subdomain. If you’re deploying a docker container, can you configure an ECR repo too? The app generator should help you do this if it follows our standard framework guidelines.”

To a Customer Service manager or Accountant who just vibed out a solution to their problem, this is complete gibberish.

If they’re persistent, they’ll ask again. They’ll probably feel discouraged. Maybe they’ll figure it out themselves in ways that would make security teams blush.

This creates problems no company wants:

• Domain experts, people with deep experience in your company, get discouraged from contributing to AI driven solutions
• Shadow IT starts cropping up everywhere, allowing customer data, financial information, or company IP to leak outside of IT controls
• Senior engineers spending days supporting small contributions from inexperienced vibe coders, erasing the productivity promise of AI
• Security vulnerabilities created by well-meaning people who don’t know any better

The technical solutions that might work for an engineer could be dangerous for inexperienced vibe-coders. The gap is huge between a working prototype in cursor and a safe deployment.

Vibe Coding

As an experienced engineer, I see huge productivity gains from using AI coding tools, but they’re not without their problems.

Engineers can see when our coding agents are going sideways. When Claude starts dropping a new ALLCAPS.md for every prompt, when it create the 3rd copy of a script it already wrote, we know it’s time to reign it in and adjust rules or clarify requirements. When Claude does something stupid, we reset back to the last commit.

New vibe coders don’t know any of this. They don’t use git. They don’t reset context. They use one conversation in cursor for the entire program they’re writing.

Junior vibe coders end up with a directory containing a mix of sensitive data, cross-linked python files, 20 random scripts for one off changes, and 50 variations of SIMPLE_QUICK_STARTUP_README_FIXED.md. Worse still, they do not know which files might contain PII or financial data. Working with sensitive data is their job. The concept of sanitized test data is foreign to them.

Vibe Coding is its own skill set. It’s an offshoot of engineering that benefits from the skills we’ve built as engineers. Knowing what a good application looks like help you build a good application.

After helping my son and my wife get started with Cursor, I can see how sharing my senior thinking with them as they learn changes the sorts of outcomes they get.

If I’m working alone, it all stays internal. If I’m pairing with someone else that’s senior, then the thinking surfaces naturally in conversation but is taken for granted. If I’m pairing with someone less experienced, I might slow down enough to explain parts of my senior thinking, but definitely not all. It would bog us down too much.

• Obie Fernandez

Life-long engineers, ones that grew up with an engineer parent or were introduced to abstract systems early, have this deeply engrained in their approach to life. When things go wrong or get difficult for vibe coders, if they don’t have any of this to fall back on, they end up with very different results than experienced engineers.

It used to be that this rite of passage, understanding the system, also meant that once you got access to rm -rf you had enough background to know it was dangerous. Now we’re facing a shift in who is capable of what, and we’re going to need to decide where we want to go.

We’ve Been Here Before

Engineers faced a similar crossroads years ago. Dan McKinley captured it perfectly in his “Egoless Engineering” talk.

He describes a designer who was encouraged to contribute to an application. When the designer accidentally broke the build late at night, the team had a choice: lock it down so only “real engineers” could deploy, or make deploys safe for everyone.

McKinley chose the path of empowerment: “Randy is in the deploy group now. The how and when can be worked out off-list, but it is now possible for him to deploy to prod.”

That decision required a mindset shift. Engineers had to ensure deploys were safe for anyone to run. They had to build systems that enabled contribution instead of building gates that prevented it.

This empowerment is what unlocked what we might call modern DevOps.

Now we’re doing it again, but the “deploy group” is much larger than it was before and contains a much more junior set of people.

The Skill Spectrum

Traditionally, a “junior engineer” meant someone fresh from college or a programming bootcamp. They were people that proved they could program before getting hired. They could make commits, install dependencies, and maybe run simple deployments. They knew the lingo. They could speak like an engineer.

Now the code skill spectrum is doubling. A new “expert junior” tier has been added. They know a ton about the business domain, but they know next-to-nothing about engineering. There may be as many people in this new group as our entire existing engineering organization.

The New Engineering

Some of the best junior hires were teachers, healthcare workers, or business analysts who brought 10+ years of domain expertise along with their junior engineering skill set. They had senior thinking from a different domain, and these executive skills somewhat compensated for their lack of engineering knowledge.

Domain Expert Vibe Coders (the new “expert juniors”) bring deep domain knowledge, and now that they come from within our businesses, they have direct useful experience. They can build prototypes with AI assistance that solve very specific problems that impact only their jobs. Stuff they would struggle to ask an engineer to help them with (if they were lucky enough to have an engineer contact in the company).

We used to consider someone junior when they were a Classically Trained Entry-Level Engineer. They have 4 year CS degrees or equivalent experience. They understood coding enough to convince a series of instructors, employers and peers.

These entry-level engineers are some of the people that AI Doomers and AGI-Optimists are trying to convince us that we won’t need anymore. The doom and gloom story says that juniors are useless now because a senior has a fleet of juniors to do their work. People (rightly) worry how we will train the next generation of engineers if the engineering org is just senior talent now.

The Full-Stack Team

Engineering needs to spread out across the entire company. We need to redefine the full-stack team to span from accounting to engineering. Including a designer and a product manager on our team is no longer “full-stack” enough. We need a gradient of engineers embedded in every part of our company.

To get the most of their expertise, we can pair domain experts with entry-level engineers. You get domain expertise (accounting, legal, HR, operations) combined with the growing system thinker with the engineering vocabulary. The entry-level engineer provides a bridge from accounting speak into infrastructure speak. They help the Senior Engineers focus on capital-E engineering.

Senior Engineers become platform builders. In the before times, senior engineers would work with product managers and designers to understand the domain. Now we need seniors to focus on the hard stuff. Engineers are domain experts in engineering. They need to create the systems that make safe self-service possible. They need to support the entry-level and junior experts, help them level up, and give them the tools to contribute effectively.

This gradient of engineer skill, from viber to junior to senior, improves the efficiency of each conversation while allowing work to continue at the right level of abstraction, where each person is most skilled.

What This Means for Hiring

Now the shift begins: Domain experts are the new junior engineering talent. Entry-level engineers fresh out of college are the mid level talent. They have a natural progression to senior while filling a need in the company that keeps seniors effective and productive.

It would be a huge mistake to stop hiring early career “junior” programmers. They’re comparatively less junior than the domain experts that just picked up cursor. A 4-year CS degree puts them squarely in the middle of the pack, now that the spectrum has doubled.

If we fail to have these juniors at hand, we’ll end up spending senior engineering time to prevent vibe coders from leaking company documents or creating headaches. Worse yet, since engineering management is afraid to waste their team’s time, it’s often the managers that deal with these new vibe coders. The cost of deploying a quick script that generates a power point presentation, when supported by department lead engineering managers and a platform ops team, is astronomical. This is not what coding agents were supposed to do.

Get this right, and we unlock an enormous amount of domain expertise that was previously bottlenecked behind engineering teams. Get it wrong, and we create security nightmares, devalue or discourage talent, or destroy efficiency by applying senior engineering time ineffectively.

The technical problems are solvable. We’ve done this before with the DevOps movement. We can do it again with vibe coding domain experts. It requires acknowledging that the spectrum of “engineer” is now much broader than it used to be and building our teams accordingly.

On September 9, without warning, Ruby Central kicked out the maintainers who have cared for Bundler and RubyGems for over a decade. Ruby Central made these changes against the established project policies, while ignoring all objections from the maintainers’ team. At the time, Ruby Central claimed these changes were “temporary”. However,

• None of the “temporary” changes made by Ruby Central have been undone, more than six weeks later.
• Ruby Central still has not communicated with the removed maintainers about restoring any permissions.
• Ruby Central still has not offered “operator agreements” or “contributor agreements” to any of the removed maintainers.
• The Ruby Together merger agreement plainly states that it is the maintainers who will decide what is best for their projects, not Ruby Central.
• Last week, the Ruby core team, led by Matz, decided to assume stewardship of RubyGems and Bundler GitHub repository.
• Ruby Central did not communicate with any removed maintainers before transferring control of the rubygems/rubygems GitHub repo to the Ruby core team.
• On October 24th, Shan publicly confirmed she does not believe the maintainers need to be told why they were removed.

While we know that Ruby Central had no right to act the way they did, it is nevertheless clear to us that the Ruby community will be better off if the codebase, maintenance, and legal rights to RubyGems and Bundler are all together in the same place.

To bring this about, we are prepared to transfer our interests in RubyGems and Bundler to Matz, end the dispute over the GitHub enterprise account, 2 GitHub organizations, and 70 repositories, and hand over all rights in the Bundler logo and Bundler name, including the trademark applications in the US, EU, and Japan.

Once we have entered into a legal agreement to settle any legal claims with Ruby Central and transfer all rights to Matz, the former maintainers will step back entirely from the RubyGems and Bundler projects, leaving them fully and completely to Matz, and by extension to the entire Ruby community.

Although Ruby Central’s actions were not legitimate, our commitment to the Ruby community remains strong. We’re choosing to focus our energy on projects to improve Ruby for everyone, including rv, Ruby Butler, jim, and gem.coop.

Signed, The former maintainers: Martin, André, David, Ellen, Josef, and Samuel

don’t put all your gems in one basket

The former team from rubygems.org is excited to announce a new gem server for the Ruby community:

https://gem.coop

Right now, the current versions of RubyGems and Bundler work with this new server. All Ruby developers are welcome to switch to using this new server immediately. Just swap your primary source to https://gem.coop

The gem.coop server is simple and we aim to keep it that way. We plan to add features that serve to increase security and make packaging blazing fast. We want the default choice to be the secure choice.

Join us

You can join us on the Bundler Slack to get involved in the discussion.

Questions?

What is the .coop TLD? Is it about chickens?

Right!? I’m glad you started with a softball question. I think it should be chicken related (logo idea!). The .coop or “Co-op” stands for “Cooperative”, like REI or a local credit union. It’s part of the way we’re imagining that we can support ruby packaging in a way that’s both sustainable, open, and fair.

Is it stable?

Gem.coop is served with full, fast, edge caching and all gems are immediately available upon push to rubygems.org

Can I publish gems to gem.coop?

Not yet. There’s an interesting and tricky problem to solve in order to have two divergent public gem servers. This is our focus for the coming months. We know people are excited to have an alternative and we hope to solve this soon.

How will you handle governance?

We’re working on Gem.coop governance with the support of Mike McQuaid, Project Lead of Homebrew. We aim to release publicly later this week.

Can I donate?

If you’re feeling gracious you can always support one or all of the maintainers on GitHub. It’s very kind of you read this question and imagine asking if you could donate. Thank you!

We didn’t feel ready to ask anyone for money yet, so if you want to contribute to the project, you can support us by sharing this post and showing your excitement, testing out the server, supporting the team, and generally being a good part of the community.

Now what?

Join the mailing list and we’ll keep you updated. No corporatespeak, just developers excited about Ruby and Gem packaging.

Thanks to all my teammates that make this possible! @simi, @segiddins, @indirect, @duckinator, and @deivid-rodriguez

After updating RubyGems.org to use the new params.expect feature in Rails 8, I thought it might be helpful to go over a few of the challenges I ran into.

Why Should I Convert?

The new expect method for filtering params protects against user param tampering that can cause hard to rescue errors.

As a quick review of the feature, when we have code like this:

user_params = params.require(:user).permit(:name, :handle)

We’re vulnerable to users calling our action like this:

post "/users", params: { user: "error" }
user_params = params.require(:user).permit(:name, :handle)
# undefined method `permit' for an instance of String

By using the new params.expect we can prevent this problem (and another I’ll discuss below) all while cleaning up our params handling.

post "/users", params: { user: "error" }
user_params = params.expect(user: [:name, :handle])
# responds as if the required :user key was not sent at all, rendering a 400 error

Remember that with valid params, the values at the expected key(s) will be returned, just like with require.

post "/users", params: { user: { name: "Martin", handle: "martinemde" }
user_params = params.expect(user: [:name, :handle])
# => { name: "Martin", handle: "martinemde" }

The Easy Part

The conversion follows a consistent pattern.

# OLD
user_params = params.require(:user).permit(:name, :handle)

# NEW
user_params = params.expect(user: [:name, :handle])

For methods that permit a mix of scalars and hashes, the conversion is also straightforward:

# OLD
user_params = params.require(:user).permit(:name, :handle, :image, address: [:street, :city])

# NEW
user_params = params.expect(user: [:name, :handle, :image, { address: [:street, :city] }])

The Challenge

The challenge comes when you have conditional or complex parameter handling, especially when you’re doing something like this:

# OLD: Conditional parameters
user_params = params.require(:user).permit(:name, :handle)
user_params[:admin] = true if current_user.admin?

# OR

# OLD: Multiple permit calls
base_params = params.require(:user).permit(:name, :handle)
admin_params = params.require(:user).permit(:admin) if current_user.admin?
user_params = base_params.merge(admin_params || {})

Solution 1: Extract All Parameters First

The simplest approach is to extract all the parameters you might need and then conditionally use them:

# NEW: Extract all potential parameters
if current_user.admin?
  user_params = params.expect(user: [:name, :handle, :admin])
else
  user_params = params.expect(user: [:name, :handle])
end

Or more concisely:

# NEW: Conditional parameter list
permitted_keys = [:name, :handle]
permitted_keys << :admin if current_user.admin?
user_params = params.expect(user: permitted_keys)

Solution 2: Use Multiple expect Calls

For complex cases, you can still use multiple expect calls:

# NEW: Multiple expect calls
user_params = params.expect(user: [:name, :handle])
user_params[:admin] = params.expect(user: [:admin])[:admin] if current_user.admin?

Though this is less elegant than the single-call approach.

Solution 3: Helper Methods

For really complex parameter handling, consider extracting logic into helper methods:

private

def user_params
  if current_user.admin?
    params.expect(user: [:name, :handle, :admin])
  else
    params.expect(user: [:name, :handle])
  end
end

Testing Your Conversion

When converting to params.expect, make sure to test edge cases:

# Test with tampered params
test "handles tampered user param as string" do
  post users_path, params: { user: "tampered" }
  assert_response :bad_request
end

test "handles tampered user param as array" do
  post users_path, params: { user: ["tampered"] }
  assert_response :bad_request
end

test "handles missing user param" do
  post users_path, params: {}
  assert_response :bad_request
end

My Experience Converting RubyGems.org

Beyond security improvements, params.expect also provides clearer intent with parameter structure explicitly declared. You get better error messages with more specific feedback, and more consistent behavior with less underspecified edge cases.

When I converted RubyGems.org to use params.expect, I found that most conversions were straightforward. Complex parameter handling became more explicit and easier to understand. We caught several edge cases we hadn’t properly handled before and the code became more self-documenting.

Converting to params.expect improves security and code clarity. Start with the simple cases, and don’t be afraid to use conditional logic or helper methods for complex parameter handling.

The key is to think about your parameter structure upfront and declare it explicitly rather than building it up incrementally.

In this post I will describe the new params.expect feature that I recently added to Rails 8 and go over how it works and how to use it.

Update: For an implementation guide, see my second post on params.expect.

params: An Attack Vector

All web application programmers learn not to trust user input.

Rails has long provided a simple pattern to prevent param tampering: params.permit. This protects our app from users that may alter params in order to insert attributes or alter behavior, like assigning admin to yourself.

def update
  user_params = params.require(:user).permit(:name, :favorite_pie)

  if @user.update(user_params)
    redirect_to :user
  else
    render :edit
  end
end

This works great when users submit the form correctly and even when they try to insert extra fields, like admin=true into the params. These attacks get filtered out.

But protecting us from correctly submitted forms and extra attributes is not enough. What if, as we regularly see on RubyGems.org, a user is trying to break your application by submitting malformed params? Problems start to emerge.

The solution in Rails 8 is the new params.expect.

How do I use params.expect?

If you don’t want to dig into Rails parameter filtering right now, you can simply do the following in Rails 8:

def update
  # OLD
  # user_params = params.require(:user).permit(:name, :favorite_pie)

  # NEW (see how it mirrors the expected params?)
  user_params = params.expect(user: [:name, :favorite_pie])

  if @user.update(user_params)
    redirect_to :user
  else
    render :edit
  end
end

The expect method behaves very similarly to require(:user).permit(:name, :favorite_pie), but it is much more explicit about exactly what the parameters should look like and rejects any params that don’t exactly match the expected structure.

Let’s be very clear about what each type of parameter looks like and how to declare them in expect:

# A Hash:
PATCH /users/1/?user[name]=martin&user[favorite_pie]=pumpkin
# params = { "user" => { "name" => "martin", "favorit_pie" => "pumpkin" } }

# An Array:
POST /pies?pies[][flavor]=pumpkin&pies[][flavor]=pecan
# params = { "pies" => [
#            { "flavor" => "pumpkin" },
#            { "flavor" => "pecan" }
#          ] }

# A String:
POST /search?q=hello+world
# params = { "q" => "hello world" }

Each parameter type needs to be declared slightly differently in expect:

# Extract a Hash containing name and favorite_pie keys
params.expect(user: [:name, :favorite_pie])

# Extract an Array containing Hashes, each with a :flavor key
# (note: the Array syntax is more explicit than `permit`)
params.expect(pies: [{ flavor: [] }])
#     Note the explicit Array format above: ^^         ^^

# Extract a String
params.expect(:q)

The rest of this post will dig into why and how the new syntax works, how to use it, and some of the gotchas that you might experience with this change.

The Problem of Params Tampering

Let’s start by exploring the core problem this new feature solves: params tampering that causes uncaught exceptions.

Here’s what can happen with the traditional Rails approach when params are tampered with:

class UsersController < ApplicationController
  def update
    user_params = params.require(:user).permit(:name, :favorite_pie)

    if @user.update(user_params)
      redirect_to @user
    else
      render :edit
    end
  end
end

When params are tampered to be a String

# Normal form submission:
# params = { "user" => { "name" => "martin", "favorite_pie" => "pumpkin" } }

# Tampered to be a String:
# params = { "user" => "tampered_string" }

user_params = params.require(:user).permit(:name, :favorite_pie)
# => ActionController::UnfilteredParameters: unable to convert unpermitted parameters to hash

When params are tampered to be an Array

# Tampered to be an Array:
# params = { "user" => ["tampered", "array"] }

user_params = params.require(:user).permit(:name, :favorite_pie)
# => ActionController::UnfilteredParameters: unable to convert unpermitted parameters to hash

Both of these examples show how parameter tampering can cause unhandled exceptions in your Rails application, leading to 500 errors for your users instead of graceful error handling.

What’s going on exactly?

The problem happens when params.require(:user) returns something that doesn’t respond to permit. When the user parameter is a string or array instead of a hash, permit fails.

The old workaround was something ugly like this:

# ugly
user_params = params.require(:user)
raise ActionController::ParameterMissing.new(:user, {}) unless user_params.respond_to?(:permit)
user_params = user_params.permit(:name, :favorite_pie)

I discovered a better version when I was trying to solve this problem for RubyGems.org. It has a few flaws, but it works well enough.

# better
user_params = params.fetch(:user, {}).permit(:name, :favorite_pie)
raise ActionController::ParameterMissing.new(:user, {}) if user_params.empty?

params.expect replaces all of this mess with clear, declarative syntax that also provides better error messages and handles edge cases properly.

params.expect to the rescue

The new expect method validates both the presence and structure of the parameters:

# This expects :user to be a Hash with :name and :favorite_pie keys
user_params = params.expect(user: [:name, :favorite_pie])

# If user is missing:
# => ActionController::ParameterMissing

# If user is not a Hash (e.g., String or Array):
# => ActionController::ParameterMissing

By resolving this ambiguity in params parsing and improving the syntax and security of features used by every Rails engineer, we are able to reduce false alarms, better protect application data, and maybe reduce the number of engineers getting paged in the middle of the night.