What does the future of engineering look like? And more.
Every Friday, I share a handful of pieces that caught my eye at the intersection of technology, media, and society. This week’s edition is late!
*This week’s links discuss the future of software development, how the EU’s attempts to …
What does the future of engineering look like? And more.
Every Friday, I share a handful of pieces that caught my eye at the intersection of technology, media, and society. This week’s edition is late!
This week’s links discuss the future of software development, how the EU’s attempts to build sovereign tech must involve helping people to create businesses around it, the complex issues surrounding trust and safety on Bluesky and similar platforms, and a concrete protocol for making professional connections between people well.
Did I miss something important? Send me an email to let me know.
The Five Levels: from Spicy Autocomplete to the Software Factory
Software development is transforming incredibly quickly. This guide, although it looks a bit silly at first glance, is very aligned with what I’ve heard from friends and seen first-hand.
“I’ve now seen dozens of companies struggling to put AI to work writing code, and each one has moved through five clear tiers of automation. That felt familiar, and I realized that the federal government had been there first – but for cars.
In 2013, the NHTSA created the five levels of driving automation. This was helpful, because while the highest level at the time was only level 22, it let everyone have a common language for both where things were, and where things were going.”
What follows is instructive; some of the interim steps are waypoints, but 4 and 5 seems to be where a lot of mainstream software development is going. We can thank Claude Code for this; many of these changes took place last year, with some pre-work laid down by the AI vendors and various startups beforehand. My guess is that everything will have changed again by the end of the year.
In the hands of senior engineers who are getting their heads around how these tools work, AI coding is starting to work as advertised. There’s a reason why engineers who have been coding for decades rave about it. But we’ll also see some really bad code (particularly in enterprise organizations) and some high-profile failures. There’s something I’ve called The Mythical Claude Code Agent Month (I need to find a pithier name), where in response to process and culture failures that are hampering its software development, an organization just decides that it needs to add more AI. And hallucinations, bias, and model poisoning are all real things.
In response to this, and because a lot of engineers are ideologically or otherwise opposed to AI, I think we’ll begin to see explicitly artisanal software companies emerge. In some industries, particularly highly-regulated ones, we’ll also see new kinds of trust certificates emerge to prove that (regardless of how it was built) software performs well and doesn’t leak private information.
Anyway, those are all knock-on effects. As of now, this is where mainstream software development is likely going. This isn’t an endorsement, necessarily — but it is a good-faith observation.
Funding Open Source for Digital Sovereignty
Vital thoughts from Drupal founder Dries Buytaert on how, if Europeans and others are going to rely on open source software as a way to decouple from US services, funding the people and communities that build open source software must be part of the conversation:
“Open Source is the most credible path to digital sovereignty. It’s the only software you can run without permission. You can audit, host, modify, and migrate it yourself. No vendor, no government, and no sanctions regime can ever take it away.
But there is a catch. When governments buy Open Source services, the money rarely reaches the people who actually build and maintain it. Procurement rules favor large system integrators, not the maintainers of the software itself. As a result, public money flows to companies that package and resell Open Source, not to the ones who do the hard work of writing and sustaining it.”
Dries’s solution involves evaluating a company’s open source contributions as part of a procurement process. If governments and other organizations are willing to do this in practice, that would work, at least for certain kinds of maintainers and communities. It would favor the companies that give back to an open source project over the ones that just repackage someone else’s work, and in doing so, make it more attractive for companies to give back in the first place.
But I think there’s another way to look at the problem: provide the tools, infrastructure, and platforms for maintainers to start companies around their work. Rather than encouraging existing companies to become open source participants, this would encourage open source participants to become companies. It might even incentivize new kinds of companies to be drawn up as co-operatives of open source maintainers.
When a company obtains software, it’s looking for more than the code: it needs a solution to a problem. Services address organizational problems more directly than codebases alone. There’s a reason why Dries’s Acquia and Matt Mullenweg’s Automattic have become so successful.
There is nothing unethical about creating services businesses (or non-profits with service missions) that are aligned with the open source nature of their underlying products — and, indeed, that direct connection with customers will make those products better. But I’d say that most open source maintainers either aren’t thinking that way or are daunted by the prospect. So perhaps they could use a little help?
An open source services in a box solution for these maintainers — including business fundamentals, sales and marketing, and a kind of operating system for running a small company around open source — could be an interesting way to both make open source software more palatable for institutional buyers and bring more money into their ecosystems.
Code, generally speaking, is not a solution in itself, but it can be part of one. This would fill in the rest.
On ICE, Verification, and Presence As Harm
This post by Laurens Hof speaks to a bunch of issues at the intersection of our current moment in history (I haven’t yet found the words to refer to it that don’t sound like a euphemism) and the open social web.
ICE joined Bluesky as part of a wave of Trump Administration accounts that were created last November, as an apparent intimidation tactic against a network that was perceived to be largely left-wing. It never posted and the account seemed abandoned, but Bluesky officially verified it this week. Subsequently, it made a post to further its narrative about Liam Conejo Ramos, the five-year-old whose local public schools superintendent says was used by ICE as bait.
As Laurens points out, what happened next on the two main pillars of the open social web was interesting:
“The decision by Bluesky PBC to verify the ICE account, two months after registration and without the account being active, lead to quite different responses for the fediverse and for the ATmosphere. On the fediverse, the choice by Bluesky PBC to lend legitimacy to ICE was a final nail in the coffin, with loud declarations to disconnect from Bluesky and block the bridge between these two networking protocols. Mastodon founder Eugen Rochko was the most notable account, who publicly declared to disconnect from the bridge.
Within the ATmosphere, the response focused on two parts, both a frustration with Bluesky PBC verifying the ICE account, as well as a call to block the account en-masse, which led to the ICE account quickly becoming one of the most-blocked accounts on the network.”
For Mastodon, this is in some ways an endorsement of the fediverse model. Both communities and individuals can choose not to connect with other communities and accounts that they find harmful.
This is in contrast with the AT Protocol model, which is not made of archipelagos of smaller communities; it’s a wide town square at scale, much like Twitter was. For Bluesky, this is indicative of the tension between being an open protocol and a prominent consumer social media platform. On one hand, the protocol allows anyone to be a verifier: in this model, the government itself could have verified the ICE account, and any client that trusts the government to verify would have displayed a badge. This arrangement would avoid the appearance of Bluesky endorsing ICE. On the other hand, Bluesky the platform has its own verification service, because you need that on a commercial social network to prevent imposters and other abuse.
The timeline between verification and ICE’s first post is a little odd. But it’s also true that ICE is a government agency. If ICE is going to be on the platform to begin with, sticking a badge on its account to ensure everyone knows that, yes, this is the real ICE, is not a bad idea.
I’m going to pause here and state, for the record, that not only am I not a fan of ICE, I believe they are committing crimes and following a terrifyingly fascist playbook. People are being both kidnapped and murdered on the streets.
That’s important context for this next discussion:
“Bluesky’s Community Guidelines lists the two major principles as ‘Safety First’ and ‘Respect Others’. It is somewhat unclear how the presence of a fascist police force that is actively working to instigate civil war aligns with the principles of safety and respect that Bluesky supposedly champions.
When it comes to actual rules in the guidelines, it is all about user behaviour and the content on Bluesky. The problem is that it is the presence of ICE itself that is already causing the harm. The intimidation of ‘we are here, you cannot escape us’ is the point, and the accounts by the regime are deliberately trying to provoke an outrage.”
These things are true, in my mind. But it’s also really complicated.
If you were Bluesky, what would you do? Which precedent would you set?
Imagine if it were to ban ICE on the grounds that it is causing harm both in the world and through its presence on the platform. (It is causing harm.) ICE remains a government agency, and doing so would therefore be a political act. Its actions are claimed to be legal by the government. Banning it could set a precedent that Bluesky can ban accounts whose politics it disagrees with. At the very least, it would be contentious and cement its reputation as a left-wing network.
If it doesn’t ban ICE, we get the situation we have today. People are upset that ICE has a presence on the network. Some users on Mastodon, which is largely seen as a place for people to connect safely in smaller groups, disconnect from the Bluesky bridge. Some users on Bluesky are upset that it appears to be endorsing ICE by verifying the account; it becomes one of the most-blocked accounts within a matter of hours. And then ICE uses it to spread its message. Not banning it could be seen as an endorsement, or as Bluesky not taking what ICE is doing and represents seriously enough. That’s particularly true when banning the account would only ban them on the official Bluesky apps, not on the AT Protocol ecosystem as a whole.
It’s not a problem that Bluesky-the-protocol would have, but the fact is that it’s primarily a consumer platform. And if any consumer social platform makes trust and safety rulings that are, in effect, arbitrary, it sets a precedent that it can turf people off its platform on a whim, which undermines both trust and safety.
But it’s also extremely hard, because ICE is terrifying, they are kidnapping and killing people on the streets, and most people don’t want them in their space. Users likely moved to Bluesky to get away from the hard right wing discourse happening over on X/Twitter; the community self-selected largely based on that fact, which made it feel safer, but the platform itself doesn’t necessarily share those values.
A social media app that aims to be town square is different to a social networking app that aims to provide a smaller, safe community. The latter has a far easier time banning accounts from entities like ICE, because it can set a tighter set of community rules. So one lesson is perhaps that we need — or at least, many people need — a pluralistic open social web, where we can choose communities based on our values. That’s closer to the fediverse than to the ATmosphere model: the fediverse is smaller communities, while the social media ecosystem being built on AT Protocol is closer to an open version of Twitter.
Bluesky is in a tough position. It’s building an open protocol but most of the users of its flagship app don’t give two hoots about that. They’re looking for a safe place to discuss and share, and Bluesky’s core value for them is that it’s not X/Twitter and doesn’t have the toxicity of that network. It’s considered to be easier to use than Mastodon because there’s one place to sign up and one official app. AT Protocol wouldn’t be as successful as it’s becoming without that dynamic. So it has to continue to foster that community while also maintaining its protocol, and it can’t fork itself to create multiple app experiences for different audiences. It also can’t indicate that its flagship app is just for people who hate ICE.
My conclusion is that Bluesky is doing the only thing it can — and this is the only path that leads to AT Protocol becoming a successful open social web protocol. You need to have a vibrant community, and most people who join one don’t care about the underlying technology. There’s a world, later on, where other providers create viable alternative microblogging experiences with different takes on trust and safety — which is beginning to happen with Blacksky and Eurosky — but the ecosystem is not there yet. Protocol success and community safety have conflicting requirements, and Bluesky has to continue navigating that ambiguity for now; later on it may be able to focus on the protocol.
Meanwhile, ICE is doing a lot of harm, and its presence may be a real risk to many of Bluesky’s users. They may find that the fediverse, after all, is a better place for them to call home.
The Forwardable Email
I know I share posts from Corey very regularly, but it’s because I’ve been working with him in various ways for over a decade, and the things he suggests are often techniques I’ve used productively for a long time. This is another great one.
I insist on double opt-in introductions if I’m making a connection. That means I check in with the connectee first: do they actually want this connection? It’s a little slower, but it means connections are always consensual.
To be able do that really well, a forwardable email is the perfect tool. Here, the person who wants to be connected drafts an email designed to allow me to forward it to the connectee with a little bit of added context. It gives them what they need to make an informed decision.
Corey’s template is actionable and really works: it’s what I’ve done for a decade now. It’s simple, but the underlying structure is not what most people are doing.
Honestly, I’m also just very happy that this is in a post on Corey’s site, because now when I tell people to write me a forwardable email, I can just point them to this. Please, if you’re asking me for a connection, this is the template I would like you to follow.