Will Larson has a good post about how they’re adopting AI at his company. The process is interesting, but this is the part that jumped out at me:

My biggest fear for AI adoption is that they can focus on creating the impression of adopting AI, rather than focusing on creating additional productivity. Optics are a core part of any work, but almost all interesting work occurs where optics and reality intersect.

It’s really hard to figure out if AI tools are (1) helping teams ship faster (2) without sacrificing quality.

We’re working on figuring out this problem right now at Cloudflare. Our proposed approach sidesteps the problem of per-commit AI attribution (did Copilot write this line? did Claude?) by correlating team-level AI tool usage with team-level health metrics over time. If a team’s AI adoption increases by 30% and their change failure rate stays stable, that’s a useful signal. If AI usage spikes and incidents start trending up, that’s worth investigating.

The key insight is that you don’t need perfect attribution to get directionally useful data. Correlation isn’t causation, and teams adopting AI tools may already be more experimental or higher-performing. But at least you’re measuring something real instead of the something like “# of lines written by AI”, which leads straight to the Goodhart’s Law problem where metrics become targets.

Metadata is the hardest problem in software, and these examples prove my point. Don’t @ me!

My favourite: a band named brouillard, with a single member called brouillard, whose every single album is named brouillard, and of course, so is every single track.

Source: Horrible edge cases to consider when dealing with music →

Lorin Hochstein is a big name in the LFI (Learning From Incidents) space. He often writes about post-incident reviews, and he has a very interesting write-up of the Cloudflare outage on November 18, 2025 blog post. I especially loved this part:

Companies generally err on the side of saying less rather than more. After all, if you provide more detail, you open yourself up to criticism that the failure was due to poor engineering. The fewer details you provide, the fewer things people can call you out on. It’s not hard to find people online criticizing Cloudflare online using the details they provided as the basis for their criticism.

I think it would advance our industry if people held the opposite view: the more details that are provided an incident writeup, the higher esteem we should hold that organization. I respect Cloudflare is an engineering organization a lot more precisely because they are willing to provide these sorts of details. I don’t want to hear what Cloudflare should have done from people who weren’t there, I want to hear us hold other companies up to Cloudflare’s standard for describing the details of a failure mode and the inherently confusing nature of incident response.

Source: Brief thoughts on the recent Cloudflare outage →

This resonates so hard. The tech industry’s obsession with LARPing roles in the public sphere has really hurt our ability to work with people who care and want to do the best work of their lives without distractions.

I think it’s unlikely the industry will get much better at identifying and evaluating candidates anytime soon. And so I’m sure we’ll continue to see posts about the importance of your LinkedIn profile, or your GitHub, or your passion project. But you neglect at your peril the engineers who are working nine-to-five days at boring companies.

Source: The illegible nature of software development talent →

Don’t let the clickbait title put you off. Related to my link about AI killing jobs in tech, here Cal Newport produces some compelling “both sides” receipts about how AI is helping + hurting software development. His conclusions are solid:

My advice, for the moment:

1. Tune out both the most heated and the most dismissive rhetoric.
2. Focus on tangible changes in areas that you care about that really do seem connected to AI—read widely and ask people you trust about what they’re seeing.
3. Beyond that, however, follow AI news with a large grain of salt. All of this is too new for anyone to really understand what they’re saying.

AI is important. But we don’t yet fully know why.

Source: No One Knows Anything About AI →

This was a very comprehensive survey about everything from AI tools to Terminal app preferences, CI/CD systems, and more. Very much worth the click to skim through the results. Gergely also has an interesting theory on why developers hate Jira so much:

But I wonder if the root problem is really with JIRA itself, or whether any project management tool idolized by managers would encounter the same push back? It is rare to find a dev who loves creating and updating tickets, and writing documentation. Those who do tend to develop into PMs or TPMs (Technical Program Managers), and do more of “higher-level”, organizational work, and less of the coding. Perhaps this in turn makes them biased to something like JIRA?

Source: The Pragmatic Engineer 2025 Survey: What’s in your tech stack? →

Yes, amen to this.

As a manager, be honest to your executives and your reports. Given enough people in your team, there is no tactical decision that will make your engineers work faster. Your only real option is to admit early that your deadline is untenable, and replan by reducing features, or extending deadlines. Whipping your engineers to work harder has never worked, and will ruin their trust in you forever.

Source: You cannot survive poor management ↗

Great list of resources here by Pete Steinberger:

These resources will help you master the new paradigm of AI-assisted development, where agents become true collaborators that can handle entire codebases and ship production features. Each piece was chosen for its practical, real-world insights.

I especially appreciate that it’s a combination of articles (yay!) and videos (not for me!), and that he provides a nice overview of each so you can decide if you want to click through or not. Excellent curation, would recommend!

Read Essential Reading for Agentic Engineers ↗

Great advice here for new managers in this wild time we find ourselves in. In general:

Whereas the previous focus of managers was to rapidly hire and scale their teams, today’s focus is on expanding impact. This is because in today’s macroeconomic environment, output is key. In the eyes of a 2025 company, the more that you can do with fewer people, the better. There are very few additional people to go around, so the focus is on how you can help your team do more with less.

James focuses specifically on EMs, but the advice definitely applies to PMs too, so check out his post if this is you!

→ New advice for aspiring managers