Everyone eventually writes some version of this rule into their CLAUDE.md:
The main thread orchestrates. Leaf work runs on Sonnet or Haiku. Escalate to Opus only after Sonnet actually fails.
And then it doesn't hold. Not because the model is disobedient, but because a rule written in
prose is a rule the model gets to interpret, every single turn, under pressure to be helpful. The
sub-task feels complex, so it "deserves" the better model. The Agent call omits model
Everything I learned writing and rewriting a Claude Code status line: the full shape of the JSON you get on stdin, the seven bugs that quietly make a status line wrong, and a finished one you can install in a single line.
The bugs are the interesting part. Every one of these was in my own status line, shipped, for weeks. None of them are in the docs.
How it looks schematically:
✻ O5 H ┃ 📁 my-repo 🌿 main ●3 ↑1 ┃ 💰 $0.42 · 4m +1.2k/-340 ┃ 🧠 36% 357k/1.0M ⏱5h 63% ↻1h07m ┃ ☕ 52m break
session place change budget rest
| import os | |
| import subprocess | |
| import sys | |
| import tty | |
| import termios | |
| def main(args): | |
| # Input prompt | |
| sys.stdout.write('\033[1;34m╭─ Kitty AI Shell\033[0m\n') |
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.
If you have Homebrew (which you can get from https://brew.sh), just run:
brew install protobufor
PROTOC_VERSION=3.9.1
| { | |
| "gitlens.advanced.messages": { | |
| "suppressCommitHasNoPreviousCommitWarning": false, | |
| "suppressCommitNotFoundWarning": false, | |
| "suppressShowKeyBindingsNotice": true, | |
| "suppressFileNotUnderSourceControlWarning": false, | |
| "suppressGitVersionWarning": false, | |
| "suppressLineUncommittedWarning": false, | |
| "suppressNoRepositoryWarning": false, | |
| "suppressUpdateNotice": false, |
| exponentialBackoff(fnFailsSomeTimes, 10, 100, function(result) { | |
| console.log("the result is", result); | |
| }); | |
| function exponentialBackoff(fn, max, delay, callback) { | |
| const result = fn(); | |
| if (result) { | |
| callback(result); | |
| } else { | |
| if (max > 0) { |
While attempting to explain JavaScript's reduce method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.
JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it much simpler to think about both the old list and the new one, what they contain, and