The desire to read is real, but our attention is scattered. The save becomes a promise to give the piece the focused reading we don’t have in us at the moment.
Well written piece of observation of readers’ behavior, although, I do believe not everyone has the same habit, hence there are some nuances.
fan-out = (neglect tolerance) / (interaction time)
_raise it_ neglect tolerance: how long an agent stays useful while you ignore it.
_lower it_ interaction time: how long it needs you every time it pings.
Your capacity is the ratio. The industry is optimizing neither lever.
Now look at where the industry is actually spending. Almost all of it goes into making agents faster and smarter, which raises the number lining up and does nothing for the ratio. Making a bottleneck’s suppliers faster doesn’t widen the bottleneck. It just deepens the queue.
…
You can’t parallelize a human. You can only get better at the handoff. That’s the whole game now, and we’ve barely started playing it.
If you’ve created something profound or remarkable, take complete credit for it. If it misses the mark or turns out to be utter slop, also take full responsibility and improve from there. This is how every meaningful or valuable thing was ever created long before the advent of “AI can make mistakes” and will remain so long after, with or without LLMs.
In my experience, there are two broad categories of Knowledge Workers. The first are outcome-first workers. Their focus is on the business, on winning, on efficiency. Human needs and faults and emotions are an obstacle to be overcome.
The second group has an experience-first perspective. These workers love the messy middle. They value the journey. They want their organizations to perform well but as a natural consequence of collaboration, debate and shared struggle with people they actually like.
…
Workism is a microcosm of the larger spectacle: a world where appearing busy, important and uniquely knowledgeable is as valuable as actually being any of those things.
It never has a name and it never appears on a roadmap, but it always goes the same way: the truth about your own customers lives in someone else’s database. The users live in an identity provider, the subscriptions in Stripe, the bounces in whatever sends your email, and your product needs that truth locally. So you subscribe to webhooks and keep a copy.
…
Webhooks-for-replication are a local optimum, and the proof is the pile of workarounds on the valley floor: signature schemes, dedup stores, idempotent handlers, retry queues with exponential backoff on the provider side and dead-letter queues behind them, webhook logs with replay tooling because consumers keep asking for replays, and my 3 a.m. cron.
The author is suggesting a better alternative: SCROLL protocol.
If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it’s so easy?
If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?
If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?
If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they’ve poured their sweat, soul, and copious amounts of time into something so trivial?
If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?
AI is forcing a harder conversation about margins, about pricing, about what it actually takes to build something sustainable. The rules of software are being rewritten.
If you want your agents to write shell scripts or any kind of scripts in Ruby, add this one block in the main instruction file (see next section in case you want to add this for all projects or only for specific ones):
Write throwaway and utility scripts (data munging, one-off migrations,file renames, glue code) in Ruby, even in projects written in anotherlanguage. If it needs a pipe, a loop, a conditional, or more than oneline, it is a script: write it in Ruby, not Python, Node, or bash.Single self-contained commands (`grep`, `git status`) are fine as-is.Use only the Ruby standard library. If a gem would clearly savesignificant effort, stop and ask before using it.Put temporary scripts in a scratch or temp directory, not the reporoot, and delete them when done unless asked to keep them.
A few things I learned tuning this:
Say “standard library only” out loud. Otherwise a helpful and eager agent will try to add gems, will sometimes try to create a Gemfile, and now the throwaway script needs bundle install. The whole point of a throwaway script is that it has no setup.
Keep the single-command escape hatch. I do not want a full Ruby file to ls a directory. For one honest shell command, let it use the shell. The rule is about scripts, not about every command.
Really nice feature, although a bit black magic, and quite a footgun.
I still prefer to do ctrl+p, then update the command.
One of the comment on lobste.rs has a nice function that allows to debug a command, which is super useful especially when some arguments are variables, so it will expand those variables, and we can easily read what are the expanded variables values are exactly, and if they do match the expectation of the command:
dryrun() { ${DRYRUN:+echo} "$@"; }# runs "long_process" w/specified arguments; DRYRUN is undefineddryrun long process "extra complicated" arguments# shows command and arguments instead of running itDRYRUN=1dryrun long_process "extra complicated" arguments
The Antithesis Principle says that you should explain by an evocative analogy (to help people understand your decisions) but you should not reason by an evocative analogy (to arrive at your decisions).
…
So keep the Antithesis Principle in the back of your mind next time you make an observation about the world around you.
You will not only reach the obvious conclusion that everyone who’s smart reaches, but perhaps also the non-obvious one that only the wise do.
