Menu

Posts tagged “engineering”

Humans make mistakes, and so does AI. It's fine.

Will Larson has a good post about implementing “Agent Skills” in their internal agent framework at Imprint. The whole piece is worth reading, but I wanted to highlight this observation:

Humans make mistakes all the time. For example, I’ve seen many dozens of JIRA tickets from humans that don’t explain the actual problem they are having. People are used to that, and when a human makes a mistake, they blame the human. However, when agents make a mistake, a surprising percentage of people view it as a fundamental limitation of agents as a category, rather than thinking that, “Oh, I should go update that prompt.”

There’s a double standard at play here that I’ve noticed too. When a colleague writes a confusing document, we ask them to clarify. When an agent produces something off, we tend to smirk and declare the technology fundamentally broken.

The fix is often as simple as updating a prompt—the same way you’d coach a team member to write better tickets. Skills, in Larson’s implementation, are essentially reusable prompt snippets that encode learned behaviors across workflows. It’s the kind of organizational knowledge we build up with people over time, just made explicit.

Building MCP servers in the real world

This has been my experience with MCP servers as well. As useful as I think my Last.fm MCP server is, I can’t see it every having more than a dozen users. But internal company servers are massively useful:

MCP is being used especially heavily by internal data and platform teams to give internal users access to systems. These are systems that these users perhaps already had access to, but it was either too complex or too broad, or needed a lot of documentation or special skills to use.

Wiki search is so much better now that I can use our internal MCP server for it via Windsurf.

Source: Building MCP servers in the real world →

Measuring AI's Impact on Shipping Speed and Code Quality

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.

New side project: Discord Stock & Crypto Bot

Not sure how many people would be interested in this, but it was fun to make so I thought I’d share. This is a Discord bot that provides real-time stock and cryptocurrency information, 30-day price trends, and AI-powered news summaries through slash commands. When you add the bot to Discord you can use the /stock and /crypto commands to get information like this:

Want to add it to your Discord server? Head over here!

Horrible edge cases to consider when dealing with music

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 →

Brief thoughts on the recent Cloudflare outage

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 →

The illegible nature of software development talent

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 →

No One Knows Anything About AI

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 →

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

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? →

You cannot survive poor management

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 ↗