HN DigestHacker Newsletter, digested

Issues

Issue #811

11 postsRead the newsletter ↗

Don't skip

#Working

There's no point at which turning your brain off will work

  • danluu.com
  • 206 points
  • 157 comments
  • 14 min read

Dan Luu argues that acting as a brain-off "meat proxy" for an LLM can't pay off for an employee. While the LLM can't do the job alone, the result is bad software. Once it can, the company has no reason to keep the proxy.

Dan Luu's long argument, built on concrete examples of LLM-built software failing in practice, that a developer who just relays what the loop produces is doing a job the company could run without them.

#Favorites

I don't want to read what you didn't write

  • blog.colinbreck.com
  • 1,070 points
  • 460 comments
  • 13 min read

Colin Breck argues that AI-written design docs, PR descriptions and messages fail their readers. The reader lacks the context that the sender had when they prompted the AI. Breck uses AI to check facts, add citations and edit his own text. But he found its drafted prose unpleasant and often wrong.

A case against handing colleagues AI-written design docs, PRs and summaries, paired with the author's own line between what he let the model do on a paper and what he wrote himself.

Worth your time

#Working

I don't want the details

  • michaelheap.com
  • 466 points
  • 226 comments
  • 4 min read

After an incident, asking why it happened tends to produce a reasonable story and no change. Michael Heap retells how an SVP cut off his explanation. He argues the useful question is what the team will change to make the same class of failure less likely.

Argues that a postmortem should end with what will change, not with a good explanation, because a satisfying 'why' can kill the urgency to fix anything; the thread pushes back on leaders who skip the specifics.

#Working

The senior engineer death spiral

  • sunilpai.dev
  • 285 points
  • 150 comments
  • 4 min read

Engineers new to a senior role often take on an oversized project to prove themselves. They go quiet for weeks and spiral into overwork and burnout. Sunil Pai's fix is to drop a level for a while and do bugs and grunt work for teammates. That daily momentum rebuilds the trust that brings bigger work back.

Names a common failure after promotion to senior (overreach, silence, hidden overwork, burnout) and a way out: become the most helpful person on the team and rebuild trust with steady, visible work.

#Learn

Why is the liver so weirdly regenerative?

  • dynomight.substack.com
  • 579 points
  • 294 comments
  • 20 min read

Most of the body heals poorly because regeneration means cell division, and cell division feeds cancer. Organs that face the environment, like the liver, skin and colon, pay a cancer tax to stay repairable. The small intestine renews fast with little cancer. It pays in energy instead, which makes the trade-off three-sided.

A careful, footnoted essay on why most organs barely heal while the liver regrows, built on one idea (regeneration buys cancer risk), and a thread where a pathologist and others dig into vitamin A.

#Code

Saving another 100TB of RAM

  • blog.cloudflare.com
  • 488 points
  • 123 comments
  • 13 min read

Cloudflare cut more than 100TB of RAM from the Pingora Backend Router (PBR), its consistent-hashing load balancer. Two changes did it: 6-byte hash entries instead of 8, and 90% fewer hashes per server. Cloudflare's math showed the extra hashes bought almost no extra balance. Past a point, 32-bit collisions made the balance worse.

Shows the arithmetic behind a large saving: derived error formulas that justified cutting hash points per server by 90%, and a rollout staged per data center to avoid a global cache flush.

If you have a minute

#Ask HN

Ask HN: How do you interview devs in a post-AI world?

  • 48 points
  • 43 comments
  • HN discussion

A hiring manager says about 80% of developer candidates now direct AI agents instead of writing code. The manager asks whether leetcode and design rounds still make sense. Most HN answers say to test judgment rather than typing. They suggest having candidates review flawed code, extend their own submission without AI, or explain every part of what they built.

A short question that draws concrete interview formats from people who run them: debugging a deliberately broken codebase, pairing without AI, agentic take-homes.

#Code

AI coding has made CI a bottleneck, so we reworked ours to keep up

  • linear.app
  • 317 points
  • 408 comments
  • 9 min read

Linear's test suite nearly quadrupled since the start of the year, mostly from agent-written tests. Faster runners, leaner setup and smarter sharding still cut PR wait from over 6 minutes to just over 5. Runner time per test fell by half. Doing nothing would have meant about 11 minutes.

Concrete before-and-after timings for each CI change in a large TypeScript monorepo: native TypeScript compiler, lint without type information, leaner installs, Vitest sharding.

#Favorites

How to Write with an LLM

  • sockpuppet.org
  • 769 points
  • 420 comments
  • 6 min read

Write every word yourself, and use an LLM only as a copyeditor that flags problems. Two rules keep it from flattening your voice. First, never accept a single word it suggests. Second, forbid it from praising your draft. Its encouragement talks you out of the rewrites good writing needs.

A workable method for treating an LLM as a copyeditor rather than a ghostwriter, with two strict rules, and a thread of developers applying it to commit messages and PR descriptions.

#Show HN

Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design

  • github.com
  • 424 points
  • 143 comments
  • 4 min read

Whiteboard is an MIT-licensed desktop app built on a vendored Code OSS. In it, a coding agent such as Claude Code or Codex draws diagrams of its work that link straight to the code. Whiteboard adds a semantic diff viewer and a log of the decisions the agent made on its own. The goal is to let developers review agent-written changes without piling up "cognitive debt".

An open-source desktop tool where coding agents draw sequence, ER and architecture diagrams linked to code, with a decision log, and a thread comparing it with C4 and PlantUML.

#Design

The Effect of CRTs on Pixel Art (2024)

  • datagubbe.se
  • 315 points
  • 129 comments
  • 14 min read

Most of the blur people credit to CRTs came from cheap PAL and NTSC TVs fed by RF or composite signals. On a good RGB monitor, pixels stayed plainly visible. Old pixel art looked good because artists used dithering, anti-aliasing and careful palettes. Modern pixel art that skips those techniques looks blockier than the originals ever did.

A long, illustrated essay arguing that classic pixel art owed its look more to dithering, anti-aliasing and palette choices than to CRT blur, with C64, Amiga, SNES and VGA examples.

Also in this issue

Everything else is in the full newsletter ↗