The level system (junior, mid, senior, staff) was never a development model. It was a compensation and expectations framework. It told you what someone should be able to do at each level. It said nothing about how they got there. But because the environment was producing growth on its own, the gap was easy to ignore. The labels tracked what was already happening, and everyone assumed the structure was the mechanism.

Interesting observations on the growth from junior to senior, and how AI changes that, or maybe for some managers doesn’t change it much at all.

“Never Send A Human To Do A Machine’s Job”. The first half is a great read on what the real benefit of code review is. And there there are some interesting thoughts on AI, which you can skip if you’re not into that, and still get much value from the post.

An interesting suggestion to start out by saying “first run the tests”. I’ll try to remember to give this a go a few times. It seems like it would be a bit annoying to do every single time. Although I guess an AGENTS.md could have it. It would put pressure on making running the tests much faster, because instead of being between the agent and getting the work done, it’s between me telling the agent what work to do.

This is very much a marketing post, but this:

Most code review tools start and end with the diff. They might expand to the file, or even the repository. But that’s not how the best reviewers think.

When a senior engineer reviews code, they’re drawing on years of institutional knowledge. They remember that Slack thread from six months ago about why the team chose this particular database pattern. They know that David on the platform team has strong opinions about error handling. They’ve internalized dozens of unwritten conventions that never made it into any style guide or lint.

is very true (it brings Chesterton’s Fence to mind) and not something that comes up in a lot of code review discussions.

these days I spend far more time thinking about how to make being wrong cheap rather than how to avoid being wrong.

Whenever someone used to ask me what my purpose was as an architect, this was my answer. It’s not about getting perfect designs, it’s about reducing regret. Maybe that is a great design that has flexibility and is so well made it doesn’t get changed – equally it could be something that can replaced with almost no regret.

A bunch of interesting thoughts on MCP vs. CLI and how it’s not “vs” at all. I’m not sure I agree 100% with this, but I do with a lot, and definitely the recommendation at the end. Follows on from this excellent earlier post.

The history of IDEs is so strange.

So true!

At some point frontier models will face diminishing returns, local models will catch up, and we will be done being beholden to frontier models. That will be a wonderful day, but until then, you will not know what models will be capable of unless you use the best. Pay through the nose for Opus or GPT-7.9-xhigh-with-cheese. Don’t worry, it’s only for a few years.

Sad, but true.

use a fresh VM

There have been done interesting UI changes here recently, with things backing that underneath I assume, but still entirely true.

Read the whole thing.

AI.

Sigh.

They rhyme for a reason.

Read the whole post.

Interesting suggestions for security policies, aimed at AI reports, but generally useful in today’s world.

Now, before some of you cry “but, but it’s not production quality“ or “non-developers don’t know what they are doing, they will hire a developer to fix their vibe coded mess”.. here’s what many don’t get: Businesses run on a ton of “brittle spreadsheets” already. People have been “vibe spreadsheeting” for a long time.

A good insight. In-house software is (especially outside of tech organisations), in my experience, terrible. Awful UX, buggy, half-done. And continually used for critical functions.

When a colleague writes code, I know their patterns, their strengths, their blind spots. I can skim the parts I trust and focus on the parts I don’t. With AI, every line is suspect.

Siddhant Khare on AI Fatigue. I 100% agree with the above, and I think I’m feeling some of this, too.

I had a recover lost code experience similar to this a couple of weeks ago. In my case the VM crashed and when it rebooted the mount was missing, which made it look like the folder I had been working was empty. Claude recovered almost everything from logs (great, but a bit scary) before I realised everything was still there on the host.

I’ve heard thoughts like these on AI building on the foundation of WordPress for other durable, foundational, infrastructure type systems before. It seems true right now, although I wonder if it will change in the near future.

Interesting thoughts on AI] from Mitchell Hashimoto.

A really thoughtful essay on using LLMs in exams, but also on “cheating” and more.

Very much not the point of the piece, but:

Most of my students don’t like email. An awful lot of them learned only with me that Git is not the GitHub command-line tool.

😩😣😢

A lightweight explanation of the history of Markdown. I think there is an element of luck, or right place right time, though, and we could easily have all been writing setext if a butterfly had flapped a bit differently.

So if you want to get something technical done in a tech company, you ought to wait for the appropriate wave. It’s a good idea to prepare multiple technical programs of work, all along different lines.

Good advice, from sean goedecke.

Maybe the answer is that we need better tools — better ways to signal quality, better ways to share context, better ways to make the AI’s involvement visible and reviewable. Maybe the culture will self-correct as people hit walls. Maybe this is just the awkward transition phase before we figure out new norms.

I feel like this is true - and that probably a lot of these tools are already being built, and culture will eventually catch up. But maybe it’s an optimistic take.

From another thoughtful post from Armin, which also has:

All I know is that when I watch someone at 3am, running their tenth parallel agent session, telling me they’ve never been more productive — in that moment I don’t see productivity. I see someone who might need to step away from the machine for a bit. And I wonder how often that someone is me.

In general, I feel a lot of UI-first SaaS will be disrupted by API-first players.

This rings very true to me. Being API first was better all along, but it will be felt more now.

This finding the Nebraska guy post dives quite deep into graph theory and algorithms, and I found it really interesting.

Product is the leadership I expected as a tech lead/principal

This is similar to why & how I moved into product, firstly the “ticket-chopping folks” (which I had somewhat been previously anyway) and then true product management.

Of course, 5 years later I was burnt out and hated my job and very grateful to move back to software engineering … but there were lots of other factors there.

When you see a package with 10,000 stars, you’re not looking at 10,000 developers who evaluated it and clicked a button. You’re looking at a number that could mean anything. Maybe it’s a beloved tool. Maybe it’s a marketing campaign. Maybe it’s a malware distribution front with a Stargazer Goblin account network behind it, it’s pretty much impossible to tell.

I have long argued that stars and download counts are untrustworthy metrics. Lots of good details in that post.

Optimism, on the other hand, is a toxin to be avoided. Optimism is a subgenre of fatalism, the belief that things will get better no matter what we do. It’s just the obverse of pessimism. Both are ways of denying human agency. To be an optimist is to be a passenger of history, along for the ride, with no hope of changing its course.

I very much disagree with this definition of optimism. Optimism is a belief that things will get better because most people will actually work for that. Basically, it’s faith (not necessarily in a higher power), which is oddly missing from the happiness, optimism, hope trilogy here.

In fact, I think he entirely swaps the definition of hope and optimism. I am not at all optimistic (in that I don’t believe people will rise up, or that the people with power will make things truly better) but I have hope (unfounded, not driven by people action) that I am wrong.

Another vibespiling experiment, this one MiniJinja from Rust to Go.

This changes some dynamics. I feel less like technology choices are constrained by ecosystem lock-in.

I haven’t seen this mentioned in other similar attempts, and I agree it’s an interesting change in dynamics. It’s interesting also in terms of hiring and how broad language experience should be (or not) within a team.

Once, having people port your code to other languages was something to take pride in. It was a sign of accomplishment — a project was “cool enough” that someone put time into making it available elsewhere. With agents, it doesn’t invoke the same feelings.

I’m still curious to see how this plays out. I have seen several people unhappy about this - for now, ones like Armin vibespiling his own work seems the safest path.

uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still.

How uv got so fast.