Marginal Contributions

Speed, Fidelity, and Thickness

August 23, 2026

Three related articles, with minimal commentary:

Florian Herrengt, “AI is removing the middle class of software engineering”:

Excerpts

AI removed the speed limit

AI makes projects with weak engineering culture fail much faster.

There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.

The most tragic aspect of this way of working is that, to the untrained eye, it works.

If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.

Just like someone buying a new luxury car on a credit card. You don't see the debt. You just see the car that looks great.

“Bad engineers always existed”

The difference is the speed.

It is the difference between crashing at 30 km/h and crashing at 200 km/h. Before AI, a bad engineer would struggle to produce code that even compiled. When they did produce something, it took them a long time and the blast radius was limited. The damage was bounded by how fast a human could type.

Now a bad engineer can produce 10,000 lines of working code before lunch. The damage we can do in an afternoon used to take them months. The speed at which bad decisions compound has changed completely while the speed at which you can fix them has not.

“Will anyone actually care?”

They will care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.

This was already happening before AI. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can get there in just a few months.

Reminder: being good at software engineering isn't just about algorithms or systems design or whatever. Even pre-LLMs, it 100% definitely wasn't correlated with how fast you can put out new features.

It's about creating a system that's easy to reason about: easy to debug, easy to change, and hard to break—even when it's complicated.

Knowledge work isn't hard

August 10, 2026

Read "Code was never the hard part" is an insult to all programmers.

Widely shared on Hacker News and Lobsters — how much of that is fact vs. flattering to our egos as developers is hard to say. We want to feel like we're doing something difficult. Not quite rocket surgery, but by jove, not just anyone can write code!

It also happens to justify our salary.

Bad tests ossify

July 14, 2026

matklad’s How to Test is one of the best articles on testing. 10/10. Almost all of it is right.

My own two cents: No tests beat bad tests.

Three patterns for substring and subarray questions

July 14, 2026

Coding-interview substring and subarray problems often reduce to one of three patterns.

1. Sliding window (two pointers)

Use a sliding window when the constraint changes monotonically as you expand or shrink the window.

Use it for: substrings with “at most K distinct characters,” all unique characters, or subarrays with sum constraints when all numbers are nonnegative.
Core idea: Expand right to include a new element. If the window becomes invalid, move left until it is valid again.

Communicating expertise

July 13, 2026

Tuhin Nair’s article frames a common conflict. A business reduces uncertainty: ship an experiment, learn from the market, choose the next bet. Senior developers manage complexity and stability: keep the system understandable, reliable, and tied to clear responsibility.

Answering a request with maintenance costs addresses the wrong loop. A better response offers a shorter, cheaper experiment that answers the business question without binding the result to the core system. This turns technical judgment into a path toward evidence.