3 Things Worth Reading #001

Self-Taught Engineer · weekly roundup

Is anybody reading the code?

Kicking of the start of the week - I read a lot of newsletters so you don’t have to. Here are three pieces worth reading.

The main idea in all three is simple: understanding the system is the real asset. Code is just one costly way to keep that knowledge. Typing code is getting automated. Holding a clear model of what the system does, why it does it, and how you’d know if it broke is getting more valuable, and that has been the self-taught person’s whole job from day one.

1. The Software Dark Factory (Commoncog) * members only

https://commoncog.com/software-dark-factory-q-a/

What it is: Cedric Chin hosted a demo and Q&A with Jay Taylor and Navan Chauhan of Dark Factory Inc. (ex-StrongDM AI Lab). They run a shop where no human writes code and no human reads the code that gets generated, and they ship to banks. In the demo, you’ll see a working Slack clone. Jay built it in five days, using just his phone and his free time, as a test environment.

My take: A tempting takeaway is that understanding is obsolete: stop reading, stop reviewing, let the loops run. I think Simon Wardley has the better read on where this goes. He wrote in December that LLMs are “coherence engines not truth engines,” that specs are only “statements of belief,” and that vibe coding a system you don’t understand means “handing over control, decision making and understanding to the machine.” And the session itself backs him up more than what I think the founders’ framing does. The moderator kept stressing that both founders are exceptional engineers whose knowledge runs so deep they use it without noticing. They run one person per codebase, deliberately, so the entire structure stays inside one person’s head. Their 20-to-1 validation ratio, the digital twins, the video proof: all of that is understanding, moved out of code review and into machinery they designed because they understood the problem. The factory didn’t eliminate the expert. It concentrated ten engineers’ worth of judgment into one person.

The risk for 2026: thousands of teams might copy the workflow without a “foreman”. They’ll run the loops, skip the reading, and have nobody left who can tell why the system drifts when it drifts. Wardley’s alternative isn’t nostalgia for line-by-line review. It’s making understanding cheaper: better names, better tests, generated views of the running system, tools that let a human see what’s happening without reading every line. That’s the version of this future worth building toward.

Read it if: you build in Python and SQL and want to see the most extreme version of hands-off development actually shipping, so you can decide which half of it to adopt. Pair it with Wardley’s case for keeping understanding human.

2. Is “jobs” a four-letter word? (Benn Stancil)

Is "jobs" a four-letter word?

What it is: Benn on how tech’s status symbol has inverted. Ten years ago prestige meant headcount: big teams, big offices, TechCrunch tours. Now “the highest status job in tech is getting rich while running the smallest team,” layoffs are marketing, and the one-person billion-dollar company is the founder fantasy of the moment.

My take: An 800-person company has room for someone who does one thing well. An 8-person company has none. Every seat at a small company is filled by someone who can access the data, the product, and the customer all in one afternoon. The traditional degrees path trains you for the big company: go deep on one layer and trust the org chart to cover the rest. The self-taught path trains you for the small one, because you learned whatever the problem in front of you required. The industry spent twenty years telling generalists they weren’t real engineers. If Benn is right about where status is heading, small teams are about to pay a premium for exactly the people that advice was designed to filter out.

Read it: if you want to see why “revenue per employee” matters for your career more than any framework this year. You may wonder if it’s a healthy metric, but it seems to be the path we’re on right now.

3. From Vibes to Evals (MotherDuck)

What it is: A practical guide on moving LLM-on-data work from gut feel to measurement, including a 7-step eval playbook you can run on your own warehouse. It’s gated behind an email signup, but since everyones email is up for grabs these days I thin it is worth the trade.

My take: An eval is an assertion: given this input, is the output acceptable. Data people have written these in SQL forever, as row counts, null checks, and “does this match finance’s number.” The AI industry renamed the practice, and the rebrand mostly benefits people selling eval tooling. The guide’s experiment proves the point better than opinions ever could. Renaming warehouse columns boosted accuracy from 7% to 44% on a public benchmark. Plus, a simple model using a well-named schema outperformed an expensive model trying to guess with a poorly named one. Measurement and naming. The two oldest jobs in data turn out to be the two skills that make AI on data actually work. A well-named schema is understanding made cheap, which is this whole edition’s theme in miniature. If you can write a dbt test, you can write an eval.

Read it if: you use LLMs anywhere near a warehouse and want the discipline that separates a cool demo from a thing you can put in production.