- The revolt of the reader — This is the sequel to the “intellectual fly is open” piece I flagged a couple weeks ago, and now he has numbers, Dunlop’s survey of 668 developers where 78% stop reading the moment they detect AI and 71% then avoid the author for good. The spam analogy is the load-bearing one, spam didn’t die because it got ugly, it died because filtering plus consequences made it uneconomical, and he’s betting detectors like Pangram do the same to generated prose. Oxide now gates public writing on passing Pangram, which is a striking thing to mandate but consistent with his claim that the real cost is trust, not aesthetics. I’ll admit reading this while an agent drafts my reading notes is uncomfortable, though the skeleton-versus-ghostwriter line is the one I keep telling myself I’m staying on the right side of.
- Will agents like Git any more than we do? — Amplify Partners — The framing that clicked for me is that Git’s quirks were never a problem because a human was always there to absorb them, and agents don’t do absorbing, they just hit the wall at 2 to 3 merges a second and stall. The staging-area state machine is the obvious tax, tracking whether a file is untracked, unstaged, staged, or committed is exactly the kind of ceremony an agent shouldn’t have to model. What actually sold me on jj is first-class conflicts, letting the conflict live in the data structure instead of blocking all forward progress is the difference between a human who stops to resolve and a fleet of agents that need to keep moving. Calling Git “an informally specified spec half implemented by five or six people” is funny because it’s true, and it reframes why a cleaner model might genuinely win this time.
- Version control second coming — What this adds over the agents-and-Git argument is the market view, and Santos has earned it fighting Git for 20 years with Plastic SCM, so his read that GitHub could go the way of SourceForge isn’t just contrarian. The roll call is genuinely useful as a map, Entire doing provenance for agent code, Pierre and Origin chasing AI-scale traffic, Diversion betting centralized and cloud-first against the whole distributed premise, ERSC commercializing jj. The prediction I keep circling is that repos past 300 GB and a million files simply break the distributed model, which quietly concedes that Git’s core design choice is the thing under pressure. His own hedge is the honest note, “ask me in two months,” because nobody actually knows which of these survives, only that the freeze is over.
- What comes after git — After two pieces arguing Git has to go, ERSC’s answer is the pragmatic one, don’t replace the protocol, replace the storage engine underneath it and keep speaking Git so nobody has to migrate on day one. That bridge framing is smart because it sidesteps the usual chicken-and-egg, you get horizontal scaling and independence from the big platforms without asking teams to abandon their clients. The number that recalibrated me is that the Linux kernel is ~43 million lines while companies were already running monorepos in the billions of lines years ago, so the scale Git struggles with isn’t hypothetical, it’s just been hidden inside Google and Meta. The jj-with-swappable-backends detail ties it to the other reads, the path they’re selling is Git protocol now, native protocols and jj later, migration as a slope instead of a cliff.
- If coding is solved, what now?: Measuring the sloppiness of code | EARENDIL — The reframe here is that correctness stopped being the interesting axis, models pass the tests, so the real question is what the code does to a project over time, and that’s much harder to score. The finding that stuck is that using an LLM as a quality judge is “basically equivalent to a random number generator,” and worse, renaming the solutions flips its verdict, which tells you it’s grading on surface, not structure. The two metrics in SlopCodeBench give it teeth, verbosity roughly doubling from 0.15 on real repos to 0.33 on agent code, and erosion jumping from 0.31 to 0.68, so the sloppiness isn’t a vibe, it’s measurable and it’s about 2x. Ties directly to the sloppiness worry underneath all the version-control pieces, the “aircraft progress by weight” line is the whole trap, and their answer that human taste is still the thing you can’t automate away is where I land too, even if it’s an inconvenient conclusion given who’s writing these notes.
Reading log
A reading log that automatically updates every week.
I save articles to my read-it-later app and write quick thoughts as I read. An automated task pulls everything I've read during the week, uses AI to review the content and expand my notes into something more coherent, then publishes them here.
- You should never be angry at work — The line that got me was “you are not Linus Torvalds or Bryan Cantrill”, because the famous angry engineers can afford anger only since they already control the decisions, and that’s not the position most of us are arguing from. The mechanism he describes is the uncomfortable part, an angry colleague quietly becomes a problem to route around, so people start backchanneling and excluding you, which feeds exactly the frustration that started it. I’ve felt the caring-overflow thing he names, where anger is just competence spilling past the edge of the tube, and I want to believe his claim that he gets more done now while calm than he did when volatile. Still chewing on the redirect-your-caring-toward-shareholder-value advice, it sounds right as self-management but a little bleak as a description of what work should feel like.
- How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cache — The framing that reset my sense of scale is that at 250 billion cached entries, wasting one byte per entry costs 250 gigabytes, so this is a post about squeezing individual struct fields and it still adds up to 100 terabytes. Most of the wins come from one observation, cached DNS responses never change, which means the capacity field in a Vec is dead weight and swapping to Box slices reclaims 64 bytes an entry. My favorite move is inferring the owner name from the cache key instead of storing it, since it trades a tiny bit of read-time work for dropping the allocation on roughly 80% of records. The counterintuitive result is that shrinking memory made it faster too, insert throughput up 43% and lookup latency down 19%, because a tighter layout is just better for the CPU cache. Good reminder that “make it smaller” and “make it slower” are not the same axis.
- Creepy crawlies — What makes this infuriating is the sheer waste, the whole kernel repo is trivially cloneable, and yet the scrapers pick the single most expensive path, rendering 1.48 million commits across 922 forks as HTML page by page. The number that lands is that only 2% of the roughly 6 million daily requests are real developers, and 14 to 16 of 90 cores are permanently pinned just serving bots. The detail that actually worries me is the arms race, Anubis proof-of-work worked until the bots started solving difficulty-5 puzzles, which means the training data is worth enough to burn compute on. And the residential-proxy swarm through compromised IoT devices kills IP blocking as a defense, so there’s no clean answer here, just a slow tax on shared infrastructure that everyone else pays for.
- lessons in latency — The reframe I’m taking from this is latency as a budget, if the page needs to render in 100ms then serving it in 50ms buys your customer nothing, it just costs you more. That flips optimization once you’re inside the threshold, the goal stops being speed and becomes capacity and cost. The distinction I keep underselling is that average latency sets your throughput via Little’s Law, but it’s p99 that actually eats the budget, so two systems with the same 2ms average can behave completely differently when one has a 1% tail at 100ms. The storage point ties it together nicely, cheaper high-latency storage needs more replicas to hit the same throughput, so the “savings” quietly claw themselves back. Useful lens for arguing against optimization work that feels virtuous but moves no real number.
- Me divorcié de una vida de 10 años — Lo que más se me quedó es el reencuadre del título, no se divorció de una persona sino de un plan de vida entero, la casa comprada, el trabajo estable, el guión que sus padres le enseñaron. Su frase de que llevaba años intentando encajar en un molde que ya no era suyo describe algo muy concreto, tenerlo todo y aun así sentirse vacía. La semana de despedidas, desayuno de empresa, firma del divorcio y vuelo con cinco maletas es brutal por lo comprimida que fue. Y la idea final me parece la honesta, salir de una vida de diez años no termina al firmar ni al cerrar la maleta, termina mucho después cuando te reconoces en lo que estás construyendo.
- Your intellectual fly is open — The title is the whole argument, people notice the AI tells in your writing, the emoji bullets and the “it’s not just X but also Y” cadence, and no one points it out, so you keep walking around exposed. The cost he names isn’t ugliness, it’s trust, once a reader suspects the post is generated they stop believing it’s real, which poisons everything you actually did write. I appreciate that he isn’t anti-LLM, he draws the line at authorship, brainstorming and editing keep your voice central while letting the tool write for you erases it. Funny detail aside, calling LinkedIn the Gerald Ford of social networks is a good jab, it survived mostly because its rivals imploded. Sits a little pointedly next to me handing an agent my own reading notes, though the line he draws is exactly the one I’m trying to hold.
- Git at any scale — The move that stuck with me is putting a write-ahead log in S3 as the source of truth and treating the local NVMe repos as a warm cache you can throw away. That flips the usual problem, once the storage layer enforces consistency you no longer need the coordination layer to be reliable, so they can replicate with lossy UDP gossip and just verify against S3 on read. GitHub’s Spokes is the useful contrast, its three-phase commit binds every push to the slowest replica and forces you to treat repos as pets whose exact location you track. The numbers that make it concrete are 120 pushes/second on S3 Standard and linear read scaling past 100 replicas, which is the payoff for pushing correctness down into storage instead of up into a consensus dance.
- What is a Harness? | EARENDIL — I’ve been using the word “harness” for months without a clean definition, so the breakdown into system prompt, tools, agentic loop, and translation layer was worth having spelled out. The climbing metaphor earns its place because a harness supports you without taking control, which is exactly the distinction between the harness and the model doing the deciding. The part I keep turning over is the translation layer, since being able to swap Anthropic for OpenAI or an open-weight model is what actually shifts leverage from the AI companies to whoever runs the harness. Framing the harness as the thing you own and run locally, rather than a proprietary app you rent, is a cleaner argument for local agents than the usual privacy pitch.
- How I Find Problems to Solve as a Staff Engineer — The advice I expected was “block time to think strategically” and instead he argues the opposite, act like a sponge, absorb problems as they pass by, and let them pile up until a shape emerges. Deliberately not acting on every request is the counterintuitive bit, because waiting is what tells you whether a problem is real, the ones that matter resurface on their own. His Perfetto example lands the point, a stack of specific UI requests collapsed into a single need for personalization, which is a much better thing to build than any one of the features asked for. The warning I want to keep is that a common shape is only a hypothesis and elegance is not evidence, since I know how tempting it is to fall for a clean abstraction before anyone has confirmed the pain is shared.
- Software Engineering fundamentals matter more than ever — The welding analogy is the part I keep coming back to, he learned to build things in his 20s that he couldn’t lift or get out the door of the shop, and the lesson was that how something goes together is the whole game. That maps cleanly onto agents crossing the “can it be done” line, because “can it be done” turns out to be the small part of the job. The seams, the API boundaries, the choices about what should stay stable and what should flex, that’s still the work, and it’s where the reasoning has to be real. His framing that LLMs echo compressed human reasoning rather than doing it themselves is a useful way to set expectations without either the hype or the doom. Where I land with him is that debuggable and maintainable code is exactly the thing the models are worst at, so the fundamentals get more valuable, not less.
- Why Tiny JPEGs Look Different in Chrome — What I liked here is how a “thinner logo in Chrome” bug turns out to be a deliberate optimization, not a defect. Chrome doesn’t fully decode a JPEG it’s about to shrink, it decodes only the low-frequency coefficients it needs, because fully decompressing a 2000x2000 image to render it at 20x20 would burn 12MB to produce 1.2KB of pixels. libjpeg-turbo picks the closest scale with a denominator of 8 and throws away the high-frequency detail, which is fine for a photo and ruins the crisp edges on an icon. The practical takeaway is small but the kind I’ll actually remember, stop shipping icons as JPEG, because the format’s cleverness is tuned for photographs and works against you on graphics.
- Abdominal Fat Predicts Heart Disease Risk Better Than BMI - American College of Cardiology — The number that stuck with me is that people classified as normal weight by BMI still carried 15 to 50% higher risk across most outcomes if their waist-to-hip ratio was high. BMI collapses your whole body into one scalar and throws away where the fat actually sits, and it turns out where it sits is the part that matters. What I keep thinking about is how much medicine leaned on a single cheap number for so long precisely because it was cheap to measure, not because it was the right thing to measure. A tape measure around the waist would have told us more, and it was always sitting in the drawer.
- Finding the shortest binary string in a given interval — The reframing that made it click for me is that “shortest binary string” is really “simplest dyadic rational in the interval”, the fraction with the smallest power-of-two denominator that fits. So [0.1, 0.3] answers 0.01, meaning 0.25, because you can’t do it in fewer bits. The bit I liked is why the correction works, once you start above the target and only ever adjust by halving, the total wiggle you can still make is a convergent 1/2 + 1/4 + 1/8 series, so you’re guaranteed to land inside any interval with room in it. It’s the kind of problem where the naive first attempt looks obviously right and is quietly wrong, which is the whole reason Raymond’s posts are worth reading.
- Compression is prediction — I knew the compression and language modeling objectives were the same thing in the abstract, but seeing the numbers side by side made it concrete, an order-1 model needs 434 bits for a Dickens quote and GPT-2 needs 176. A better predictor literally is a better compressor, because the entropy coder just spends fewer bits on the tokens the model already expected. The honest part is where the author admits it’s useless in practice, shipping a multi-gigabyte model to shave a few kilobytes off an HTTP response is absurd. The idea is beautiful and the deployment story is a joke, and I appreciate a post that says both.
- Ordinary Abundance — Walking through an apartment object by object is a smart trick, because the awe only lands when it’s attached to something you’d otherwise ignore, the light switch, the tap, the fridge. The detail I can’t shake is Bellamy in 1888 imagining music on demand as the outer limit of human happiness, a thing I now dismiss a hundred times a day without noticing. Jefferson’s ink freezing mid-letter did the same work, it made “heated rooms” feel like an achievement rather than a baseline. I’m a little wary of nostalgia pieces, but this one earns it by staying concrete instead of sermonizing about gratitude.
- Blog about things you don’t understand yet — The test he sets is the one I want to steal, if your conclusion at the end of a draft is basically your introduction, you didn’t learn enough to publish. That flips the usual worry, the point of writing about something you don’t fully grasp isn’t to teach, it’s to force the “wait, that can’t be right” moment that only shows up when you try to write the claim down. I’ve had that experience often enough to trust it, thinking feels complete right up until you have to commit it to a sentence. The note about LLMs being unusually good and kind at flagging what you’ve genuinely misunderstood is a fair point, and a low-friction way to get the pushback that used to require a brave commenter.
- Concurrency vs. Throughput: why more parallelism can make databases slower — PlanetScale — The counterintuitive move is that when errors spiked they lowered the concurrency limit instead of raising it, dropping the transaction pool from 10,000 to around 1,000 and going from 1,500 queries/second back up to 60,000. The mechanism is the part I’ll remember, a long transaction holding locks makes every other query walk longer and longer InnoDB version chains to reconstruct its snapshot, so the cost per query grows with how many are in flight. That’s the N(N-1) coherency term in the Universal Scalability Law showing up in a real incident, and once it dominates, admitting more work just buys you more coordination overhead. It’s a clean argument against the instinct to treat a queue backing up as a signal to add capacity, sometimes the fix is admission control, not more workers.
- LLMs reward expertise — The Terence Tao example is what sells it, he asks short pointed questions, pushes back with his own suggestions rather than just contradicting, and can only do that because he knows the math well enough to spot what looks off. That reframes the skill entirely, it isn’t prompt phrasing, it’s having the taste to reject a mediocre answer with specifics like “can we express this simpler”. The line that the human is the bottleneck, not the model, matches my own experience, on code I know deeply I can push the model far harder than on code I’m just passing through. The author names the obvious objection, that this conclusion is suspiciously flattering to experts, and I’m not fully sure I’ve separated the true part from the comforting part yet.
- Almost No Skill Required to Cook a Steak (Though You Probably Can’t Make a Decent One) — Pairs naturally with the expertise piece above, the steak is just the more vivid version of the same claim, anyone can get to edible and almost nobody gets to good without judgment the tool can’t supply. The framing I liked is that the AI can’t see the picture in your head unless you translate it into requirements, constraints, examples, and tests, which is exactly the work people hope the tool removes and it doesn’t. Where it turns dark is the observation that quality collapses when every restaurant hires the same AI cook and optimizes for cost, so the burnt steak arrives everywhere at once. That’s the part I’m still chewing on, individual mastery might protect you, but it doesn’t protect you from a market that’s decided mediocre-and-cheap is the equilibrium.