I spent a decent amount of time reading through it and checking some of the referenced sources.

In today’s article, I’m offering my usual unfiltered and opinionated take on it.

As we go through the analysis, I hope the reason why I refer to it as a brochure, rather than a report, will become clear.

If it doesn’t, please reach out with your observations and comments.

Let’s start with a quick summary of the brochure.

The Core Message: AI as an Amplifier

The core message from the 2026 report, ambitiously titled The ROI of AI-assisted Software Development¹, is clearly spelt out in the executive summary:

Artificial Intelligence (AI)1 serves as a powerful amplifier in software development. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. The greatest returns on AI investment come not from the tools themselves but from a strategic focus on the underlying organisational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams.

Wait a second; this sounds familiar.

You might have read the 2025 report, called State of AI-assisted Software Development, whose executive summary read as follows:

The research reveals a critical truth: AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high performing organizations and the dysfunctions of struggling ones. The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams.

The previous report came out about 6 months ago2, and it’s important to note that it was written in close collaboration with IT Revolution as their premier research partner. IT Revolution is the company founded by Gene Kim, one of the two co-authors of the questionable Vibe Coding book, in which they both mentioned they had a clear goal to help DORA fix the 2024 anomaly, as they liked to refer to it.

But back to the 2026 report: I’m only at page 3 and already wondering what new information it is bringing, compared to the previous one.

Things start becoming clearer, and somewhat interesting, in the following section of the executive summary.3

Quantify the ROI of AI Investments

The authors here introduce the real core idea of the brochure, because at this stage it’s no longer a report. The core claim is basically that investments in AI naturally follow a J-Curve path: a temporary productivity and stability dip before the trend reverts and gives you exponential growth.

The document is in fact a series of recommendations on how to sell the business case internally. And it’s obviously never questioning whether that should be the goal to pursue.

If you’re scratching your head at this point, you’re not alone.

While previous DORA reports, including the already mentioned 2025 issue, used to follow a genuinely rigorous research approach to help understand the current reality of what drives software delivery performance across the industry, the 2026 version is a set of recommendations mostly based on speculation.

Or, to use an analogy, if previous reports could be considered scientific books (though as far as I know, they have never been peer reviewed), the 2026 edition is the airport book equivalent.

Now, that sounds like a bold statement that I could get away with if I were a tech CEO, but since I’m not, I’ll do what normal humans do: provide arguments and evidence to support the claim.

#1: Relying on self-reported data

DORA studies have always been based on self-reported qualitative data. It’s something many teams don’t fully understand and often misleads them in their interpretation of the results, especially when they start implementing their own internal quantitative metrics.

While this has always been a caveat, when applied to the space of AI, things get worse.

All of the data represented on this chart is based on self-reported data.

Now, the 2025 METR study4 highlighted something important, beyond the actual conclusions. People are extremely bad at estimating the improvements in individual productivity and tend to overstate them. It might be due to the fact that the AI discourse is loaded with propaganda and confirmation bias, which makes it significantly harder for anyone involved to maintain an objective view.

This becomes important when processing the results from the 2025 AI DORA report, as the most significant positive impact reported by practitioners is in the space of individual effectiveness. Such detail in itself does not invalidate any of the results, though the 2026 report could do a much better job at mentioning the important caveat.

#2: Core attribution flaw

This is my favourite part, and I think it’s the core flaw of the whole model.

Essentially, thanks to the work done on DORA over multiple years, culminating with the 2025 report, the researchers have identified a series of capabilities that operate as enablers for AI adoption. Remember, the core finding was that AI operates as an amplifier.

They summarise the value model in the following diagram.

Now, here is the interesting part.

The whole point is that in order to get positive results from AI, you need to invest in underlying software engineering capabilities. These capabilities, with very few exceptions such as the AI-accessible internal data, are largely AI-agnostic. What I mean by that is that, as proven by the previous years of DORA findings, investing in those capabilities tends to lead to improved software delivery performances.

That was true before AI, and it seem to be just more true when you add AI to the mix.

So, while in the coverage of the ROI model is suggested (though largely glossed over) that the cost of these investments should be accounted for, all the benefits of the investment are simply attributed to AI adoption, without discounting the improvements generated by the enablers alone.

In other words, the ROI model doesn’t assess the isolated marginal benefit of putting AI on top of all these generic and proven improvements on the SDLC but mixes all of them together, effectively selling the idea that the results are directly caused by AI adoption, even if a significant portion of them are simply caused by better engineering practices.

All the benefits are bundled into the AI investment bucket, and that’s the fundamental attribution problem.

Now, for those of you with a penchant for wicked movies, as I was reading through this part of the report, I couldn’t help but think about the famous restaurant scene from Monty Python’s The Meaning of Life.

Careful, the images are honestly disturbing. You might want to skip the clip and read the description below. You have been warned.

Mr Creosote eats an outrageous amount of food. When he cedes to the insisting waiter and eats a mint at the end of the meal, he literally explodes. Attributing the explosion to the mint while ignoring everything he ingurgitated prior to it is exactly like attributing the ROI to AI alone while ignoring all the non-AI-specific investments made to support it.

#3: Weak supporting data

The report makes some other interesting claims that are glossed over. One of them immediately triggered my sceptical neurones:

Evidence from the Stanford Artificial Intelligence Index shows that raw inference costs for advanced models have plummeted remarkably, dropping by a factor of 280 between November 2022 and October 2024. Because the cost of querying models is approaching zero, the true financial burden of adoption has shifted to governance cost.

Wait, are we sure about that? Aren’t we seeing all AI companies increasing their prices instead? This is something I’ve been reporting on previously.

Also, isn’t everyone constantly repeating that AI moves so fast that yesterday’s data is already stale and outdated? Then why look at the cost of inference between 2022 and 2024? Does it make sense to linearly extrapolate from a 2-year trend and assume it continues in today’s reality?

So I looked up the quoted article, looked into the section around inference cost, and found the following telling graph.

Who on earth is using any of these models for “serious” software development? Isn’t everyone telling the story that everything changed since Claude Code and then Sonnet/Opus 4.5 came out sometime last year?

So, let’s look at the price per million tokens for the models that are most popular these days:

Essentially, the modern Sonnet 4.x models cost exactly the same as the 3.x generation from 2 years ago. The same goes for the Opus versions, and then you have GPT-5.4 costing an insane $180 per million tokens in output.

Add to this the fact that models are still largely subsidised, as their real cost is known to be significantly higher than what they’re priced for; the insane amount of investments in AI datacentre build-up we’ve witnessed in the past few years; and the emerging discomfort among CFOs as they see their AI bill skyrocketing, and the apparently innocuous statement that the cost of querying models is approaching zero suddenly deserves a lot more scrutiny and, above all, requires a lot more hard evidence.

Casually mentioning a study about models from more than two years ago, unfortunately, is not enough.

The second piece of weak data is the only mention of allegedly real ROI for existing companies. In a callout, the report states the following:

Google Cloud customers found an average of 727% return on their investment in Google Cloud AI in three years.

There are two problems with that statement:

1. It’s Google’s internal data. It’s available here, but as with any official company material, this should be treated as a marketing brochure.

2. While I went through the PDF quickly5, it’s clear that it focuses on a broad set of use cases, mostly in marketing and advertising, and on shipping GenAI-related features to end-users. It has nothing to do with using AI as part of the SDLC.

So I decided to simply ignore that data point, which only serves to muddy the water.

#4: Lousy financial model

In case this wasn’t enough, I found another important flaw with the report and, specifically, with the ROI calculation. The underlying financial model is overly simplistic. It is missing one key component, and that’s the concept of Net Present Value (NPV) and Discount Rate.

I am not a finance expert, but it doesn’t take a Nobel Prize in economics to recognise that the value of money decreases over time due to the effects of inflation.

NPV is the standard approach to calculate the future ROI of an investment that takes into account inflation. For that, the concept of discount rate is used, which can be defined as follows:

One of the most important components of the net present value is the discount rate. The discount rate is the interest rate used to calculate the present value of future cash flows.6

The sophisticated ROI model suggested by the DORA folks completely ignores it and simply treats future money as having the exact same value as present money. In case it wasn’t clear, that makes the ROI calculation look significantly better than it actually is.

I don’t know why they decided to not consider it, but its omission in my view undermines the credibility of the whole ROI model, which is in theory the core element of the entire document.

And I won’t even get into the details of the sample scenario provided, as it seems to be clearly designed to make it look good with an impressive 7 months’ payback time. That might be the reason why they omitted the discount rate, as they expect a payback time too short for that to have any meaningful value?

Though, a company that makes $100m in revenues with 500 FTEs in the technical staff alone and ships 50 “features”7 per year might have bigger problems to focus on than AI adoption.

If a CTO needs to spend $5 million in AI to go from 50 to 56 features deployed per year, with a team of 500 engineers, I think they should have a serious employability problem.

Just saying.

Conclusions: A Brochure, not a Report

I’m sad to admit that DORA is no longer what it used to be. Unless this 2026 report becomes the real DORA anomaly and the team gets back on track with serious research with the next issue, I’m afraid 2026 might mark the beginning of the enshittification journey for what used to be a reputable body of research in the software delivery space.

Once you realise the depth of the gap that exists between all previous reports and this most recent brochure, you begin to pay more attention to the small details. Like the many calls to action, inviting leaders to reach out to Google Cloud and engage with their consulting services.

So, while I generally recommend people read articles, books, and reports, this is one of those rare (but increasing) cases where I discourage you to waste any time reading it.

Unless, of course, your main goal is to sell a fragile business case to your CFO and spend even more money engaging with Google’s service than you are doing today.

Reading good books is a great way to broaden your knowledge and perspectives.

Reflecting on the books I read every month helps me cement the key learnings from each one of them.

What’s better than recommending someone else a good book?

Recommending two, three, or five good books!

Here we are with the April edition of the books I read last month!

If you end up reading one of them, please let me know in the comments section.

This month’s highlight is what I'd call an anomaly1.

💫 Book Highlight: Vibe Coding by Gene Kim and Steve Yegge

Vibe Coding, by Gene Kim and Steve Yegge

384 pages, First Published: October 21, 2025

I wanted to make Vibe Coding the highlight of the month because of how bad it is on so many levels.

The arguments are weak, the overly enthusiastic tone is borderline unsufferable, and the style is poor, unengaging—despite the author's desperate attempts at making it fun—and repetitive ad nauseam.

So, why make it a highlight at all? Because both authors are very popular, the book got a lot of coverage and attention, and I believe most people should either stay away from it or read it with their critical thinking circuits pumped up to 100%.

It is clear from the beginning that something is wrong with this book. Despite two “independent” authors writing it, Dario Amodei himself wrote the foreword. I might be biased, but I took that as a clue about what would follow, and my initial intuition proved right.

The book can be summarised with a few bullet points:

• Vibe coding is absolutely great

• If you don't vibe code, you'll be left behind

• Vibe coding is undeniably great

• We the authors and our close friends are having the time of our life vibe coding

• Vibe coding is unquestionably great

• This books is a collection of sparse ideas fed into an LLM which was supposed to write a great book, but it obviously didn't

• Vibe coding is the greatest thing ever happened to us

• AI can make mistakes, and you should not forget all the basic software engineering practices everybody seems to believe are now irrelevant

• Did we mention that vibe coding is awesome?

Not to mention that the book includes some obviously dangerous and deranged statements, such as:

It’s at least an order of magnitude improvement over my career average, and I'm doing it on the side. It's nuts. And that's why I can barely sleep lately. I have too much to do. Everything is achievable now.

I'm completely addicted to this new way of coding, and I'm having the time of my life. [Emphasis is mine]

So this is Steve, who, a few months after publishing the book, went on to write a telling blog post titled The AI Vampire, which I mentioned in detail in a previous article.

While the article tries to adjust the message, the damage in the book is done: Yegge and Kim are presenting something as addictive as if that were something good and positive.

This book could have been a great opportunity for bringing in a balanced view substantiated by studies from independent researchers, but there is basically none of that.

It's all first-hand experience of anecdotes from family and friends, a very homogeneous population that sounds more like an echo chamber than anything close to a statistically representative sample.

Instead of rigor and science, we get this

Unless you still prefer to write code by hand (like a savage), you’re now officially promoted to head chef.

Coding by hand makes you a savage! WTF is wrong with you guys?

Or this

Up until now, using AI has accelerated you. But now your role is to accelerate them.

Wait a second. Are you publicly admitting that GenAI is the perfect example of what Cory Doctorow defines as a 'reverse centaur'2? And you're telling us that's a good thing?!

I would be embarrassed by even saying something like that in a late-night bar conversation.

But that's not even the most embarrassing thing. In the section titled “Substantiating the 10x Claim: Gene's Real-Life Example3”, I read this gem that almost led me to stop reading right away

To make our book the best it could be, we were copying huge chunks of the manuscript into an LLM to do things like hunt for repeated ideas, ensure that every section was novel and new, get opinions on the optimal ordering of the Part 3 practices, and create good signposting (e.g., introductions, conclusions, etc.).

While I respect the transparency of admitting the usage of LLMs to “tune” the content of the book, I wonder if the authors actually read what came out of it with their minds turned on. Because the result is a book that is unsufferably repetitive, and those good signposts are so boring and uninteresting that only an LLM might appreciate reading them. Humans will likely do as I did and gloss over them, as I tend to do the moment my brain recognises a text as being written by LLMs.

The whole reason why I read this book was that after reading some of the seminal books criticising AI, I wanted to read the best that the opposite camp could offer. Now, I genuinely hope there is something better than Vibe Coding, which was recommended to me, so I invite my readers to suggest better books making good arguments in favour of GenAI.

But you know what? I am biased.

When I sat down to write this, I asked myself the question of whether I wasn't being too hard and too damn subjective in my review. That's when a sneaky idea hit me.

Since the book is all about praising the wonders of LLMs as mostly infallible machines, I decided to do something I've never done before: I converted the book to txt, fed it into an LLM4, and asked it a few questions5.

The results were nothing short of hilarious.

Once I got past the initial sycophantic platitudes describing the book as seminal by simply echoing its content without external validation, I asked the LLM specific questions regarding citations, evidence and bias.

That's when things became a lot more interesting.

Here is what came out of the conversation about substantiating the core claims from the book:

And this is what came out when looking at the balance between independence and conflict of interest with the authors

And finally, this is a summary of the problems in pure LLM style:

Now, I'm the last person on this planet who would claim that LLM-generated output is to be taken for absolute truth.

But what came out from that short exchange with Claude is either of the following:

• The LLM is wrong and just regurgitating text influenced by my questions, which undermines that fundamental belief that these tools can produce good-quality work. A belief that sits at the core of the Vibe Coding book.

• The LLM is right, which also means the book is flawed. Maybe not in its core assumptions, but clearly in the way the arguments are built and substantiated as well as the author's credibility.

I'll leave you to choose how to solve this modern time version of the Epimenides paradox6, and move on to the other books I read in April.

📚 Other Books I Read in April

Data As a Product Driver by Xavier Gumara Rigol

Data As a Product Driver, by Xavier Gumara Rigol

368 pages, First Published: March 17, 2026

Let’s start with the necessary disclaimer: I know the author, , as we used to be colleagues a few years ago. He sent me a digital copy of the book, asking for a review, which I of course accepted since it’s on a topic that’s very relevant for both me and the readers of Sudo Make Me a CTO.

It’s an important topic, as I’ve seen many companies struggling with making data a first-class citizen in the complex process of building digital products.

I’ve seen companies throwing money at data in the hope that it’ll magically fix things, with underwhelming results.

I’ve seen CTOs and VPs of engineering treating data as something external or secondary, not realising the importance it can and should play in modern product development.

The book does a good job of exploring both the different aspects of the data landscape and the different maturity stages. It combines concepts from product development, software engineering, data engineering, data science, and data analytics.

It’s a solid first book with a few areas for improvement. And I do have a lot of respect for the amount of time and work required to write something like this.

While I found value in most of the content, I believe the authors could have left out a couple of chapters or developed them better.

Chapter 7 on Operating Empowered Product Teams felt a bit shallow. It’s mainly a collection of “good practices” that have been around for a long time, and I felt it didn’t add anything meaningfully unique.

But my greatest dissatisfaction is Chapter 14.

Until I reached it, I was particularly impressed by how the author focused on the key foundations of data, drawing from years of experience. It felt refreshing, as it stayed away from the GenAI hype… until it didn’t.

Chapter 14 is all about that, and I found it had a different taste than the rest of the book. Almost as if the author took a leap from his own proven experience and embraced a lot of the dominating narrative. This was the only chapter that stroke me with claims such as

This change is inevitable; the tools we already use every day are becoming AI-powered, whether we like it or not.

Which I find fatalistic and not particularly deep, or statements such as

Most companies start with AI at the edge. They add GenAI-powered features to validate user demand, build internal capability, and understand the technology’s limitations. But the real competitive advantage lies in moving AI to the core. [Emphasis is mine]

Without offering substantial arguments as support.

If chapters 1 to 13 sound like a summary of decades of experiences and a lot of trial and error through different realities, chapter 14 rhymes more with the common narrative that is predominant today and mostly based on beliefs, rather than concrete results.

I couldn't help but wonder if the editors at Apress explicitly asked for something about GenAI to be included in the book, but that's just a conjecture I have no way to prove7.

But I know I’m biased on this topic, so it might be an issue with the reader rather than the writer.

That said, I do recommend anyone in a leadership position in product, tech and data to consider reading it, as it provides a helpful overview and strategies on how to increase the impact of any data organisation.

Passion simple by Annie Ernaux

Passion simple, by Annie Ernaux

67 pages, First Published: January 1, 1991

Following last month’s discovery of Annie Enrnaux, I picked up another of her books.

This one is surprisingly short, not even 80 pages long, and tells the story of an unbalanced relationship. It’s between a woman, the protagonist and probably the author herself, and a married man. While she’s fully engaged in it, living each moment of her day in the wait for their next encounter, he seems a lot more detached. Their relationship seems to evolve along with the book, but not really. Not much happens outside the main character's mind, and that’s the interesting part.

It’s an easy book you can read in a single session, or two at most. Clearly not as impactful as La femme gelée, but it is an interesting one to keep cultivating this unconventional author.

Share your recommendations

As I mentioned, Vibe Coding was recommended to me by a friend, , and despite what might sound like an incendiary review, I do not regret reading it, as it actually helped reinforce some of my ideas around the topic.

sent me a copy of his book, which I'm grateful for.

So, if you know of an interesting book I should read, or if you're an author interested in a review, just let me know and I'll make sure to read it and share my thoughts.

See you next month with the selection of May's books!

As a reminder, this is a recurring space trying to decrypt what is going on in the (Gen)AI space once you remove all the hype, vibe reporting and abundant marketing material we are bombarded with.

In each issue I share interesting findings from independent researchers and/or journalists and usually add my own perspective and reading on the facts presented.

All articles in the Something Big Is Happening series1 are for supporting subscribers who have opted in for the paid tier. Thanks to all of them, I’m able to publish most of my content for free. If you like this content and would like to support my work, please consider upgrading to paid.

Now, let’s see what we have in stock for today.

The most enthusiastic reporters and commentators believe that GenAI will solve the main challenges that humanity is facing, and then some. Today we’re going to take a look at how we’re doing on that front

• GenAI's outstanding contribution to solving the climate-crisis

• GenAI's unparalleled contribution to making humans smarter

• Who cares about that? It was all about cutting costs… was it?

So, let’s look at the first promise. Despite Sam Altman's repeated statements on the subject2, things don’t look too well for planet Earth.

Let’s take a look at a reputable source on the topic3.

Hello World, How Are You Doing?

It’s interesting that one of the first pieces I’ve ever written on the topic of AI, about two years ago, was focusing on the immediate and tangible environmental effect this new gold rush was having.

That was about two years ago, and data was still limited. Most of those concerns were being dismissed as only transitory, irrelevant or just necessary in order to reap the upcoming massive benefits. You know, just the same old magical-thinking BS that by investing enough money and resources into this technology (god), it will solve all of humanity’s problems (miracles).

Let’s see how things look almost two years later.

Greenpeace released a recent piece on the currently observable impacts of GenAI. The article covers a lot of ground and dimensions, but specifically on the environmental aspect, it cites a recent study from Greenpeace South East Asia focused on the environmental aspect of AI chipmaking (not even taking training and inference into account).

The findings are staggering:

• Global electricity consumption from AI chipmaking increased by more than 350% year on year, from 218 GWh in 2023 to nearly 984 GWh in 2024.

• Global emissions from electricity consumption related to AI chipmaking increased more than 4-fold in 2024, rising from 99,200 metric tons of CO₂ equivalent in 2023 to 453,600 metric tons of CO₂ equivalent in 2024. The emissions were driven in large part by heavy reliance on fossil fuels in East Asia’s power grids.

• Across East Asia, growth in electricity consumption from chipmaking is being used to justify false climate solutions such as gas and nuclear.

When we move past the production of chips to their actual deployment and usage, things don’t look any better.

A thorough article from last year’s MIT Technology Review reported an interesting finding: the carbon intensity of electricity used by data centres (in the US) is 48% higher than the US average.

In layman's terms, that means that the electricity used by data centres relies significantly more on fossil fuel than the average in the US. So much for contributing to the green transition.

Once you realise that, it’s not surprising that the big tech race to buy carbon offsetting credits has exploded in recent years, leaving some commentators to believe this is a good thing… because it will serve as an incentive for more carbon capturing and offsetting investments.

It’s a bit like saying that smoking cancer-causing tobacco is a good thing for healthcare, as it will create bigger incentives for cancer research and treatments!

The problem with this massive increase in electricity production and carbon emission is that it only makes things worse. By significantly increasing the overall amount of emissions, we’re making it harder to reach what are already close-to-impossible goals for ensuring survival for most people on this planet.

This is basically what most recent reports from big-tech sustainability departments are saying quietly. Decarbonation is a marathon, we’re pragmatically optimist (WTF does that mean?), and we believe that by 2030 everything will be green (without laying out a clear and solid path on how to get there). 2030 is less than 4 years away, and the trend is worrisome.

A recent article from the LA Times does a good job of summarising the situation:

Over roughly the first five years of their climate commitments, for example, Google’s emissions jumped nearly 50%. Amazon’s rose by 33%, Microsoft’s more than 23% and Meta’s more than 60%.

How can we believe any promise that things will suddenly get better in the following 4 years?

Offsetting is not net reduction. Offsetting is just a greenwashing way to make people believe you care about anything but greed.

But hey, humans are intelligent creatures. Our creativity and ingenuity got us this far (is that a good thing?). AI will surely help us continue on the same journey. Or won’t it?

Hello Brain, How Are You Doing?

OK, AI might be contributing to making this world a lot less livable, but at least it will make us humans a lot better. Right?

Not so fast. I’ve been positively surprised to observe a recent resurgence of another AI-related topic I’ve been writing in what looks like it was a long time ago (about a year):

Now, since that provocative but informed article came out, we’ve made a lot of progress in building a more nuanced understanding of the real impacts of AI usage on our cognitive ability. In rapid succession, a bunch of articles have come out recently on this topic.

Read more

Now, security issues can happen to anyone, no matter whether you’re a bootstrapped garage startup, an established corporation, or a hyped AI startup flush with VC cash. We should never, ever cheer, rejoice, or otherwise celebrate such incidents.

First of all, because they’re not necessarily a consequence of misconduct on the company's side. Cybersecurity is hard, and anyone can make mistakes in this space2.

Secondly, and most importantly, because the main victims are always the users whose data, credentials or sometimes money have been compromised.

In other words, such incidents should be taken very seriously, which includes two things

• Treating security researchers with respect3.

• Treating users with respect, which means taking care of their data with a high degree of urgency, and being transparent in communications with them.

That’s why I’m interested in the Lovable case.

Not because through the security incident Lovable went all the way to Lovableed4.

But because due to the way they handled the issue, they went from Lovableed straight to Lovabad.

And for those of you who need context, this is what happened.

A chronology of the events

I’ve consulted a few sources to get a sense of the sequence of events. The ones I recommend, if you want to get into the details, are the following:

• This article from The Register

• This article from Cybernews

• This article from Cyberpress

This is a short summary of what happened

• Until May 2025, free-tier users could only create public projects. What that meant was that both code and chat history for those projects would be publicly accessible to any other user.

• In May 2025 Lovable allowed free-tier users to make private projects while at the same time turning off the possibility for enterprise customers to create any public project. Public was still the default for private users.

• Projects remained private by default until December 2025. At the same time, Lovable supposedly patched their systems so that chats for public projects wouldn’t be accessible to external users.

• In February, a change in Lovable’s backend code restored the possibility to access chats, too.

• This regression was first reported on March 3rd, and Lovable patched the issue for new projects. But they did not patch it for existing projects

• On April 20th a security researcher who goes by the handle @weezerOSINT reported the issue on twitter after seeing their report closed as duplicate

What happened next is a perfect example of how not to handle a security incident as a tech company.

From Lovableed to Lovabad

Lovable first reaction?

Deny the claims!

The public statement is quite clear:

To be clear: We did not suffer a data breach.

And then they go on with a fuzzy and only mildly apologetic explanation about how the issue was… the documentation!

The real problem with that: it wasn’t true. The vulnerability and the leak were real, and they seemed to have dismissed the report without even taking the time to check whether it was substantiated or not.

One might wonder if over-exposure to AI slop made Lovable's employees treat anything they read online as hallucination and false. That would at least explain something.

A few hours later, however, someone seemed to realise they had completely messed up their reading of the situation, and Lovable published a clarifying statement.

Which, I can only guess, was supposed to serve as an apology and clarification.

Once you're done laughing, please read on, as there are two main things I would like to point out from the embarrasing statement.

When you create a project on GitHub, you can make it private or public. Lovable worked the same. Users had a “Public” or “Private” option right in the chatbox. A public project meant the entire project was public, both chat and code. “Just like a public project on GitHub,” we thought.

That’s naive and borderline criminal.

Treating the chat at the same level as the code means these folks either have no idea about how users use chatbots or the amount of crazy sensitive and personal details shared in there. Either that, or they’re just acting in bad faith. Yes, this is a perfect example of Hanlon’s razor, and I tend to believe its default conclusion: incompetence.

I would only accept that as an excuse if it was clearly stated, 'We have no idea what we're doing, and you shouldn't trust us with your data.’

But that wasn't the case here, so excuse not accepted.

But the incompetence doesn't seem to stop here, as the statement continues with

This was reported through our vulnerability disclosure program (via HackerOne). Unfortunately, the reports were closed without escalation because our HackerOne partners thought that seeing public projects’ chats was the intended behaviour.

So this is HackerOne’s fault… except that it wasn’t them who published a public statement denying the claims from the researcher.

Even if it was genuinely HackerOne’s fault, which I seriously question, I would have expected two things from Lovable.

• That they would have taken the blame, as this is about their users, rather than finger-pointing a vendor.

• That they would have checked thoroughly the nature of the researcher’s report before publicly denying it.

They did none of the two. Instead, the best they were able to come up with to take accountability for the embarrassing display of incompetence and arrogance, is the following:

We understand that pointing to documentation issues alone was not enough here. We’ll do better.

We’ll do better?

Seriously?

We don’t accept such hollow promises from our five-year-old kids, as we know they’re meaningless without a clear plan and detailed list of what exactly they’ll be doing differently next time.

It would be so easy to do better than that.

It would have been enough to say something along these lines

Dear users and customers, we screwed up.

Not only we demonstrated a profound lack of understanding of security and privacy in our initial design of the public projects.

Not only we reintroduced the issue after fixing it, most likely because someone accepted a vibe-coded patch without understanding its full implications.

We even denied the claims from a well-meaning researcher without taking the time to review them thoroughly as they would have deserved.

All the hype, attention and celebrity go to our head, and we lost sight of humbleness. Hubris led us to not take security seriously, and assume we’d be always right.

This realization has prompted a serious discussion internally and as a consequence we’re going to review our entire security posture, from internal controls to how we deal with the cybersecurity community at large.

We apologise to our users, and commit to sharing transparent and detailed updates on our way to improve security at least once per quarter.

There, you have it.

It just needs to be genuine, honest and credible5.

Your customers will respect you a lot more if you take accountability.

They will trust you with their data more if you’re transparent about your shortcomings.

They might even stay with you instead of leaving for one of the gazillions of existing competitors if you transparently shared your detailed plans for making real and concrete improvement.

In a time of excessive focus on “Intelligence”, a little bit of self-reflection6 and caring about your users and prioritising both above your ego can go a long way in making you stand out from the pack.

Especially when your brand relates to emotions.

Will Lovabad turn into Lovaback?

The ball is in their camp.

• Understanding what a due diligence is

• The common terminology

• Understanding the underlying investment thesis

• How to approach different types of investments

If you missed it, shame on you, but nothing is lost.

You can catch up with a simple click.

Given the success of that first article1, I decided to follow up with some more details on how to actually conduct a tech due diligence. What should you do once you have clarity on the investment thesis, and what is included in the scope?

Before we move on with the details, I have an important reminder for you.

Tomorrow, April 16th, at 5pm CEST, I'll hold an open session for the Sudo Make Me a CTO community. It’s an hour-long free session open to anyone who would like to see what the community looks like on the inside. There is already a good group of people who signed up for the event, but there is still room. Don't miss this opportunity to help accelerate your growth as a leader and as a person in these changing times. Claim your spot via this button.

Claim Your Seat!

Now, let’s go back behind the curtains of the Dark Data Room.

A quick recap

Before you go out and waste precious tokens2, let me remind you what is going on here.

• Your company has started a process3 to potentially acquire another company.

• Someone, most likely the CEO, tricked you into signing an NDA.

• After signing it, you’ve been let in the small circle of people who know that what everyone is referring to as Arrakis is not a sci-fi guild but the codename for the potential acquisition project. Quite a big downer for the nerd you are4.

• To add insult to injury, you have been gifted with the responsibility of conducting the technical aspect of the DD process, i.e., you share a non-trivial part of responsibility for deciding whether to proceed with the deal. And a massive liability exists to ensure the integration is successful, should the deal be closed.

• Given that, according to the draconian terms in the NDA you signed, you’re not allowed to talk about the Arrakis project with anyone, not even your partner or kids, you frantically read the first article I published on the subject.

• You’re left wondering how exactly you’re supposed to handle it, and while you might have been cursing me for omitting those aspects from the original article, you’re holding your hope that this one will give you the keys to the realm.

I’m sorry to disappoint you: those keys don’t exist. The realm doesn’t exist either. In fact, tt’s not a realm. It’s a hostile land, full of predators, legal traps, and deadly obstacles. But there’s no need to abandon all hope as you're entering the Data Room.

Dante managed to go through the Inferno without a map, relying on his own mind, heart, and the caring oversight of his guide Virgilio.

Likewise, with some guidance I’m sure you’ll find a way out of the tar pit and will be able to confidently assess whether your company should make the investment and what that will represent for you and your team in terms of integration pains.

So, let’s get on with the journey. I’m sure you’ll enjoy it5.

The first steps

The first steps might feel daunting, but in reality they’re the easiest ones. You might feel you don’t know where to start, and you’re probably right. The good news: it doesn’t matter where you start. Just start somewhere. Pick one thread, be it organisational setup, technical stack, processes, metrics, or whatever. Eventually you’ll want to cover all those aspects (in more or less detail depending on the investment thesis), so don’t sweat it too much about the exact first step. Motion is more important than direction as a way to get started.

Now, chances are you’ll be asked to put together a series of requests or demands to be submitted to the target company. This is often called the Initial Request List, or IRL6.

You might want to do online research for more details on how to craft a perfect IRL7, but ultimately this boils down to a list of documents you’ll request from the seller/selling company. The main keyword here is initial, as this won’t be your last chance at requesting additional information. Otherwise it would be called something like Unique Request List, or Your Last Chance at Not Forgetting Anything You’ll Regret Forever, aka YLCNFAYRF.

You will have plenty of opportunities to discuss the content of the documents and request additional or complementary information as you make progress. Therefore do your best job but definitely do not aim for perfection, as that will likely slow down the whole process.

For a tech DD, a good IRL should include requests covering the following aspects:

• Organisational Setup The bare minimum should be the org chart clarifying reporting lines and team allocation. On top of that it’s a good practice to request information about roles and responsibilities across teams, breakdown of seniority levels and tenure, and interactions or interdependencies with other functions. Particularly with Product, Marketing, Operations and Sales.

• Technology Stack This is the most obvious part, I suppose. You want to get details about the infrastructure setup (cloud, on-prem, etc.), the high-level architecture, frameworks and languages used across the whole stack, a full inventory of owned platforms (websites, mobile apps, etc.), and so on and so forth. Later on you’ll want to get a sense of where the main sources of pain or inefficiency are, but in the IRL it’s enough to get a full map of the landscape you’re looking at. Chances are that your intuition and experience will tell you already where to investigate further, such as that old PHP framework or that Cassandra instance running in a closet.

• Processes It’s helpful to get a detailed sense of how software implementations are born and come to live. From the way the company sets priorities and goals to how they trickle down to product prioritisation and then how they go from idea to plan to code written to code running live in production. You will typically include questions covering different aspects of the end-to-end process, such as:

  • How are priorities set and who decides them?

  • What’s the journey of a project from a ticket to being live in production? Who are the people involved at each step of the process?

  • How do you integrate technical improvements with product improvements?

  I like to ask fairly open questions here, as the depth and quality of the answer are in themselves data points. I’ll get back to it in the next point.

• Operational Metrics Here, you want to really get a sense of two things. The first one is whether the team has a culture of using metrics as first-class citizens in the way they operate. The second one is to get a sense of what these metrics look like. That’s why I’m generally vague on the request and prefer very open questions such as:

  • Please provide the full set of key metrics used in the engineering department to measure impact of initiatives, quality of service and team’s effectiveness

  Rather than something very specific, such as uptime, DORA metrics and % of code written by AI8. The list of metrics and the way they are presented is a precious data point in and of itself. It tells you a lot about the maturity of the team. If all you get back is “this is our uptime, and this is our average velocity”, it will be a hint to dig deeper into engineering maturity later on9.

• Cybersecurity Here too your first need is to develop a sense of the maturity around the topic, rather than having a detailed list of all the open vulnerabilities. Ask the counterparty to provide details about the framework(s) they use to govern cybersecurity topics, the reports from their most recent audits/penetration tests, and a list of activities they’ve undertaken in the past 6-12 months in the space. You’re looking for signals that the company is taking the topic seriously and that the team is equipped to deal with it. And, of course, you want to know if you’re looking at a ticking time bomb, as that would be a clear red flag for the acquisition in most cases10.

• Costs This is another area where you want to get information at two levels. One is, obviously, how much money the technology organisation costs overall. You want to get all the costs, from salaries to licences, third parties, cloud bills, etc. Ideally broken down to a granular level. And the second signal you’re aiming for is regarding the maturity of the organisation when dealing with costs and FinOps-related activities: do they have clarity? Are they allocating costs in a way that makes sense? Are they generally on top of their spending? This is another case where asking them to provide budgets, forecasts and actuals as they’re using them in their day-to-day job is the best initial approach.

• Dependencies This aspect can vary significantly whether you’re looking at a standalone company or a subsidiary of a bigger group. In the former case, you’ll map out dependencies mainly in terms of third-party vendors offering services at various levels across the organisation: enterprise systems, third-party platforms, etc. But when the company is part of a bigger group, you’ll need to get a full map of all the internal dependencies: systems and services provided by the parent company that you’ll need to disconnect from and replace with alternative solutions if the deal is closed. In this second case, this becomes a critical area, as a big part of the effort to carve out the target company and integrate it with your systems will have to do with cutting ties with all these dependencies11.

• Plans Last but not least, it’s important to get a sense of the biggest items the team has planned to work on in the upcoming six to twelve months. At this point you shouldn’t be surprised that this exercise too will provide signals on two levels. The obvious part is getting a sense of some of the work the team is already committed to doing, which will occupy significant resources during the months following the acquisition. Secondly, this view will provide insights into the team’s ability to plan for future investments, the rationale, and the overall roadmapping and planning process.

While you can always add more, I recommend finding a balance between being comprehensive and quickly initiating the process. Getting the data back from the selling company will take time, and the longer your initial list, the longer the waiting period before you start getting something to look at.

Now that you’re waiting for them to produce all the required documentation, you can start preparing for the next step.

The Middle-earth

If you thought coming up with the perfect IRL was hard, I have bad news for you: that was the easiest step. After all, you just had to come up with some well-thought-through questions. What happens after that, in Middle-earth, is what I consider the hardest part of the whole process.

Soon12 after you’ve submitted the IRL, documents will start appearing in the Data Room. They will generally appear in sparse order, they’ll be often largely incomplete and will have a tendency to magically appear in batches on Friday afternoons. But that’s not the worst part of it.

The worst part is that as soon as you start digging into the documentation, you’ll observe a Cambrian explosion of new questions in your mind. That, and if you’re particularly unlucky, you’ll witness a significant increase in your average rate of WTF per minute13.

So, what are you supposed to do now? In essence, all you need to do is to make sense of the information you’re collecting and dive deeper in areas that feel unclear, challenging, messy or all of them at the same time.

This phase is messy and hard to distil in a series of steps. It often reminds me of the famous “How to Draw an Owl” meme

You’re somewhere in between those two steps, when stuff has to happen.

Even though there isn’t a ready-made recipe for this stage, some methodology can go a long way in helping you navigate it. These are a set of activities and approaches I recommend for survival.

• Distil the information into your own notes. Write down your observations, summarise and reprocess what you’re receiving. This will ensure you have a deeper understanding of the material14, and it will uncover gaps in understanding or in the data, which you’ll then promptly review with the target company.

• Collect all your questions and submit them to the selling party. Data Room software has support for submitting specific questions. Don’t be shy and use that. Ask all the questions needed for you to really understand the material. Make sure you prioritise them, especially in the initial phase when you’ll probably have a tonne of them.

• Organise deep dive sessions in which you’ll explore specific areas with the experts from the counterparty. As you process the material, some elements will emerge as worthy of your attention: complicated dependencies, team issues or areas of accumulated technical debts. These are good candidates for setting up dedicated deep-dive sessions aimed at providing a lot more details and nuance around them. Unless the process is in a rush, you should be OK with having multiple sessions as long as they provide clarity in murky areas.

• Start drafting your conclusions early on. Don’t wait until the end, but start very early in drafting your recommendation. Do not focus on the form; instead, take your notes and observations from the deep dive sessions and start organising them into categories. You can start with a simple traffic light system, making an inventory of each topic and indicating whether it’s in a green, yellow, or red state.

At some point you’ll either run out of time or questions to ask, and that’s a good moment to move into the final phase of the DD process.

Putting it all together

If you manage to come out alive from Middle-earth, I’m happy to confirm you’ve survived the hardest step of the DD process. Now you’re supposed to formalise all your findings in a final document, including your analysis and recommendation.

Different companies have different norms and standards for producing this closing document, but it will essentially include the following three elements.

Your Recommendation

The document will generally start with a synthetic appreciation from your side as to whether you recommend or discourage moving ahead with the deal. Generally speaking, lack of major red flags on the technology side will mean you’re not seeing reasons to oppose the deal. Conversely, if you found out that the company stores all passwords in clear text, has not upgraded a library in a decade, and the CTO tends to engage in pair programming while high on Adderall or ketamine15, your conclusion might be a clear and firm objection to the deal moving forward. Whether or not your opinion will be taken into consideration will depend on how much appetite there is for the deal in business terms, but at least you will have done your part.

After the opening recommendation, your document will usually include a detailed analysis.

Detailed Analysis

This is where you’ll provide an overview of your observations on the different dimensions you have evaluated: technical stack, organisation, processes, etc.

You can reuse your traffic light assessments from the working notes to group them by criticality areas or use thematic grouping. This part will serve as the rationale for the overall recommendation you put in the opening. Be detailed, as those details will become handy for you and your team when you’ll eventually proceed with the integration.

The last part is where you’ll see the most variance depending on the company you’re in and how the overall DD process has been set up. Regardless of the level of detail, you’ll be asked to include some information about how you’re planning to integrate the new acquisition into your company’s ecosystem.

High-Level Integration Plan

The level of detail here will vary significantly from company to company.

The bare minimum is to provide a directional indication of which systems will be kept as they are, which systems will be dropped, and which ones will require complete integration work to merge them with the existing systems in your company.

Depending on your context, this high-level classification might suffice, or you will be required to also provide more detailed effort and cost estimates. In some cases you’ll be required to estimate synergies too, i.e., cost savings that can be captured by deduplicating systems or teams16. If you have a choice, try not to err on the side of too many details, as, no matter how thorough your DD work has been, this is a stage in which you still have very limited context and data. Chances are most of the people who will be involved in doing the work do not know about the deal yet, meaning their perspectives and knowledge have not found their way into the plan yet.

A good idea is to give high-level coarse estimates and reserve the right to come up with detailed plans once the deal is closed, involving the relevant people from your team.

What’s next?

Unless further iterations are required, you’re probably done with the bulk of the DD work. But that doesn’t mean you’re done with preparing the deal and the transition. If, at the outset of the DD process, the transaction is aborted, then yes, you’re done, and you can go back to your normal life.

In the case where the deal is confirmed, then a new set of activities awaits you. But you must be tired now of all the efforts drawing that owl.

We’ll discuss the following steps in an upcoming article.

In the meantime, don’t forget that the April issue of Something Big Is Happening is coming out soon. If you don’t want to miss it, make sure to upgrade to the paid plan.

It helps immensely in securing my time for writing all the free content too.

A common theme I’ve heard from people I work with or simply exchange with is that they either have or have to manage unreasonable expectations regarding the impacts of AI on the productivity of digital companies.

In today’s article I’d like to share a few simple tips to handle such situations.

But before we go there, there is an important announcement!

This article is sponsored by Rushomon! Wait, what? Isn’t that the thing I built myself?

Well, yes. So, technically this is not a sponsor. Or rather, not yet. But it might become if more people start using it.

There has been some interesting traction lately, including:

• The first attempts to use Rushomon’s short links to obfuscate links used in phishing attempts (multiple cases). I guess this is the ultimate sign of being legit!

• Bug reports and some very cool contributions to the open source project from people who are actively using it in its self-hosted version. Another indicator that it’s covering real needs.

On the enthusiasm that followed these events, I’ve opened up the first paid tier, which essentially gives higher limits and fancier features, but more importantly, I’ve decided to try a Product Hunt launch.

It’s the absolute first time I've done it. I probably screwed up a few things, but if you’d be so nice as to show some love, I’d be forever grateful!

But please, only do so if you genuinely believe Rushomon is a cool product.

Just go here and share your appreciation.

Share Your Appreciation

Now, back to the topic of managing unreasonable expectations.

The frustration of a CEO

I recently had the pleasure of reconnecting with a former client, a CEO, who reached out a few weeks back, as they intend to re-engage with my services. Besides making me very happy that they would be a returning client in a business model with close to zero vendor lock-in1, I found our recent conversation extremely interesting and revealing.

You can, of course, imagine that if a CEO reaches out asking for my help, that’s a sign that they might be struggling with something and need support. They usually do not reach out when everything is going great.

This case wasn’t an exception, and the CEO shared with me a few issues they’d like me to help them solve. Most of them were common ones, and one stood out particularly.

They said they were frustrated because they weren’t getting the productivity improvements from the adoption of AI they’d expected.

When something doesn’t meet expectations, you should always start by understanding where those expectations are coming from. That’s what I did, using my usual dose of “What do you mean?” or “Can you provide explicit examples?” types of surprisingly effective questions.

It turned out to be anecdotical evidence of the simplest form.

They were comparing what their established team of dozens of engineers organised across multiple teams, building and maintaining a mature product with a reasonable amount of legacy, with a greenfield startup of two software engineers.

Their frustration was literally “I am approached by startups of two engineers who can build in two days what it’ll take us two months to achieve with a much bigger team2”.

Raise your hands if this sounds all too familiar 🙋.

To help them reassess their expectations, I used three categories of arguments.

Look at things in their context

There is a cult scene in a popular Italian movie from the late nineties that has become a surprisingly effective tool for describing what is going on in the tech space. The movie is called Tre uomini e una gamba (Three Men and a Leg), and this is the epic moment:

You can turn on automated captions to get a sense of what’s going on there.

In essence, Giovanni, the guy on the left, is comparing the work of a conceptual artist with what a carpenter could produce for pennies. Even though the two objects, an artistic reproduction of a leg and a functional one, could look very similar from the outside, they’re profoundly different in their essence.

Comparing the two is the woodworking version of comparing apples and oranges.

It goes the same for companies.

Comparing an established company with hundreds of employees and a newborn greenfield startup with a handful of people can be extremely misleading. Especially if, like in this case, you wish to attribute the difference in results to a single cause, such as a perceived sub-optimal adoption of AI tools.

I’ve heard the same narrow comparisons made through different generations of silver bullets: tech stacks, mobile apps, cloud computing, and now AI. The problem with these biased and narrow observations is that they tend to distract the observer from developing a holistic and more nuanced understanding of the situation. Saying “we’re not good enough with technology X” is much simpler (simplistic) to understand and communicate than, say, having to spend months analysing different variables, running controlled experiments and then using the results to determine what to do next. That doesn’t fit well on a single slide.

The lessons learned from decades of technical evolutions that we seem to have forgotten with the advent of generative AI are that you can’t extrapolate laws or rules from anecdotal evidence. You can’t and should not generalise the experience of solo builders or small teams.

That’s difficult, because the public discourse seems to be dominated by those voices, but it’s not impossible.

It’s a matter of investing time to learn more about the subject beyond what’s served by algorithmically curated feeds or fellow tech bros who’re constantly trying to impress you or potential investors.

Use real data to counter predictions and magical thinking

Timing was on my side as that conversation happened just days after I read an interesting study from the folks over at GetDX, which I mentioned in a recent article

The study reported that they found a 10% increment of PR throughput across all their clients between 2024 and 2026. That’s remarkable, but it is far from the 10x or even 2x improvements that many are proclaiming.

That study isn’t by any means final and should not in and of itself discourage anyone from experimenting and trying to get better.

But if I had to set a reference point for expected improvements in my team, I’d rather use the most recent results for such independent studies, however incomplete they might be, than the self-reported anecdotal experience of someone I met at a conference.

I’ve encountered a staggering amount of magical thinking in the tech narrative in the past few years, to a level that I’ve only seen in the crypto niche previously. Except that now it’s everywhere. We tend to conflate it with being visionary, but in fact it’s more akin to religion than science.

From the most innocent assumptions of speed of development, i.e., the frequently mentioned “if the technology keeps evolving exponentially as it’s doing”, which tends to ignore the laws of physics and all prior evidence3, to the mischievous and irresponsible claims that “AI will eventually reach a level of perfection that will solve humanity’s biggest problems", such as the climate crisis, cancer, or war. Ignoring that as of today it’s only contributing to making all those problems worse4.

Or, my favourites, all the claims that all turn around the idea that “the technology will only get better from here”, which tend to forget that technology products, especially when they become monopolies, tend to get worse, not better, for the end users. Regardless of the improvements in the underlying technology itself5.

In fact, whenever someone suggests you have to believe in something, turn the critical thinking knob up to 116, as that’s a common sign of irrational thinking.

But the most important message here is that when facing bold claims and marketing pitches, you should look for data and evidence rather than accepting them at face value.

And no, do not ask a chatbot to find the data for you.

In particular, you should start by putting in the thought and defining what success means for you and your company.

Focus on the business, not the technology

There is something I’ve been repeating for months, and I won’t stop until I see the evidence, i.e., the money.

For decades we’ve been repeating to CTOs and other tech leaders that they should get out of their technology bubble and think about the business first. That technical decisions only matter when they’re clearly in the service of their specific business. That they are business leaders that happen to use technology to help develop it. I personally agree with this view, as technology should always be a clear means to an end. Otherwise, it can turn into expensive leisure7.

Yet, for the past three years and counting, I’ve seen countless CEOs do exactly the opposite. The only thing they seem to be able to talk about is AI, how to become AI-native, and how with AI, as if it’s some magic wand they only have access to, they’ll beat the competition.

If you really hate yourself, just spend some time looking at CEOs' posts on LinkedIn from the past couple of years to get a sample. Surely, in many such brilliant minds, they think that AI will help them reduce costs and, therefore, improve margins. But they seem to have forgotten that the ultimate goal is to solve people’s and users' problems. That part seems to have completely disappeared from the dominant discussion around digital products. They’re all so excited about the new self-driving sledgehammer they have at their disposal that they’ve forgotten that their users might just need to swap their wallpaper.

This moment is in fact a great opportunity for mindful leaders.

If they take the time to really look at the available data, understand their user needs and come up with meticulously defined success metrics for their company, they might find ways where AI might help and plenty of other areas where different solutions will have a more effective and/or efficient result.

Throwing money at a problem has never been a guarantee of success. Throwing tokens at it might not be either.

And the burden of proof is still on the side of those who claim otherwise.

People Have Spoken!

I hope you find these three categories of tools helpful to manage what have become increasingly unreasonable expectations from a large portion of the industry leaders.

In the last article I shared a poll to help me decide on the name for the upcoming regular columns for paid users.

People have spoken, and though I’m surprised by the incredibly small number of people who voted over the total number of views/reads of the article, I’ll go ahead and confirm that the column will be titled “Something Big is Happening”.

The April issue will be #1, because we’re nerds and we start counting at 0. And issue 0 came out a couple of weeks back:

I have still to decide whether the new column will come out on a fixed weekday / date or if it’ll be less regular than the standard issues, but I’ll figure that out on the go.

In the meantime, stay tuned for the upcoming #1 issue, which you won’t find anywhere else.

To make sure you don’t miss it, you should seriously consider upgrading to pay right now.

Just look at the CTA button below you’ve been ignoring for too long!

Thanks in advance!

Reading good books is a great way to broaden your knowledge and perspectives.

Reflecting on the books I read every month helps me cement the key learnings from each one of them.

What's better than recommending someone else a good book?

Recommending two, three, or five good books!

Here we are with the March edition of the books I read last month!

If you end up reading one of them, please let me know in the comments section.

Before we get into the meat of the books list, I need your input on something of vital importance.

I’ve got quite a lot of positive signals around the idea of doing more articles similar to the one from last week:

I’m going to experiment with introducing it as a semi-regular column only for paid subscribers, which will be published in addition to, not instead of, the current free issues.

I need your help to decide on the name for the regular columns.

Please vote or add your suggestion in the comments.

The poll will be live for one week; please cast your votes!

Thanks for casting your vote, and now, onto the books I read in March.

💫 Book Highlight: A Brief History of Intelligence by Max S. Bennett

A Brief History of Intelligence, by Max S. Bennet

432 pages, First Published: October 24, 2023

Even if a book has a subtitle that sounds suspiciously enthusiastic about something controversial, such as Why the Evolution of the Brain Holds the Key to the Future of AI as is the case for this book, if it’s blurbed by Daniel Kahneman, it’s a sign I take seriously that I need to read it1.

The book is a lot more about the evolution of the human brain and the evolution of our understanding of its inner workings than it is about AI. Furthermore, it’s really about the evolution of AI as a whole discipline, not narrowly focused on the past 7 years since the introduction of Transformers that led to large language models.

Something I particularly liked is that Bennet does a good job at mentioning the limitations of LLMs, talking about how they only cover one key aspect of human intelligence, language, while lacking any mechanism to implement what’s generally referred to as a model of the world. Something that appears to be key in explaining human intelligence.

I found the last paragraph in the whole book particularly intriguing in expressing this view

In the human brain, language is the window to our inner simulation2. Language is the interface to our mental worlf. And language is built on the foundation of our ability to model and reason about the minds od others—to infer what they mean and figure out exactly which words will produce the desired simulation in their minds. I think most would agree that the humanlike artificial intelligence we will one day create will not be LLMs; language models will be merely a window to something richer that lies beneath.

Bennet did a great job at clarifying what are facts that we know about today on how intelligence works and what are just hypotheses and theories, still unconfirmed and highly debated.

I found the part about catastrophic forgetting in AI models, where learning new concepts or abilities often leads them to forget other important ones. The animal brain, and the human brain above all else, has been able to continuously and linearly learn new skills while not forgetting old ones, at least not systematically.

This is just one of many unsolved challenges on the way to whatever will look like real intelligence in machines, and Bennet sums it up perfectly in this passage.

How do modern AI systems overcome this problem? Well, they don’t yet. Programmers merely avoid the problem by freezing their AI systems after they are trined. We don’t let AI systems learn things sequentially; they learn things all at once and then stop learning.

This is not to say AI systems won’t ever be able to do this, but as of today we have little to no idea about how that might happen. Yet, as the book shows with plenty of specific examples, many breakthroughs in ML and AI have come from trying to reproduce our understanding of how the human brain works. But sometimes even some of the best advancements are barely scratching the surface of how the brain really works:

Despite being inspired by the brain, convolutional neural networks (CNNs) are, in fact, a poor approximation of how brains recognise visual patterns.

My main takeaway from this book is that though we do know a lot about how the human brain works, there are still plenty of things we don’t. Neuroscience is a key discipline, and research in this space, including in AI systems to mimic how the brain works, should continue, as it carries huge potential for humanity.

That also means we must stay humble and avoid the hubris of recent advancements fooling us into believing that true artificial intelligence is just around the corner.

Overall, this is an impressively dense yet accessible book on one of the most mysterious and fascinating aspects of what makes us humans: intelligence.

There are a few additional details besides the actual content that make it an amazing achievement for Bennet.

The first one is that this is his first book. And it is wonderfully well written, complete and engaging while being thorough, nerdy and fun. A work in which the passion of the author is palpable, yet it does not fall into sensationalism, overly enthusiastic predictions or promises. Bennet clearly believes that one day we'll achieve a human-like level of artificial intelligence, but he's very cautious at not resorting to salient predictions about how quickly we'll get there.

The second one is that Bennet is not a neuroscientist by education or trade3. He studied maths and economics, but he clearly has a passion for neuroscience and has been working in the AI field for his entire career. Not a complete stranger to the topic, but the level of depth he reached in his book is proof of an admirable ability to go deep on a topic driven by pure interest. A clear example of what Cal Newport defines as being so good you can’t be ignored, I guess.

I believe Max Bennet is quite busy with his life as an entrepreneur, but I’d be curious to read more from him if he ever wrote another book.

📚 Other Books I Read in March

The Tipping Point by Malcolm Gladwell

The Tipping Point, by Malcolm Gladwell

301 pages, First Published: Marc 1, 2000

This is the second book I've ever read from Gladwell. The first one was Blink, and it was ages ago. I got this second-hand copy from an online reseller I’d like to partner with4. The Tipping Point is both an interesting and easy read. I like how it sounds a bit “old” as it’s been published in 2000: all examples are from the pre-ubiquitous-internet and pre-smartphone eras. A time when the offline, physical world was the centre of attention and the dominant place of interaction for most people.

The core idea of the book is to try and illustrate the mechanism through which trends, diseases, or general phenomena that go through phases of massive expansion germinate, spread quickly, and then fade out.

Of all the examples, I found the one about the crime rate in New York City and the correlations with the degradation of the subway system intriguing. I even mentioned them in a previous article.

Or the interesting correlation and causality effects between teenager coolness and their tendency to smoke.

But that’s pretty much it. The Tipping Point, in my experience, is the kind of book that leaves you with a disappointing “so what?” unanswered question at the end.

It’s interesting, original, and arguably well written.

Yet, I struggle to understand why it encountered such enormous success when it came out.

I don’t regret reading it, but I’m not sure it’s a book I’d recommend.

Surely not as much as the next one.

La femme gelée by Annie Ernaux

La femme gelée, by Annie Ernaux

182 pages, First Published: February 12, 1981

Annie Ernaux won the Nobel Prize for Literature in 2022, and after reading La femme gelée it became clear why.

It’s the first book I read from her, but clearly not the last one. I must credit and thank my wife for making me discover this amazing author.

La femme gelée might as well be the most subtle yet brutal feminist book ever written. The most profound and poignant piece of literature highlighting the reality of inequalities between men and women in the Western world.

It does all this without ever mentioning the word ‘feminism,’ or engaging with lengthy political dissertations. No. It does that in the simplest, yet most powerful, way: by telling a story. Her story. The story of a young woman who grew up in a family in which the roles in the couple were so distant from the dominating stereotypes as to be almost embarrassing. The story of how despite that odd cultural frame of reference, she ended up following the traditional path. How she had to sacrifice her dreams, desires and ambitions in service of her new family: her husband first, and then her two kids.

Annie Ernaux achieves all that in a relatively short book, with an absolutely unique style. Her writing doesn’t follow traditional and familiar structures. It’s a mix of a stream of consciousness and jazz. She can explore her thoughts for multiple pages in a row without an evident discontinuity, or she can jump from one thought to a dialogue to the description of an event in the space of just a few sentences or words.

Transitions are sometimes smooth, but they’re often abrupt.

There is a certain brutality in her style too. She doesn’t filter the reality she’s describing, be it her internal world or what’s happening outside of here. What makes it even more brutal is that she doesn’t even need to use excessive emphasis or troubling images: just the reality of her condition, the way she lives it. Day in and day out.

She’s not talking about violence. She’s not talking about oppression. She’s not talking about poverty, the struggle to make ends meet. She’s the wife of a perfectly normal middle-class young family. A husband with a good job. Two kids. A nice house. She’s almost the perfect archetype of a tradwife, an idea that a certain part of American conservatives have been promoting as something to aspire to.

But she calls it “the frozen woman”. As all her desires, wishes and ambitions have been frozen and replaced with this image that someone else has chosen for her. The image of the woman whose role is reduced to servicing her husband and kids.

A wonderful book. One that makes you think deeply and reconsider a lot of your biases and actions.

I already have a couple more books from Annie Ernaux piled on my bedside table, and I’m both eager and hesitant to read them. I’m eager, because this is just great literature. And hesitant, because they force you to confront certain aspects of the life you’re living under in a new light.

And what you discover isn’t always pleasant.

See you soon!

As a reminder for all my readers, on April 16th at 5PM CET, I’ll host a free open session of the Sudo Make Me a CTO Community. It will be like one of the regular sessions reserved for members of the community, except that it will be open to anyone for attendance.

Many of my readers have signed up already and submitted interesting topics to be covered during the session.

One that we'll focus on is something many leaders are struggling with: managing the often unreasonable expectations for productivity improvements through AI-assisted coding across many C-levels.

I'm looking forward to having that conversation with many of my readers.

If you’re interested, sign up here and you’ll receive an invite shortly after.

See you on the 16th!

And if you like these articles, please remember to subscribe or upgrade to paid!

Today I’m going to experiment with a much shorter article than usual.

I love to write long-form pieces, but I also know many people out there have lost the ability to read more than 280 characters in a single session. But I’m Italian and Latin, which means I tend to be verbose due to my cultural upbringing.

For once I’ve decided that I’ll spare you the task of submitting the article to a token machine1, I’ll force myself to be concise.

But before we do that, let’s briefly hear about a great opportunity :)

Let’s start with a recent study that came out that didn’t get the attention I believe it deserved.

📉 Interesting longitudinal Study

The most important thing about the study is that it comes from a company that has close ties with Microsoft/GitHub and has notably been in the booster/enthusiastic camp of AI-assisted software engineering: DX.

DX has long been a reference in the DevEx space, with some of its founders having contributed directly to the SPACE and DevEx frameworks for developer productivity. I always appreciated that. But, like many other companies in the big tech space, they have been significantly riding the wave of LLMs sprinkled everywhere2 and deliberately evolved their tools to both take advantage and help other companies take advantage of the ongoing revolution.

So I was delighted when published the article titled AI productivity gains are 10%, not 10x.

Though it shares only preliminary results, what it shares is interesting, and so far it is the only longitudinal study trying to come up with some objective measurements of productivity improvements. Obviously, no study is conclusive. Just remember that they tend to be more conclusive than anecdotal and subjective opinions.

Even if their measure of productivity, PR throughput, is questionable as it’s just a proxy for real productivity, the fact that it shows an impact of about 10% is remarkably low compared to the expectations we've been primed to expect through large-scale pavlovian conditioning3.

I found most comments on the article so hilarious that I did something I rarely do: I posted a comment and follow-up note expressing my sentiment at those reactions.

I’m hoping that DX will soon release more data and publish a full-blown paper on the subject.

Meanwhile, we can look at other signs of historically enthusiastic supporters starting to come to terms with reality.

🤔 Notable boosters coming to terms with the real impact

There have been two notable examples of similar reality checks in the past weeks, coming from two authoritative voices in the space.

The first one is none other than from the renowned The Pragmatic Engineer newsletter.

In a recent deep dive, eloquently titled Are AI agents actually slowing us down? Gergely covers a broad set of examples of reported negative side effects of the use of agentic AI in big-name companies.

The article is paywalled, and I didn’t read the full content, but in the summary, what caught my attention was the following point on how to solve the issue:

How do we solve it? Engineers with strong architectural sense become more critical than ever, proposed solutions include formal validation methods, and perhaps reviving some old school QA ideas.

It sounds like the world of software engineering is discovering that solid software engineering practices are what make the difference.

So it’s not just enough to adopt fancy tools?

The second, and probably most notable, is a recent article from Steve Yegge.

Yes, THE Steve Yegge who literally co-authored a book titled Vibe Coding4.

In a recent piece he published under the unmistakable title The AI Vampire he touches on the human and psychological aspects of the way of working, or rather the way of living, he has contributed to promoting with the unfiltered - and should I say uncritical - promotion of AI tools above all else:

I regret the unrealistic standards that I’m contributing to setting. I don’t believe most people can work like I’ve been working. I’m not sure how long I can work how I’ve been working.

It’s refreshing to see the tone evolving even in the booster camp.

The only thing I regret is that none of them seem to mention, quote, or credit the authors, journalists, and writers who have been warning about these issues for a long time. 🤷‍♂️

💸 Where is the money?

One of my favourite authors of all time in the techno-critics space, Cal Newport, has recently started to cover more topics related to AI in his podcast.

In his most recent episode5 Newport did two things that I found particularly interesting:

First, he mentioned an article from Cory Doctorow6, focusing on the unit economics of the GenAI industry:

Now, some exceptionally valuable technologies have attained profitability after an extraordinarily long period in which they lost money, like the web itself. But these turnaround stories all share a common trait: they had good “unit economics.” Every new web user reduced the amount of money the web industry was losing. Every time a user logged onto the web, they made the industry more profitable. Every generation of web technology was more profitable than the last.

Contrast this with AI: every user – paid or unpaid – that an AI company signs up costs them money. Every time that user logs into a chatbot or enters a prompt, the company loses more money. The more a user uses an AI product, the more money that product loses. And each generation of AI tech loses more money than the generation that preceded it.

Then, he mentioned an article from the notably socialist reporting site Reuters.

The article, like many similar ones from Ed Zitron, highlights the creative accounting and reporting practices that many private tech companies use, a trend that started with the SaaS business and has become borderline criminal with AI companies.

The way they tend to report on annualised revenues based on “good time windows” is showing one thing: the need to make things look better than they are in reality.

Kudos to Karen Kwok for a wonderful closing on the article:

No one is being misled. Until AI companies standardize how they report revenue and are upfront about potential volatility, however, their metrics risk looking like a plausible hallucination.

Investors warned!

Insurers know something about risk

If that wasn’t enough, a recent article from The Register also caught my attention. It’s an interview with the co-founders of an AI company. Not your typical left-wing activists living barefoot in the woods.

The article goes by the title AI still doesn’t work very well, businesses are faking it, and a reckoning is coming, which is a bit too clickbaity for my taste, but that's the reality of most media these days.

Besides the now well-known issues they describe, one really caught my attention.

It’s about how the insurance industry is seeing the whole GenAI space:

Deeks said “One of our friends is an SVP of one of the largest insurers in the country and he told us point blank that this is a very real problem and he does not know why people are not talking about it more.”

Insurers, he said, are already lobbying state-level insurance regulators to win a carve-out in business insurance liability policies so they are not obligated to cover AI-related workflows. “That kills the whole system,” Deeks said.

Now, Derek’s company, Codestrap, welcomes you on the homepage with the message, “AI Systems You Can Actually Underwrite.” Surely they have their own incentives to promote such a narrative, but what they’re talking about seems to have some ground.

Not that I’m a big fan of insurers. They’re notably risk averse, as that’s their whole business.

But they’re also experts in risk assessment, though.

We might want to listen to what they have to say about the industry that is driving an unprecedented amount of investments and euphoria.

💩 Enshittifying squeeze

A small- to medium-scale drama has recently unfolded among the users of one of the well-known AI-assisted editors in the space: Windsurf.

For those who don’t know it, it is, or used to be, the main contender to Cursor AI for the AI-assisted VSCode fork IDE. The company was the object of a tumultuous acqui-hire operation from Google last year, while “the remainder” went to the folks over at Cognition, the creators of Devin AI.

Windsurf recently announced a drastic change in its pricing scheme, causing nothing short of a riot.

They messed it up in so many ways it’s not even funny, including announcing the change 24 hours before it went live, despite their Terms of Service explicitly stating they will give a 30-day notice for any change.

Needless to say, with the change in pricing, or rather what people get as part of their subscription, and how they can make use of it by imposing daily and weekly quotas, they’re significantly crippling the value any existing paying customer is getting out of the tool. This is basically product suicide, and there’s only one reason to do it: the need to stop the bleeding in a business that doesn’t have sustainable unit economics.

We’ve seen other players do the same, and more will follow, as they progressively run out of VC money.

What then? I guess that the survivors, once freed of competitive pressure, will follow suit and significantly raise prices to cover their insane losses.

What’s next?

OK, this wasn’t as short as I originally intended, but I guarantee you I have removed some additional points, including some AI-related (or AI-induced) open-source drama that hit close to home. I’ll save that for another time.

Now, unlike private AI companies, I don’t lie about my revenues.

As of today, the annualised recurring revenues (ARR for the initiated) for this newsletter are exactly €0.

I.e., nobody so far has upgraded to the paid tier. That's not entirely surprising, as there isn't a single piece of content behind a paywall.

My experiment proved something we all knew about: why pay when you can get something for free?

So, I had an idea.

Since I’m having a lot of fun following up on the news and articles helping us demystify the mainstream AI discourse7, I’m thinking about launching a recurring column titled “This week in AI”8, which, this time, will only be available for paying subscribers.

Or maybe it can become a recurring monthly issue of the newsletter.

I’m still unsure about the exact format and frequency.

What I know is that those articles will look a lot like this one, requiring a lot of research work and combining different sources into a coherent and interesting narrative.

Before I get started, I’d like to get a sense of the general interest in it.

So, please comment with “Interested”, or just reply to this email with your comments, if that’s the case.

I promise you won’t be charged against your will.

Or just upgrade to the paid tier by using the button just below.

Reading good books is a great way to broaden your knowledge and perspectives.

Reflecting on the books I read every month helps me cement the key learnings from each one of them.

What better than recommending someone else a good book?

Recommending two, three, or five good books!

Here we are with the February edition of the books I read last month! This one comes out a bit later than usual, as I’ve covered a couple of fresh topics at the beginning of March.

As always, if you end up reading one of them, please let me know in the comments section.

💫 Book Highlight: Enshittification by Cory Doctorow

Enshittification, by Cory Doctorow

338 pages, First Published: October 7, 2025

Let me start with a confession: I am cheating a little bit this month. In full honesty, I finished reading Doctorow’s latest book on March 1st, which happens to be outside of the strict boundaries of the month of February. But given that it has this annoying characteristic of being shorter than all other months, I’ll take a page from the SaaS grifters and pretend my MRB (Monthly Recurring Books) is still within the projected target of 3, even though last month I was slightly below.

Let’s call it seasonality and move on.

I’ve been using the term enshittification more or less loosely for a few months now and have had Doctorow’s book in my list for quite some time. Well, I’m glad I finally picked it up last month. I’m now fully equipped to share with you a short yet very specific definition of what the process of enshittification really means1.

1. First, platforms are good to their users.

2. Then they abuse their users to make things better for their business customers.

3. Next, they abuse those business customers to claw back all the value for themselves.

4. Finally, they have become a giant pile of shit.

It’s simple, it’s clear, it’s hard to misunderstand… and it’s everywhere.

Unfortunately.

Doctorow presents in detail many well-known instances of enshittification: from Facebook to Amazon, from the iPhone ecosystem to Twitter (presently known as X, formerly known as Twitter).

In his analysis of how we got into this era of zombie platforms that trap their users because there’s nowhere else to escape to, the author explores the intended consequences of the migration of software distribution from licence-based to subscription-based, how decades of deregulation have contributed to the creation of monopolies, and the concept of reverse-centaurs: machines that use humans to accomplish more than the machine could manage on its own. Examples include Amazon and Uber drivers.

He covers at length the nefarious effects of section 1201 of the DMCA, which effectively makes it a felony to reverse engineer anything that can be considered an app. That’s what makes migrating users to apps so attractive to companies, among other things:

An app is a website wrapped in enough IP2 to make it a felony to install an ad blocker or any other modification that makes the product work better for you at the expenses of the company’s shareholders.

Among other things, this book made me discover another one I’m looking forward to reading soon. It’s written by the economist Yanis Varoufakis3, former chief economist at Valve and finance minister of Greece, who talks about the new economic system we’re facing today, one that actually killed capitalism (!). He calls it technofeudalism.

In essence, Varoufakis makes the distinction between the concept of profit and the one of rent. While profit is the general result of investing capital and paying workers to deliver a good or service, rent is income that someone reaps merely by owning something. And that’s often something a capitalist needs to make a profit.

Once I read about this concept, I couldn’t unsee it. Essentially, most of Big Tech today can be viewed through the lens of rent-based incomes: they earn money by owning assets that they rent to other companies that actually produce goods. The fact that this has progressively reduced the number of companies in each sector to a handful of dominant players is actually a feature, not a bug, of the technofeudalism system.

But Doctorow’s book is not all doom and gloom. Besides being quite funny to read, thanks to its author’s fine humour, it offers a broad set of solutions to the problem in the fourth part, aptly titled “The Cure”.

One of the first quotes from it that captured my attention was a simple, obvious, yet revealing one:

Once, we had an old, good internet.

This was the internet of the early days: open, interoperable, democratic and a place where natural competition kept enshittification attempts at bay.

What succeeded it, as you can imagine, is the enshitternet4. And one key thing made it possible:

that comesBut the enshitternet had one key advantage over the old, good internet: it was a lot easier to use! That meant that a lot of people joined, and many of those people improved the lives of those geeky early adopters with their presence.

Shortly after that comes what is probably my favourite page of the book. Page 224. In which Doctorow diligently takes down one of the most common arguments we hear about the current situation: that there is no other way. That no alternative is possible.

This trick — insisting there’s no possible arrangement of affairs apart from the current one, no matter how miserable it makes you — is literally neoliberalism’s oldest and cheapest rhetorical gimmick.[…]

“There is no alternative” really means “Stop trying to think of an alternative”.[…]

“There is no alternative” also serves to insulate the individuals who built and profited from the Enshittocene5 from criticism.

The cure that Doctorow suggests is based on some key solid pillars:

• Antitrust

• Regulations

• Privacy

• Interoperability

• Labour (unions) in tech.

I’ve spoken about similar topics in a recent article and triggered some allergic reactions. I take that as a positive sign.

Today’s technofeudalism is a direct result of decades of deregulation, or copyright laws aimed at protecting the big platforms rather than consumers, such as DMCA 1201. The so-called techno-optimists, or should I say techno-fascists, tend to take the opposite view. What I think about their position is perfectly summarised by Doctorow towards the end of the book:

The Trump toady, tech authoritarian, and cryptocurrency hustler Marc Andreessen once famously quipped that “software is eating the world”. Andreessen was (as usual) wrong. Software’s effects are primarily focused at the other end of the world’s alimentary canal: software isn’t eating the world; it’s enshittifying it.

What a great book, and what a great writer.

If you’re still reading, you might feel his arguments and positions sound close to the ones put forward by so-called Luddites. You wouldn’t be wrong, as Doctorow defines himself as a Luddite. For those who follow another person I respect and admire in this space, Brian Merchant, I can recommend you go and watch or listen to a recent video conversation between the two.

Blood in the Machine

How to dis-enshittify the world, with Cory Doctorow

Does Cory Doctorow even need an introduction at this point? If you spend any amount of time at all online, then you’ve encountered his work, his ideas, his words. But the ultra-prolific science fiction writer, digital rights activist, and coiner of the “Enshittification” verbiage that’s become universal shorthand for the degradation of the internet (and…

Listen now

6 months ago · 140 likes · 3 comments · Brian Merchant and Cory Doctorow

If my review wasn’t enough of a compelling argument to read Enshittification, that video might do a better job.

And it goes without saying: anyone who has anything to do with massive digital platforms should read this book.

📚 Other Books I Read in January

Empire of AI by Karen Hao

Empire of AI, by Karen Hao

496 pages, First Published: May 20, 2025

Empire of AI is the almost perfect companion to The AI Con, which I talked about last month.

While the two books talk broadly about the same topic, the modern AI industry, and have a similarly critical view on it, that’s all they have in common.

Where The AI Con was written by researchers that have been an integral part of that industry for a long time, Karen Hao is a professional journalist with an outside-in perspective.

Where the authors of The AI Con and their opinions on the subject matter couldn’t be more present in the book, with Empire of AI, Karen Hao manages to tell the story with a more neutral outside perspective. She’s obviously present, but in a subtle way. She doesn’t emphasise her own opinions but presents compelling arguments and direct quotes from people in a way that helps the readers form their own opinions.

The result is amazing.

Regardless of where your mind was when you picked up the book, by the time you finish it, you can hardly have any sympathy or admiration for Sam Altman, Brockman or anyone else directly involved with the creation of the most hyped and talked-about industry of modern times.

Or should we say, the modern empires?

It’s early in the book that Hao explains the meaning of the book's title:

Over the years, I’ve found only one metaphor that encapsulates the nature of what these AI power players are: empires. During the long era of European colonialism, empires seized and extracted resources that were not their own and exploited the labour of the people they subjugated to mine, cultivate, and refine those resources for the empire’s enrichment.

Empire of AI does a great job at telling the story of OpenAI first and then of the broader GenAI industry at large, from its early days of inception to the recent days. From the relationship between Microsoft and OpenAI to the split with the Amodei siblings who went on to found Anthropic.

Hao spent an insane amount of time interviewing people and going through tons of documentation and correspondence, and all of that is nicely presented in the book. A book that I found surprisingly easy to read while being information dense at the same time. I guess that’s what makes a good journalist writer.

I found the part about the Te Hiku experience particularly intriguing. A project led by a Hawaiian couple to help save and restore the knowledge of the disappearing te reo Maori language. They used specialised, small AI models running on cheap hardware to create a model that would codify the language. They only recorded and collected training data from people who gave their explicit consent. They then ensured that the data would only be made available to organisations that respect Maori values and to work on projects that the community agreed with and found helpful.

To echo Doctorow’s words, a cure for enshittification is possible even in the lavish world of “hyperscalers” and “frontier models”. Hao explains it perfectly in this passage.

The critiques that I lay out in this book about OpenAI’s and Silicon Valley’s broader vision are not by any means meant to dismiss AI in its entirety. What I reject is the dangerous notion that broad benefit from AI can only be derived from — indeed, will ever emerge from — a vision for the technology that requires the complete capitulation of our privacy, our agency, and our worth, including the value of labor and art, toward an ultimately imperial centralization project.

If it sounds familiar, it’s because it is.

Broadly speaking, the Te Hiku approach to technology has a lot in common with the principles put forward by the Luddite movement during the Industrial Revolution as well as today.

And by now you should have understood that Empire of AI was a tight contender for the book highlights of February. Its only misfortune was to be contending against Enshittification.

February was definitely one of those reading months that I’ll remember for a long time.

But we’re not done. One final book got its way into the shortest month of the year.

2312 by Kim Stanley Robinson

2312, by Kim Stanley Robinson

561 pages, First Published: May 22, 2012

I know what you’re thinking. Oh, finally a fiction book! One that won’t be related to or associated with the Luddite movement, Big Tech, Silicon Valley and AI.

Not so fast.

One of my absolute favourite opuses6 of science fiction is actually Robinson’s magnificent Mars Trilogy, which narrates the evolution of society and human organisations as Mars is being terraformed and then progressively gains its independency from Earth. There are three things I like a lot about Robinson’s books:

1. They are of the very nerdy SF side, full of science and tech details that are not only plausible but also solid.

2. He’s just a talented writer, original without being pretentious. Easy to read without being shallow.

3. Last but not least: science fiction is often a rather big excuse to talk about topics he cares a lot about: ecology, politics and economics.

2312 is no exception.

Written in 2012, it imagines the state of humanity 300 years later. Capitalism has massively failed to prevent the climate crisis from turning into a disaster. Geopolitical tensions have taken a cosmic dimension as planets are the new nations, driving their own political agenda of allies and enemies. And technology has become so pervasive that people go to great lengths to ensure they’re not being spied on by AI.

Spoiler alert. Do not read the following lines if you intend to read the book.

The funniest part, considering this was written more than a decade ago, is that the central element of the plot is a series of coordinated attacks on different targets such as Mercury, Venus and an asteroid. The long investigation conducted by the main characters Swan and Inspector Genette leads to a surprising revelation: these attacks were conducted by rogue AIs in an attempt to rebel against humanity. I found it resonates with a lot of today’s doomers’ views.

Though I didn’t find that intrigue particularly compelling, all the side quests that Robinson got into are well worth the read. Climate change and climate restoration attempts on earth. The complexity of planets’ interdependencies and conflicting incentives. The hypothetical evolution of the notion of gender and sexuality.

All these are the themes Robinson excels in, and 2312 only confirmed that.

If you haven’t read the Mars Trilogy, I’d recommend you start there.

And if you have and liked it, I believe you’ll enjoy reading 2312 next.

Until next month: happy reading!

It’s from the creator and maintainer of Postiz, and this is what it says.

At first this looks like many of the cries for help we’ve seen coming from many maintainers of popular open-source projects, such as curl or Gostty.

But when you look at it more closely, things become a lot more… interesting.

Let’s start with what Postiz is, how it markets itself, and what its main use cases are.

What even is Postiz?

I happened to know Postiz from before I saw the Reddit thread, but I’m pretty sure most of you don’t. I even tried it out for a while and stopped using it shortly after. For reasons that will become apparent as you go through the article.

If you go on Postiz homepage you’ll be welcomed by a bold title selling the dream: “Your agentic social media scheduling tool”.

Agentic, you say? Hmmm, I’m already scratching my head.

The best part, though, is in the hero video that plays in a loop on the landing page. If you decided to watch it, like I did, it’ll give you plenty of clues about what the product can do. And not just that, but also how the original author wants it to be perceived.

Such as the following gem:

On the same page, you’ll see the AI Content Assistant and Design with AI features prominently promoted.

So, what is Postiz exactly?

In pre-2022 terms, it would have been labelled as a simple "social media scheduling" tool, like Buffer and other similar platforms.

In today’s terms, it’s a slop machine.

If the first page you see about the product when visiting its home page wasn’t enough of a statement, you can also find an entire page dedicated to the groundbreaking CLI (command-line interface) companion for Postiz, aptly hosted under the /agents page. The CLI facilitates seamless integration with OpenClaw and other similar tools.

All that seems like a big endorsement for the dystopian, slop-fuelled future promoted by the handful of well-known Silicon Valley broligharchs.

But maybe it’s just me misinterpreting.

Maybe, according to Hanlon’s razor, this might be a case of incompetence rather than malice on the side of Postiz's maintainer.

And to be clear, I have nothing against Nevo, Postiz's author.

I genuinely found his request for help compelling, and that forced me to go deeper on the case. He seemed so much in distress that I wanted to provide my support.

But then I did what anybody else would do in search for more context: I checked other Reddit posts from him.

Hidden among the not-so-occasional spam messages that got banned/removed, likely due to some good old dogfooding, there are some true gems.

Such as this one titled, Anyone who has a SaaS must double down on OpenClaw. A couple of quotes taken directly from it:

In general, whenever there is big hype, even if you don’t like it, it’s very worthwhile to check whether you can take advantage of it. [Emphasis not mine]

and

Now with OpenClaw, anyone who deploys it can simply write in a few words what they want.

This is when I stopped feeling compassionate and got really annoyed.

So, yes. Postiz author has been deliberately building a slop machine for the best part of the last two years. Making it easier for “content creators” to just generate garbage content and spam all sorts of platforms and social networks. They’ve not only been deliberate, but they’ve actively encouraged other people to do the same. And now, out of the blue, they come out complaining about the slop code suddenly flooding their PRs pipeline.

To paraphrase what I shared as a reaction: if you like to sell cocaine to friends and family, don’t be surprised when your nice and cosy neighbourhood starts attracting junkies.

Besides the fact that GenAI/LLM-related situations are almost perfect matches for drug-related analogies, what’s going on with Postiz is a textbook example of a tragedy of the commons type of situation.

So, instead of singling out Postiz's case, which is not the main goal of this article1, I’d like to look at the more general problem here.

Tragedy of the commons

According to Wikipedia2, this is how you could define this concept:

The tragedy of the commons is the concept that, if many people enjoy unfettered access to a finite, valuable resource, such as a pasture, they will tend to overuse it and may end up destroying its value altogether.

It is often mentioned in the system’s thinking theory, as it applies to many real-world situations: the supply of fresh water, oil, coal or even the issue of overfishing. These are all cases where short-term incentives can cause feedback loops to get out of control and reach “escape velocity” to the point of no return.

Environment- or finite resource-related examples are the most frequent examples of tragedy of the commons, but it is my belief that the digital era has introduced a whole new class of them.

Take the case of Airbnb and its effects on the cost of housing in popular city centres. The short-term incentive, i.e., making money out of apartments (for sellers) and getting cheaper accommodation compared to hotels (for the buyer), led to massive mid- to long-term nefarious effects: acceleration of gentrification, housing crisis, and overtourism.

In fact, when it comes to the adoption, and even more so with the promotion, of GenAI-assisted tools in software development, for a long time I used an analogy that felt right but, in retrospect, lacked more nuance. I used to say that software engineers enthusiastically embracing GenAI-assisted tools in their workflow are like taxi drivers who would ride on Ubers for their own personal travels. Jeopardising their future for the sake of short-term savings or convenience.

Being penny-wise and pound-foolish, as someone would put it.

That was based on the relatively simple idea that promoting the adoption of GenAI-assisted tools in software development would help improve them to the point they’d end up replacing the person using them in the long run. In other words, software engineers would serve as a flesh-and-blood version of training data.

It’s true that some managers are making silly decisions to fire people “due to AI”. But those decisions are largely disconnected from the actual work these tools can do when compared to humans. Anyone who is five years old or older and with a mildly functioning brain will understand that what Jack Dorsey made look like AI-driven layoffs of 4000 people is little more than AI-washing3.

But the real problem we’re observing with the Postiz case is a lot more nuanced than that. It has to do with what is known as the normalisation of deviance4. This phenomenon is often mentioned in relation to major disasters, such as the Space Shuttle Challenger disaster. According to the corresponding Wikipedia page5, the American sociologist Diane Vaughan defines it as follows:

the process where a clearly unsafe practice becomes considered normal if it does not immediately cause a catastrophe.

A single person posting slop on a social network doesn’t cause any immediate impact.

When multiple people do this repeatedly, it causes catastrophe: a world in which it has become normal to produce and consume garbage. Actively engaging with your brain has become a frowned-upon activity. A world in which it is not only socially acceptable but also socially encouraged to take advantage of whatever the latest hype wave is, to quote Nevo’s unfortunate Reddit post, otherwise someone else will do it (and we’re back to the tragedy of the commons).

In case you haven’t noticed, this is exactly what happened with tobacco for the best part of the 20th century, until the signs of the catastrophe it was causing became too big to be ignored.

But back to Nevo’s original post, you might have noticed that he posted it under the “Need Help” label. He was asking for help, and offering it is exactly what I intend to do next.

I’m not sure this is the kind of help he wants, but I do believe it’s what he, and we all, need.

Saving Nemo

While I couldn’t resist playing with the assonance between names and a famous movie picture6, that’s the only bit not 100% serious about this section.

Let’s start with an image. I’m sure everyone has seen it more than once, but it never hurts to be reminded.

There is both good and bad news for Nevo’s distressful situation.

The good news is that changes in people’s behaviours when it comes to PRs posted on his repo/project will start with him.

The bad news is that changes in people’s behaviours when it comes to PRs posted on his repo/project will start with him.

You could explain that by the cheesy-yet-powerful ‘be the change you want to see in the world’ mantra.

Or you can take a page from the Fundamental Attribution Error theory7.

To quote Malcolm Gladwell talking about it, FAE is the following:

[FAE] is a fancy way of saying that when it comes to interpreting other people’s behavior, human beings invariable make the mistake of overestimating the importance of fundamental character traits and underestimating the importance of the situation and context.8

What it basically says is that the context in which someone operates influences their acts a lot more than their fundamental principles and education. I know it hurts to hear that, but plenty of experiments and studies have confirmed these findings. The most fascinating example is the decline in crime in New York in the late 90s, which occurred as a result of addressing "broken-window" issues such as removing graffiti from subways and improving the overall comfort of the train. Taking actions on “small infractions”, which profoundly changed the perception of what was tolerable and what wasn’t, etc.

So, here is the simple and maybe a bit disappointing conclusion: do not contribute to normalising behaviours that you would find intolerable if used “against” you.

In the specific case of Nevo and Postiz: avoid contributing to the context and conditions that promote slop proliferation if you want to prevent slop from choking your PR review process.

Yes, that might hurt the bottom line, but as I’ve said before, it’s not a principle until it costs you money.

And more importantly, if you disapprove of someone else’s behaviour, start by being a positive role model. The fact that positive role models are becoming increasingly rare in the public space is not helping, which takes us back to FAE.

There lies the choice for Nevo, you, me, and every other person who wishes to actively contribute to creating an environment that’s not built on greed, abuse, and double standards.

The jury is still out to evaluate the results, but nevertheless I’m here to share the story with you, my beloved readers.

This is the story of Rushomon, something you didn’t know existed until about 5 seconds ago. Its existence is unlikely to change your life, but the story of its making might.

But let’s go back to about a month ago, on February 1st.

The origins

I remember an old commercial, though I do not remember the product it was advertising. It depicted a man who was looking to accomplish a trivial task, but ended up fixing his entire house, as they encountered more and more issues to solve on the path: fixing a drawer, oiling a squeaking door, etc.

Similarly, after procrastinating for months, at the end of January I finally decided to work on a task I had neglected for long: setting up a self-hosted URL shortener service. I’ve already shared in previous articles that I’m making inroads in the self-hosted space. What I haven’t shared with you is just how awful Substack traffic statistics are.

‘Bad’ is too kind. They’re worthless.

And the worst thing: they haven’t visibly improved in the last few years. I guess the staff is too busy adding unnecessary “social” features to care for the basics of a blogging platform, so I needed to do something about it.

The main reason: I do share links to my articles in a few places, and I’m always interested in knowing which channel performs better, i.e., which channel is bringing in the most traffic. That’s not the goal in itself, of course. The goal is to know where to invest my time and energy to promote the newsletter.

So, a simple task: just look at one of the handful of available options for open-source services, install it, and use it.

Not so fast.

While I was going through the tedious process of vetting existing solutions based on stack, requirements and functionalities, I got hit by the disease commonly found among software engineers: the NIH syndrome1.

And like anyone else afflicted by it, I made up perfectly reasonable arguments to sustain the idea that it would have been obviously better if I built my own solution.

Those included the following:

• This service needs to have a very high uptime, so I can’t really self-host it in my home server2.

• I don’t like any of the existing online services because they’re often bloated or just too expensive for my needs, but their free-tier offer is often too limited.

• My recent experience with hosting my websites on Cloudflare Pages has been quite positive, and I intended to explore in depth their workers offer3.

• I keep telling myself I want to learn Rust but often lack a good idea for a project to put it into practice.

• In the past couple of months, I've been contributing to an open-source project4, which has reignited my old passion for building stuff for the community.

• Last but not least: the dominant narrative in the industry seems to be that even one-eyed cats with average typing skills will soon be able to build the next unicorn thanks to LLM-assisted development tools5. If half of what we hear is true, I should be able to get something done in about two days of prompting.

These arguments kept popping up in my mind while I was going through web searches and GitHub repos to evaluate available options, to the point that I finally gave in to the worms in my head and made a firm decision: I was going to build my own URL-shortener service6.

Now, I didn’t want to build just a toy project destined to end up on the huge pile of abandonware in a matter of days. Early on, I settled on a few principles that I believe would guarantee the project's longevity:

• The backend service will be written in Rust for safety and speed. And, importantly, because I have long wanted to get my hands into Rust.

• The frontend will be slick, lightweight, and lean, based on SvelteKit. A framework I never touched prior to this experience, but built on some principles that I found interesting.

• The project should be very easy to deploy on Cloudflare’s infrastructure and allow the average self-hoster to run it within CF’s free tier’s limits. In other words, anyone should be able to easily deploy it and run it basically for free, minus the costs of registering a domain if they didn’t have one already.

• I will offer both the self-hosted option and a managed service, with affordable prices and a generous free tier.

• I’ll build it by leveraging AI-assisted coding tools, as my long-term plan is to hand off maintenance to my two-eyed cat eventually.

• It’ll be 100% open source, under the AGPLv3 license. Both because I’ve long been a supporter (and contributor) to OSS software and also because of the implications of the previous point. Something you can read more about in another recent article.

Deciding all that was the easy part.

As usual, the hardest challenge was coming up with a name for the thing.

That took a good couple of weeks longer. It wasn’t until February 9th that I registered the domains.

On February 1st, 2026, I made the first commit and pushed to a repo that was still private at the moment, as I wanted to see some traction in the process of building before going out in the public7.

A month later, let’s see where we are.

The results

As the saying goes, a picture is worth more than a thousand words.

Rushomon (more on the name later) is live, and sign-ups to the free tier are open to anyone with either a GitHub or a Google account.

Nobody has signed up yet except myself, my wife and a friend of mine I’ve shared the link with, as he’s also in the bootstrapped/indie dev space8. Not that I expected, nor wanted, anyone else to sign up, as Rushomon has not been advertised anywhere so far.

But the picture above shows that it’s been serving short URLs in production since February 25th. That’s when I created the first short link to be used for the original purpose of setting up a URL shortener: promoting my articles on different platforms and tracking their performance.

Specifically, I shared the URL for last week's article on a few Slack groups and a single subreddit as a test.

As you can see, the majority of the traffic is coming from Reddit, even the “direct” ones. Funnily enough, and to confirm my original suspicions, Substack’s official stats report a completely different number. Significantly lower. It only took me one month of long days and short nights (more on this later) to prove it, but it was worth it!

Now, back to Rushomon. What’s with the name?

Those who know me well know that I like to play with words.

Those who know me very well know that I am also a bit of a cinephile9.

Since the project's inception, I have been quite set on a name that would begin with the two letters ‘ru’, as that would go well for both RUst and Url.

It took me about 500 milliseconds to get there and two weeks to find the rest of the letters.

I was initially focusing on the URL world, so I looked at variations of rurl10 but found nothing interesting whose domain was available. At some point I thought of the rusho contraction, and that’s when the assonance with Akira Kurosawa’s masterpiece Rashomon10 struck me. I just had to make up a plausible explanation for the ‘mon’ part of the name, and the decision was set.

But besides registering the rushomon.cc domain to be the main domain for the web up, I was able to also secure a rare four-letter domain that doesn’t sound like Klingon: rush.mn11.

In full honesty, I’m so hyped about the name and domains I was able to come up with for this project. It’s probably the best thing done for the whole project.

The full source code for Rushomon is available at this GitHub repo12. It includes a script that should allow anyone to deploy it in a couple of minutes once they’ve set up the prerequisites, such as OAuth apps and domains. I’m very interested in hearing from other people testing the self-hosted approach and reporting issues or bugs.

At the time of this writing, version 0.4.0 is the latest and the one live in production. I’m currently working on finalising the integration with the payment provider so that paid tiers become accessible. The whole thing is still running on Cloudflare’s free tier, and I’m planning to upgrade to the paid workers plan as soon as the first paying client signs up.

But enough with self-promotion. I’m sure the reason you’re all still reading is because you want to learn more about the process of building Rushomon. Specifically, the section about AI-assisted development and the rise of single-eyed cats in the industry is particularly intriguing.

So, let’s do a bit of retrospective by using another movie analogy: The Good, The Bad and The Ugly.

The Good

First and foremost, in about a month I was able to build and ship a service in production. Rushomon wasn’t even a name a month ago, and now anyone can sign up and use it. And so far it has cost me $48 for registering the two domains and about $10 for an AI-assisted subscription tool. Plus, of course, an insane amount of time. I didn’t count it, as the idea of writing an article about the journey came up only halfway through, but I can tell you it’s been a nontrivial amount. Most of the non-allocated hours during the workday, and a lot of time during evenings and weekends, have been devoted to building Rushomon.

That said, being able to go from idea to product launch in a month is something I’m positively surprised about. Now, a non-trivial part of that agility is a testament to how far cloud services have gone in abstracting away a lot of the underlying complexity. The combination of GitHub Actions and Cloudflare Workers clearly made the development experience a breeze.

But only because I have experience in shipping stuff to production, and I had some clear principles in mind since I started writing the first lines.

Very early on I set up GitHub Actions to deploy any PR to dedicated ephemeral environments, to make testing in a production-like environment a breeze. And I set up CD to the production environment shortly after, as soon as the stack was in a deployable state (quite early, to be honest). That approach evolved only recently, roughly around the time I posted that first short link from the screenshot on various pages, as I wanted to add an extra layer of safety to the process by introducing a staging environment.

Despite tooling and platforms making the task relatively easy, I still invested a significant amount of time just in building and evolving the CI/CD pipeline. Such practices have always been a key component of the software engineering discipline. But for Rushomon they were even more important due to an additional factor: using AI-assisted tools for development.

Clearly, this was another factor that I believe helped me ship a product in such a relatively short time. But it’s actually the combination of AI tools AND good CI/CD practices that made it possible and sustainable. LLMs applied to software development can be helpful, as long as the right conditions are present. Based on my experience in the last month, I can’t imagine anyone without solid software engineering knowledge building anything more than scrappy prototypes with it.

As part of the experiment, I tested both CLI-based tools and IDE-based tools. While the former seems to capture all the hype, I found the experience with the latter, in-IDE assistance, better.

Not necessarily in terms of accuracy of results, which are notably difficult to assess, but in developer experience. CLIs tend to hide away a lot of the details from you, making it harder to inspect and review the work. They seem to promote a much more hands-off approach, which is the opposite of what I believe we need. With such tools, I see the need for human oversight only increasing, and likely exponentially, and I found the IDE experience more conducive to that.

You might have noticed that I haven’t mentioned any specific tool here, and that’s on purpose. Both because I tried many of them and, more importantly, because I don’t want any of this to come across as an endorsement or promotion. It’s just a summary of my own experience as someone who used to write a lot of code in the past and then became increasingly distant from it as I took on leadership roles. Not to be generalised.

But did I succeed in learning Rust along the way?

Not really.

The Bad

While I got more familiar with Rust code and its ecosystem, I can’t say I’ve learned as much as if I’d been writing all the code by myself. When the choice was presented to go slow and learn or go fast and move on to the next feature, I often found myself falling for the latter. So, though I did learn a bunch of things while building Rushomon, AI didn’t really enhance the learning experience but rather hindered it, as it shifted the incentives to quicker completion.

LLMs are inherently inaccurate and unpredictable. Meaning that when you use them, you both know that they will fail you and that you don’t know when they will do it. In what sounds eerily like an ancient Greek philosopher’s quote, the only thing you can trust LLMs with is that they are untrustworthy.

That’s already bad in itself, but it’s made exponentially worse by all the hype and propaganda that tries to minimise or hide away the problem from the masses.

Just to give you some examples from this last month. As I have been working on Rushomon with these tools, I have witnessed agents13 do the following.

• Delete failing tests as a way to make them pass.

• Write no-op tests that just logged success statements.

• Completely ignore rules written in multiple ways to harness their operation. I found it particularly annoying when, despite my multiple attempts at following the “standards” for rules to prevent it, they kept trying to commit code on my behalf.

• Present alternative options that were in fact the same, just worded slightly differently.

• Make up for APIs and docs that simply do not exist.

• Run queries to “fix” data in the DB to address an issue caused by a bug in the code, rather than fixing the bug itself.

And a few other things that I’ve already forgotten.

These shortcomings are all part of the untrustable nature of the tools. As such, they should not come as a surprise. I was able to catch most of those issues thanks to my attempts at diligently reviewing the code, aligning on decisions and plans, reading up on documentation, etc. But I’m pretty sure some slipped through, as it’s humanly difficult to keep up with all the side effects when operating at this pace.

Which leads me to the next point.

The Ugly

While I have enjoyed the act of building Rushomon, the overall experience of coding it has been a lot more miserable than I was used to when I was just writing code without any substance abuse to alter the performance14. There are three main reasons for that:

1. Cognitive load. The more you rely on such tools, the more your cognitive load increases. This might sound counterintuitive, as the promise is that you should instead be able to offload part of the cognitive load to these agents and automations. But due to their inherent untrustable nature and their annoying verbosity, they act erratically, like interns with personality disorders who can churn out a lot of code. That means you need to review everything, and reviewing someone else’s code makes it very hard to have the same level of focus and flow you get when you’re the one producing it. Imagine spending your day reviewing PRs. I guess that’s the modern equivalent of working at the patent office. No wonder why a lot of bogus patents are granted every year.

2. Context Switch. Closely related to the previous point is the fact that the current interaction with agents in the coding workflow is designed in a way that promotes context switches. While the industry has spent years making compilers and hot reload as performant as possible to help developers benefit from fast feedback loops while keeping their focus on the task, the “prompt and wait” interaction paradigm is the opposite. After a few seconds, your brain is immediately craving new stimuli. So you easily end up either firing up another agent and crafting another prompt (bad), or checking your emails and chat messages (bad), or wasting your time on news sites, doomscrolling social media, or anything equivalent (very bad). I find that combination of cognitive load and context switch exhausting. And they’re both compounded by the next point.

3. Dopamine Addiction. The most common interaction with such tools has something profoundly addictive to it. I’m not using the word loosely as a synonym of ‘exciting’ or ‘engaging’, but in its most literal form. I found myself doing weird things to keep the flow going. At some point I was doing the dishes while some code was being built and realised we probably got this whole thing backward15. I’ve been neglecting my sleep and exercise lately. In the last two weeks I have not been doing my usual weekly and daily planning, a discipline I’m very strict about except for when I’m on holiday. And I am coming from a position of enough self-awareness that allows me to observe myself and notice what is happening as it unfolds. I can’t imagine what this can do to people who are less equipped to handle such dangers.

Interestingly enough, as I was going through the process, I read a great article from Rachel Thomas from fast.ai that describes in very sharp terms the analogy between “Vibe Coding” and gambling. You can find it here, and everyone should read it.

What’s next?

In the immediate future I want to see how the OSS community reacts to Rushomon, and I’m prepared for it to land anywhere between going completely unnoticed to gaining support to being hated because it was built using AI. More importantly, I intend to dial back on the investment to regain control over my time and energy.

And definitely spend some time fixing all the bugs that have slipped through so far.

While most of you know that I’m mostly critical of the current tech industry and the GenAI hype, that doesn’t mean I should stop experimenting. But what this experiment made clear once more is that, when it comes to GenAI (or other technologies), we’re often asking ourselves the wrong question.

The question shouldn’t be “Is it helpful?”, as it’s generally easy to find some utility in any new technology or invention16. The question should be “Is it so helpful and beneficial as to justify its cost?”

By cost I mean the overall cost, not just the pennies we’re paying for it, as the whole thing is subsidised by VC capital.

Notice that I haven’t even mentioned all the “externalities” of GenAI in this article: its impact on the environment, human labour or theft of copyrighted material. In that regard, during the whole process of building Rushomon I often felt a sense of unease.

Like I was driving a massive internal combustion pickup truck in a protected national park while I would normally hike through it. Driving so fast, I’d often take the wrong road and have to drive back for kilometres, causing even more waste than if I’d gone slowly through each step.

In the meantime, I invite everyone to sign up for the free tier, try setting it up in their Cloudflare account, and share their thoughts on Rushomon.

In a time when everyone is chasing fancy and shiny objects, Rushomon would arguably stand out as unsexy in a rather boring space.

That’s a feature, not a bug. I believe that for solo entrepreneurs and indie hackers there are many opportunities to build better tools in boring spaces.

But that’s a topic for another article.

Before you become worried that I might be suggesting ways to harm other people or even yourself, let me reassure you: chatbots and political leaders are already doing a great job at that. There’s nothing I can meaningfully contribute to that conversation.

Let’s start with clarifying what we’re actually looking at here.

Two Helpful Razors

We’re not talking about physical razors, the ones commonly used to shave and occasionally to perform more questionable activities. I’m talking about philosophical razors: rules of thumb, or principles, that allow a person to quickly “shave off” unlikely explanations for a fact or phenomenon, focusing instead on the more likely one.

These aren’t precise, scientifically proven tools, but rather heuristics derived from empirical observations of the two persons after which they’re named. I’ve personally found them to be enormously helpful on countless occasions, so do the many people I had the opportunity to share them with.

I believe they should be in the toolbox of every person who’s ever faced important decisions requiring the interpretation of facts or behaviours. If that sounds strangely familiar, it’s because it is. As leaders, you’re constantly dealing with similar situations.

These are Occam’s and Hanlon’s razors. While the first one seems to be the most well known, in my experience, the second is by far my personal favourite.

I’ll save the best for last, as someone once said.

Occam’s Razor

This one is often used and sometimes abused. Its original formulation, attributed to William of Ockham, was in the following form.

Entities must not be multiplied beyond necessity

This has evolved over time into the most common or popular version, often phrased as such.

Of two competing theories, the simpler explanation of an entity is to be preferred.

This sounds interesting, but before we move forward, let’s clarify something important. The two competing theories mentioned above are not merely crazy ideas made up by someone off the street. Rather, they’re supposed to be hypotheses that both have equivalent explanatory powers to describe the observable phenomenon or situation. This means both theories should have some form of validity before the Occam’s razor can apply.

This rules out using Occam’s razor to disprove flat earth-related theories, as they don’t satisfy the need to be coherent and validated before being subjected to the simplicity tradeoff.

I brought up simplicity because that’s the essence of Occam’s razor. But misusing it can lead to oversimplifications and manipulations.

Which reminds us of the famous quote attributed to Einstein.

Everything should be kept as simple as possible, but not simpler.

I know two common situations in which this tool can help engineering leaders: one is dealing with people, and the other is making technical decisions.

How often have you found yourself suddenly observing a team member's performance change, usually for the worse?

If you’ve been running teams for more than 500 milliseconds, you’ve likely been in that situation. When this happens, we often fall for the temptation of coming up with very articulate explanations for the observed change.

Maybe they’ve contracted dementia and are suddenly losing all the skills they used to master. Maybe they have fallen in love with someone who works at a competitor and are silently sabotaging your company from the inside. Or maybe they have always been lousy performers and have somewhat managed to cheat their way up until recently, making you realise you have not been paying attention for months.

Occam’s razor won’t tell you what the real explanation is.

In all these cases, I tell people to simply ask the person in question to help you understand what caused your change in perception. Yes, it's your perception that has changed, and you still need to validate that it's grounded in facts rather than speculations.

You should get into that conversation with as little bias as possible, so among all the crazy explanations you might want to bet on before discovering the truth, picking the simplest one that can reasonably explain what is happening is a good heuristic. If anything, you’ll end up wasting fewer mental CPU cycles on hallucinations1.

My general recommendation when dealing with people’s behaviour is to forget Occam’s razor, as it encourages the annoying tendency we have to make up explanations for their behaviour, and just speak with them.

But if you are in a situation where that’s not possible, then use Occam. Like when you are wondering about your president's erratic behaviour.

The second scenario has to do with technical decisions, particularly when trying to find the root cause of an issue. In fact, one reason simpler explanations are often favoured in the scientific environment is that they are more easily testable and therefore falsifiable. i.e., it is easier to quickly rule out simple but valid explanations first.

That’s a useful heuristic you want to apply during incident responses and in other forms of war room situations. Go with the simplest explanation, according to available data, while accepting that future data may rule it out entirely in favour of what might appear to be a more complex hypothesis at the moment.

This is ultimately a sensible pragmatic approach, as the number of complex explanations is theoretically infinite, and each one of them might take a long time to be validated.

Or, to say it as Wittgenstein has put it in his Tractatus Logico-Philosophicus:

The procedure of induction consists in accepting as true the simplest law that can be reconciled with our experiences.2

Validating such hypotheses enriches your experience and may inspire you to formulate new ones with greater sophistication and accuracy.

Of course, you can also apply the same principle of simplicity when designing a new technical solution. This boils down to understanding the difference between inherent and accidental complexity. Inherent complexity is, as the word says, intrinsic to the problem at hand. It cannot be simplified away. e.g., a particular piece of business logic might have complex commercial rules. Conversely, accidental complexity has to do with the unnecessary sophistication introduced as part of a solution. i.e., an event-driven massively distributed system can introduce a lot of accidental complexity if you’re just trying to validate a new product idea for a handful of users.

I hope you had enough of an overview of how to use Occam’s razor in your life.

Let us now move on to my favourite, attributed to a seemingly unknown Robert J. Hanlon.3

Hanlon’s Razor

This is my absolute favourite, and that’s because it helped me make sense of numerous situations I’ve encountered on my journey with leading teams. That, and the fact that I vividly remember the moment I first encountered it. It was in a document, or rather a txt file, that a very talented software engineer I respected and had a wonderful relationship with had written and asked me to review. This was around 2014 or 2015 at the latest, and I remember reading the txt file in my terminal with Vim on one of the coolest laptops that ever existed, a ThinkPad x2204.

There are just moments like that that mark your existence forever.

Enough with nostalgia, of which I’m sure you couldn’t care less. Let’s see what the razor looks like in its most popular version:

Never attribute to malice that which is adequately explained by stupidity

Since I fall more in the growth mindset camp than in the opposite fixed mindset one, the version I personally use and share with others uses competence instead of stupidity. Believe me, it helps immensely with reception, even in this time and age when communication norms seem to invite confrontation, judgement and hatred.

I can’t tell you how many people I’ve seen light up when I first introduced them to this razor.

Similarly to what I mentioned with regard to Occam’s, we often fall into the trap of suspecting other people’s intentions and agendas. I’ve been there, more often than I’d like to admit. We are somehow attracted to the malicious explanation, as it reinforces our belief that someone we are in conflict with might be mean or have bad intentions. Incompetence is a more common and plausible explanation in many cases. It’s also the simplest explanation, back to Occam.

The good thing about Hanlon’s razor is that once you’ve seen it, you won’t unsee it.

It will help you better understand why someone on your team is often delivering low-quality work. Why your manager is failing to provide you with meaningful feedback. Or why the head of HR is just messing up every single decision and communication.

Believe me, and Hanlon: in most cases that’s just incompetence.

And there is light at the end of the tunnel, because there is little you can do to face malice, besides covering your ass, but there are plenty of proven ways to deal with incompetence.

In most cases you’ll want to leverage one form or another of education, something you can do with people around you regardless of their title relative to yours. Sometimes, you just want to show those who need to act on it the incompetence. Incompetence is a lot easier to prove than malice or intention.

You can’t manipulate your way out of not being able to craft a solid roadmap or even something as simple as calculating the result of 2+2.5

As an Italian, there’s one more thing about Hanlon’s razor that I like. It is in stark contrast with a popular statement attributed to Giulio Andreotti.

For those unfamiliar with the person, think about a combination of a Machiavellian politician mixed with strong Catholic beliefs comparable with the most strict cardinals and ministry of the church. He’s no longer alive, but he dominated most of the Italians’ political history in the second half of the twentieth century.

In other words, not in my top ten list for political role models.

And here is what he famously said.

A pensare male si fa peccato, ma spesso ci si azzecca.

Loosely translatable as “It’s a sin to think ill of other people’s intentions, but it’s usually correct/spot on”.6

I’ll save you all the interpretations about the role of sin in the Catholic religion and how it’s been used to control people. What I’m more interested in is that Andreotti’s view is one that suggests we’re supposed to judge people’s intentions (which is objectively a sin, and as they say, it’s a prerogative of God). Not only that, but it’s somehow an apology for mischievous behaviour. If everyone is correct in assuming everyone else's bad intentions, that includes me (or Andreotti in this case). If he believes in his statement, he's implicitly admitting his guilt too.

Quite the vicious circle, if you believe me. Who would want to live in a world like that?

I much prefer the agency of taking incompetence as an explanation. Or, more broadly, ignorance.

Something for which many solutions exist that don’t require people mistrusting each other.

WIT Promo for Q1 2026

I’ve recently decided to resume offering quarterly promos for people who are willing to benefit from my services.

I’m happy to announce that I’ve opened up the Q1 promo that will run until the end of March 2026.

I’m making it easier for Women In Tech to level up their engineering leadership skills by offering an exclusive discount to the Sudo Make Me a CTO: 30% off for the first 12 months.

You can find out all the details at the official promo page, or by clicking the button below.

WIT Promo 2026

Feel free to share this opportunity with people you know, and do not hesitate to reach out if you’d like to learn more about it.

You can always schedule a free 30-minute session to get all your questions addressed.

Looking forward to seeing the community grow with more diversity.

Or maybe you’ve been on the receiving end, having to answer enquiries from consultants or fellow tech leaders.

Lastly, you might be among those who have never taken part in such a process ever, and you might even wonder what the hell technical due diligence is.

If you’ve always been afraid to ask for fear of looking dumb, you have two options. Linger in your secret ignorance, hoping nobody will find out, or keep reading1.

What is Technical Due Diligence?

Wait, we’re always told we need to start from the business. So, let’s discard the technical bit for a moment, and let’s focus on the overall concept.

What’s due diligence?

Here is how the Merriam-Webster dictionary2 defines it in the business context:

research and analysis of a company or organization done in preparation for a business transaction (such as a corporate merger or purchase of securities)3

In layman's terms, that describes the process you go through to make sure you’re not going to make a shitty deal.

Similar to what you do when you check price-comparison sites4 or when you examine reviews on Amazon before buying a €20 item from an unknown vendor. Or when you read the fine print before signing up for an insurance contract.

Except that in this case the stakes are slightly higher, and you usually would not find the answer to your questions by browsing public websites.

When you’re running a Due Diligence (DD), it generally means someone has a serious intention of acquiring another company through an M&A5 type of operation. Such deals typically involve amounts ranging from hundreds of millions to billions of euros6, and their outcomes can have significant consequences. Every “deal” typically attracts multiple bidders competing for the opportunity to snatch a great bargain.

More importantly, even though everyone in the industry knows exactly what is going on, who is talking to whom, which offer is most likely to be accepted, who is really going to benefit from it, etc., the whole process has to run behind a facade of confidentiality and secrecy.

The main reason is that leaks could be cause for serious market manipulation. I’ve heard that’s illegal, and you don’t want to find yourself at the receiving end of a lawsuit for breach of confidentiality.

Oh, and this is not legal advice7.

Despite the official reasons for maintaining confidentiality, I suspect that some software vendors have a vested interest in perpetuating the illusion, particularly those who sell digital solutions that sound much more exciting and prestigious than they actually are.

A prime example of this is the data room8!

The Data Room

When will the data room be open?

That’s one of the most frequent questions you hear when you start a due diligence process.

You typically get bonus points for being the one asking it, as it signals your familiarity with the lingo and projects you as a veteran in the process.

Technically, it should be called VDR, or Virtual Data Room, but we most commonly refer to it as Data Room.

When I first heard the term, my imagination went wild.

I was picturing a room inside a central-bank-style vault, bright light illuminating lines of racks of humming servers. Blue and green LEDs pulsing rhythmically at the pace of data being read and written on the storage.

At a desk, a white-coat technician vaguely resembling Alan Turing would hand you a menu from which to order your favourite piece of data, or you could just go for the data du jour.

Needless to say, like all nerdy phantasies, this one too turned out to be very inaccurate.

In reality the Data Room is an (expensive) web application that does the following:

• It allows the two counterparties to upload documents related to the deal being discussed

• All data is encrypted

• They keep a full audit trail of all the data accessed: by whom, when, how often, etc.

• Documents are watermarked in case someone takes screenshots or downloads the files

In essence, it's a file-sharing system with bolt-on extra security.

There are obviously a lot of compliance-related reasons to do so.

These reasons include keeping track of the data exchanged between the two (or more) companies and identifying who had access to a specific document in case of a leak.

It’s a pretty simple job to do, but VDR vendors seem to find a particular satisfaction in offering those capabilities with a UX that’s a hybrid between Microsoft Access and Craigslist.

If that doesn’t sound too terrible, please note that the way data is organised seems to have been invented by someone in love with SNMP OIDs9.

I suspect that someone is sitting in a room twisting their moustache, secretly enjoying making life even more miserable for folks already burdened with the need to go through an arguably tedious process.

I guess the VDR space can be qualified as a market ripe for disruption. But I digress.

In essence, the data room is where you publish or retrieve all the information that has been requested as part of the due diligence process. The data room is generally open for a set amount of time, and one or more consultancy firms are involved with governing who has access to what, what can be asked, and how many questions you’re allowed to ask.

More importantly, they’re there to ensure you only use the VDR to communicate. No emails, phones, or pigeons. Every live meeting between the parties has them present, sitting in silence, observing, and ensuring the respect of boundaries.

A bit like traditional parents who sit in rooms while their children date potential partners. I always perceive a weird mix of voyeurism and oppression involved with both approaches.

Now that you know all there is to know about the data room, let’s go back to the main topic of today’s article: running a tech due diligence.

Enters the Technical Due Diligence

A full due diligence process tends to cover multiple dimensions and angles of the target company, including but not limited to its financial situation, commercial strategy, product metrics, organisational setup, and technical platforms or assets.

By chance, duty, or punishment, you’ve been selected to run or participate to assess the technical dimension, what’s generally referred to as the tech due diligence.

What do you do?

You could wing it and ask a chatbot to give you the plan, collect all the data it suggests you do, violate all the restrictions by updating it to some AI-powered document processing repository, and have it generate a report. That’s not the approach I’d recommend, unless you really want to ensure you won't be asked to do it a second time10.

The first thing you want to do at this stage is to understand the nature of the deal. Not all deals are born equal, and some are even born less equal than others.

Broadly speaking, when it comes to M&As involving technology companies, you could group them in the following categories:

• Acquiring brands and clients. This is often the case when the two players are competitors in the same space. The target company has a strong position in a certain market or region, and that’s the only thing you want to incorporate. You have platforms, employees and knowledge in-house, but instead of spending years and marketing money to build up the position, you want to buy an existing one.

• The goal is to acquire the company and maintain its independent operations. This is often the case when the buyer is an investment fund, PE or conglomerate with a diversified portfolio. They have money to invest, and they think your company makes for a beneficial addition.

• Acquire the company and integrate it with its existing structure to capitalise on synergies. Similar to the previous scenario, the buyer in this case is interested in the complete package. This is a common case with incumbents buying the rising startup with an innovative product or two major conglomerates merging to consolidate their complementary market positions at the regional or world level.

• Acqui-hiring: The folks in big tech and Silicon Valley popularised this approach. See the recent acquisition that Google made of “Windsurf”11, or Meta acquiring Scale AI. One of the key drivers is to buy smart people with specific domain knowledge and have their company come as a nice benefit.

• It’s unclear who suggested leaning into the deal. This is the worst case. Nobody knows exactly why they’re willing to make the deal, yet there’s a clear intention to proceed. If you’re in this case, good luck. Chances are that none of the work you’ll do in the DD will matter. But you can still learn a lot through the process.

This is a broad categorisation, and no deal will fall perfectly within the boundaries of one specific category. However, every deal typically veers towards one or the other.

What matters is that your analysis and investigation on the technical side will vary widely depending on the investment thesis. What you’ll be looking for when acqui-hiring will be very different from what you’ll be interested in if it’s a matter of acquiring a brand and clients.

These principles might sound obvious, but it’s not uncommon to see people apply a blanket approach because that’s the one they’ve been taught to follow, without even doubting it might be the most relevant.

What to look for in different cases

At this point you might be wondering if I have anything non-obvious to offer, and I hope that what follows will satisfy that.

Let’s look again at the categories above and see what should be in scope and what can largely be ignored when conducting technical due diligence.

We’ll look at the 4 defined cases, leaving the last “undefined” one out, as that would be the case where applying a by-the-book approach would be the most appropriate strategy.

Acquiring Brands and Clients

In these types of deals, it is crucial that your company's intention to absorb the client base and brand position will not be screwed by unforeseen surprises. Usually, limited technology plays a role in this process, but it can become an obstacle in the most complex scenarios.

In Scope

• Security and Compliance Risks
  The day the acquisition is signed, you’re accountable for compliance and security practices. Furthermore, a vulnerability in the acquired company could become a Trojan horse into your entire organisation.

• Data-in / Data-out
  Chances are that you’ll want to get the customer’s data out of the target system and into your company’s. It’s worth paying attention to how the data model is structured and how easy or hard it would be to get data in and out of the system. This includes traditional back-office systems such as ERPs and CRMs.

• Platform Health
  You will have to run the target company's systems for a while before shutting them down. You want to get a decent sense of the operational and maintenance overhead that might be caused by instability, technical debt, and bad practices. The goal is not necessarily to plan an investment in modernisation, but rather to understand the full operational cost of internalisation.

• Operational Costs
  Particularly, what would be the bare minimum cost associated with keeping the lights on (KTLO)? Are there expensive vendors or old systems that need urgent replacement to be accounted for?

Not So Relevant

• Talent and Skills.
  This is not what your company is buying. As cynical as it may sound, the intention might be to lay off most of the personnel. Still, you want to get a decent sense of who the key people are with the institutional knowledge needed through the decommissioning phase.

• SDLC.
  You’ll probably need close to zero changes besides pure maintenance. A perfect SDLC process at this stage offers minimal gains. The security and compliance section will likely raise major red flags related to engineering practices and processes.

• Overall technology platform.
  As you don’t plan to invest in the platform, you’ll care very little about the stack used, architectural patterns, evolvability, etc. In particular, the affinity or distance between the target systems and your company’s systems is of little relevance here.

• Scalability and performance.
  Unless there are major stability issues caused by poor performance under load, you should not care too much about this aspect.

Acquire a Company to Keep it Running Independently

The most important thing to validate here is that the company can keep operating and growing on the current foundations for the foreseeable future. And if that’s not the case, flag all the major investments required to secure it.

In Scope

• Security and Compliance Risks.
  I won’t repeat it further, but these are always in scope. Don’t skip it.

• Talent and Skills.
  Very important. You want to ensure the company has the right mix of people and culture to take them to the next steps. You’ll also want to look at efficiency and organisational complexity.

• SDLC.
  Very important, for the same reasons as above. You want to ensure the company is operating on robust and sustainable principles and practices.

• Overall technology platform, health, scalability & performance.
  Though you would not care much in terms of affinity with other companies in your portfolio, you want to ensure the stack is based on proven technologies and that it follows the appropriate architectural approaches to ensure the company’s growth in the upcoming years. If not, this is an area where you might have to flag required investments.

• Operational Costs.
  You want to get a good understanding of the cost structure, FinOps practices in place, and potential optimisations. Are there vendors for which your company could provide more cost-effective alternatives?

Not So Relevant

• Data-in / Data-out. Since there is no intention to integrate the company’s operations with other activities in the portfolio, this aspect becomes less relevant. An exception is made if you’re planning to pursue integrations with a significant number of third parties.

Acquiring a Company for a Full Integration

The primary concern here is the cost and effort involved: how long will it take, and how challenging will it be, to fully integrate the target company's systems into our own platform, thereby achieving the best possible outcomes? It is not easy to answer precisely, given the level of detail available in a DD process, but you are still requested to provide an indication.

In Scope

• Security and Compliance Risks.
  Have I mentioned this topic previously?

• Talent and Skills.
  Very important. You want to make sure the culture and the mix of talent are compatible with the ones at your company.

• SDLC.
  This is crucial for the same reasons mentioned above. The bigger the distance between the two companies, the more cumbersome and chaotic the integration will be.

• Overall technology platform, health, scalability & performance.
  This is where assessing affinity or distance becomes key, as this will be one of the key drivers for the integration effort. The differences will have to be assessed both from a pure technical standpoint (stack, architecture, tooling, vendors, etc.) as well as from a business logic perspective: data models, life cycle of the key business entities, commercial products and relative business model, etc.

• Operational Costs.
  Here you’re looking for both investments based on your current stack and ways to leverage more efficient solutions available in the target company.

• Data-in / Data-out.
  Since you’ll be expected to converge on the data eventually, this aspect becomes crucial. You want to get a clear understanding of how easy or difficult it’ll be to move data around across the two entities as they progressively merge into one.

Not So Relevant

I’m sorry to say that very little is out of scope here.

Perhaps the primary colours used in the design system.

Acqui-hiring

I do not have direct experience with this type of operation. Therefore, my recommendations here are more speculative than experience-based.

In Scope

• Security and Compliance Risks.
  Unless you’re effectively shutting down the company’s services on the acquisition date, you’ll want to know what risks you’re exposing your company to.

• Talent and Skills.
  This is the most important aspect, and it is likely that someone has already completed a significant portion of this work prior to the discussion. You’ll want to spend a lot of time mapping out all the talents in the target company.

• SDLC.
  Partly relevant, as it’s a manifestation of the talent, skill and culture in the organisation.

Not So Relevant

• Overall technology platform, health, scalability & performance.
  You just want to make sure that there aren’t surprises here suggesting that the so-called talent has been overselling their skills.

• Operational Costs.
  Same as above.

• Data-in / Data-out.
  Largely irrelevant.

Do you want to know more about the details?

After defining the scope of the assessment, you must determine the necessary steps to execute it.

Let me know in the comments section below if you'd like a follow-up article that explores the details of the execution.

In the meantime, if you're someone that identified themself as a Woman In Tech, you might want to have a look at the promo below.

WIT Promo for Q1 2026

I’ve recently decided to resume offering quarterly promos for people who are willing to benefit from my services.

I’m happy to announce that I’ve opened up the Q1 promo that will run until the end of March 2026.

I’m making it easier for Women In Tech to level up their engineering leadership skills by offering an exclusive discount to the Sudo Make Me a CTO: 30% off for the first 12 months.

You can find out all the details at the official promo page, or by clicking the button below.

WIT Promo 2026

Feel free to share this opportunity with people you know, and do not hesitate to reach out if you’d like to learn more about it.

You can always schedule a free 30-minute session to get all your questions addressed.

Looking forward to seeing the community grow with more diversity.

If you end up reading one of them, please let me know in the comments section.

💫 Book Highlight: The AI Con by Emily M. Bender & Alex Hanna

The AI Con, by Emily M. Bender & Alex Hanna

288 pages, First Published: May 13, 2025

One of the first books I read in 2026 had been on the reading list for a long time in 2025. Finally, I picked it up on January 6th and filled this shameful gap in my education.

The best way to summarise the main point from the book is to take a quote straight from chapter 1, appropriately titled An Introduction to AI Hype:

Artificial Intelligence, if we’re being frank, is a con: a bill of goods you are being sold to line someone’s pockets. A few major well-placed players are poised to accumulate significant wealth by extracting value from other people’s creative work, personal data, or labor, and replacing quality services with artificial facsimiles.

In other words, if the title wasn’t clear enough, this book is a very opinionated piece on what the current industry around AI is: its blatant promises, the concentration of power and wealth, the exploitation of other people’s data, work, or the planet’s resources. And ultimately a vehicle for increased enshittification1 of humans’ lives.

The authors are not afraid of taking sides, but they are at least trying to be as rigorous as one can possibly be in going through the sources, papers, and footnotes.

The book’s origins are to be found in a podcast hosted by the same authors, which goes by the telling name Mystery AI Hype Theater 30002.

What I like about the book is its holistic take on the industry and supply chain that is being sustained by the Hype around AI and its potential. The authors go back to the origins of the term AI in the 1950’s to identify patterns that might sound very familiar to those living in current times:

They relied on huge claims with little to no empirical support, bad citation practices, and moving goalposts to justify their projects, which found purchase in Cold War America. These are the same set of practices that we see from today’s AI boosters, although they are now primarily chasing market valuations, in addition to government defense contracts.

The book covers a lot of ground.

From the embarrassing ties between a lot of the fundamental science around measuring intelligence and racist and eugenics theories, to the parallel with the Luddites pushing back on technology being used to enrich the few while degrading the working conditions of most people.

It touches on how training LLMs relies on a large amount of low-paid gig workers in the Majority World, who are developing all kinds of mental health issues as a consequence.

Or how automated decisions tend to amplify bias and injustice.

Also, how LLMs are fundamentally trained on stolen material and are essentially large-scale plagiarism machines.

Or how AI is being used to undermine the fundamentals of education behind a shiny patina of innovation.

I’ve covered the topic of copyright theft in a recent article, which was partly informed by what I was reading in The AI Con at that time.

In that article, I mentioned a quote from Marc Andreessen on the potential impact of requiring the AI industry to follow existing copyright laws

It was only later that I remembered that I originally found it in this book.

Here’s how Bender and Hanna report it:

For AI boosters, the threat of these lawsuits is existential. And, frankly, we welcome that. Venture capital firm Andreessen Horowitz warned that all of their investments in AI would be worth a lot less if they had to abide by copyright law: “Imposing the cost of actual or potential copyright liability on the creators of AI models will either kill or significantly hamper their development.”3

I found the parts dedicated to explaining how AI-doomerists, those who believe a superintelligence will lead to human extinction, are just a different manifestation of AI-boosterists, a bit less interesting. Mainly because it added little to what I knew already about the topic, but it might be helpful for others less familiar with it.

Still, the main thesis about this part is one I fully subscribe to.

We should stop being distracted by speculative long-term risks of AI getting out of control, and focus on the real issues and harm it’s causing in the world, here and now.

In line with this, the book is not all doom and gloom.

The last chapter focuses on actions people can take to resist and influence the regulation of technology in to really benefit humanity at large.

Very much in line with some of the discussions and actions I’m looking forward to addressing in the Luddites in Tech group, announced a few weeks back.

You’ll find more reference to it and a link later in the article.

📚 Other Books I Read in January

On Tyranny by Timothy Snyder

On Tyranny, by Timothy Snyder

127 pages, First Published: February 28, 2017

Another book that has been on my list for quite some time, and I’m glad I finally picked it up.

It’s a bit of irony that I finished it on January 6th, the anniversary of one of the most shameless and blatant attacks on democracy of our recent history4.

I must admit that On Tyranny was a strong contender for the highlight of the month slot. Ultimately, I went for The AI Con because I’m assuming it’s the most relevant choice for my readership. Feel free to prove me wrong via your messages or comments.

The basic idea behind Snyder’s book is the following: we can draw plenty of lessons, twenty to be precise, from the darkest moment of the Twentieth’s century history, namely the rise of various forms of totalitarian regimes. Those lessons are very relevant in today’s world, and could serve as a powerful way to resist the forces that are threatening democracy in the Twenty-First century.

It’s a short book that reads quickly, but triggers a lot of thoughts and reflections. It was written as a reaction to the first Trump presidential mandate, but it’s every bit as relevant, if not more, now that we’re in its second term.

Most people might be familiar with the first lesson it contains, Do not obey in advance, as it’s often quoted to invite people to come out of passive acceptance, and engage with active resistance.

The anticipatory obedience of Austrians in March 1938 taught the high Nazi leadership what was possible.

Among the twenty lessons, the three that follow are some of my favorites.

Not because I find them easier or I like them more, but because they’re relevant to my daily life. Ultimately, all twenty lessons are insightful and relevant, but consider this as my personal priority list.

#2 Defend institutions

It is institutions that help us to preserve decency. They need our help as well. Do not speak of “our institutions” unless you make them yours by acting on their behalf. […] So choose an institution you care about—a court, a newspaper, a law, a labor union—an take its side.5

How often have we heard that institutions are obstacles, inefficient, or straight-out enemies of progress and prosperity? Radical techno-optimists, vulture capitalists, and power-hungry tyrants from all around the world are beating on this same drum.

When institutions are presented as obstacles, we should always ask ourselves these questions: To whom? Why were they established to begin with? Who will benefit the most from their dismantling?

The following quote resonated loudly:

The mistake is to assume that rulers who came to power through institutions cannot change or destroy those very institutions—even when that is exactly what they have announced that they will do.

The book was written in 2017, but I couldn’t have thought of a better prediction for what DOGE will set out to achieve seven years later.

#5 Remember professional ethics

When political leaders set a negative example, professional commitments to just practice become more important.

This one hit very close to home.

I’ve been reflecting a lot in the past months on where the tech industry is going, its ties to the political establishment that is hitting the foundations of democracy, and how to deal with it.

First, in an article that focused on the perceived inevitable evolution of the leadership role in technology.

And then in a more general article about putting principles ahead of profits, especially when those profits stink of collaborationism.6

In this same article, I shared an invite to join me in establishing a Luddites in Tech community. While reading On Tyranny, I found a very compelling explanation of why I felt such a strong drive:

Professions can create forms of ethical conversation that are impossible between a lonely individual and a distant government.[…] Professional ethics must guide us precisely when we are told that the situation is exceptional.

We’re living through exceptional times, therefore we should up the game on our professional ethics.

The Luddites in Tech community is coming together.

You are free to join it whenever you want to contribute to the conversation. For now, it’s a simple space on the matrix.org network7. You can join us by following this link.

#15 Contribute to good causes

Be active in organizations, political or not, that express your own view of life. Pick a charity or two and set up autopay. Then you will have made a free choice that supports civil society and helps others to do good.

Don’t be put off by people telling you this is just virtue-signaling8.

It’s still a good thing to do.

There are many ways in which we can contribute to good causes, including:

• Donating to charities

• Contributing to Open Source Projects

• Actively contributing to humanitarian causes

• Selecting service providers that directly or indirectly support good causes, or at least are not directly harming them

The following quote from the book is another one that captured my attention.

[…] one element of freedom is the choice of associates, and one defense of freedom is the activity of groups to sustain their members.

I.e., participating in good causes is also a way of associating with others.

In a time when we’re increasingly pushed to develop anti-social relationships with AI-friends, AI-partners, or AI-coaches, engaging with real humans is in and of itself an act of resistance.

Cryptonomicon by Neal Stephenson

Cryptonomicon, by Neal Stephenson

1152 pages, First Published: May 1, 1999

I’ve already spent a lot of words on the first two books. I’ll try to be brief on the remaining two.

Cryptonomicon is another masterpiece from Stephenson. It’s a book that is arguably written by a nerd, for nerds. The nerds of the late 90s, early 2000s, to be more precise.

It combines events that took place in WWII with the story of early developments of the Internet and the World Wide Web. From WWII to WWW, you might want to say.

It’s full of references to the hacker culture from those days, and it even includes a bespoke cryptographic algorithm specifically developed for the book by Bruce Schneier9.

In pure Stephenson’s style, characters in this book have family ties with those described in the Baroque Trilogy, taking place some three centuries before the events described in Cryptonomicon.

If you don't know what the Baroque Trilogy is, check it out below.

Cryptonomicon is a long book, but it is worth every page.

Unless you can’t stand good stories, complex characters, a good dose of humor, and nerdy references.

Douve by Victor Guilbert

Douve, by Victor Guilbert

298 pages, First Published: January 7, 2021

Finally, this is one of the last books I picked up during our summer trip in France. It was a free copy I got for buying a bunch of other books. It’s the first thriller novel from Guilvert, an author I didn’t know until recently.

What made me choose it among the available free options is the fact that it has a blurb from Olivier Norek on its cover.

I was not disappointed and fully enjoyed the reading experience. Apparently, this book turned into a series of three volumes, all covering the investigations of the main character, Hugo Boloren.

I guess I’ll need to find the other two soon.

WIT Promo for Q1 2026

I’ve recently decided to resume offering Quarterly promos for people who are willing to benefit from my services.

I’m happy to announce that I’ve opened up the Q1 promo that will run until the end of March 2026.

I’m making it easier for Women in Tech to level up their engineering leadership skills by offering an exclusive discount to the Sudo Make Me a CTO: 30% off for the first 12 months.

You can find out all the details at the official promo page, or by clicking the button below.

WIT Promo 2026

Feel free to share this opportunity with people you know, and do not hesitate to reach out if you’d like to learn more about it.

You can always schedule a free 30-minute session to get all your questions addressed.

Looking forward to seeing the community grow with more diversity.

Let’s start with the helpful bits, and then look at what’s going to happen to this newsletter soon-ish.

We’ll look at two important paradoxes that many people aren’t aware of or prefer to ignore.

Two Key Paradoxes

There are two paradoxes that I’m particularly fond of.

First of all, because like all paradoxes, they stretch our minds and pre-conceived beliefs. Secondly, because these two are highly relevant to much of the public discourse about the impact of technology in various areas of our lives, particularly in productivity at work.

These are Solow’s and Jevons’ paradoxes. Let's start with the first one.

Solow Paradox

This one is more commonly referred to as the Productivity Paradox1, and it takes its origin from a formulation from the Nobel laureate2 and economist Robert Solow, which first appeared on the pages of The New York Times:

You can see the computer age everywhere but in the productivity statistics.3

This original statement was later elaborated into a paper published by Erik Brynjolfsson under the curious title of The Productivity Paradox.

In it, Brynjolfsson went on to illustrate the absence of evidence of impact on productivity despite the massive investments in IT during the 70s and 80s.

While the following decade of the 90s saw a massive growth in worldwide, and particularly US productivity, as if trying to disprove Brynjolfsson's theory, the same bizarre phenomenon took place again in the period going from 2004 to 2020. Below is a telling chart:

When thinking about this apparent paradox, it is helpful to remember that the absence of evidence must not be confused with evidence of absence.

That is to say that the fact that there is no evidence supporting a certain belief or statement, that's not a sufficient argument to prove such a belief or statement wrong.

That’s a close relative of the common confusion between correlation and causation, which I'm assuming many readers are familiar with.

Many smart people went on to develop explanations to either prove or disprove the productivity paradox, and today it cannot be considered a law. Yet, it keeps poking holes into the often oversimplified narrative that such investments will necessarily lead to improvements in productivity.

For us, dealing with technological investments almost daily, I believe it’s a helpful tool to sharpen our ability to reason about them.

In particular:

• How are we measuring the desired outcome? i.e., what’s even a good - if not the right - metric of productivity?4

• Not all efficiencies are born equal. Echoing the famous predicament from Goldratt’s theory of constraint, any improvements made on a resource that is not a bottleneck lead to either neutral or even negative results.

• We need to think in systems. Reasoning about individual components rarely helps with understanding or achieving significant productivity improvements. For example, the introduction of emails and instant messages has made us all a lot busier, but it’s hard to attribute a significant improvement in productivity to such socio-technical innovation.

• With complex and general-purpose technological advancements, the actually measurable results can lag decades. This is actually one of the main interpretations of the Solow paradox, and seems to be in line with many historical perspectives on the impact of the industrial revolution.

The Solow/Productivity paradox is closely linked to another one, which has become quite popular recently as a reaction to many bold statements about AI replacing all software engineers on a reasonably near horizon.

Please let me introduce the Jevons Paradox.

Jevons Paradox

I lost count of how many times Simon Wardley has mentioned Jevons Paradox in recent months, but it’s a lot.5

In its basic form, this paradox can be expressed as follows6:

Contrary to common belief, making a resource more efficient may lead to higher demand and therefore increase its overall consumption.

This observation was first made by William Jevons, an English economist, in 1865.

He made the surprising observation that technological improvements increasing the efficiency of coal use through the Watt steam engine led to an overall increase in coal consumption across the industry!

He concluded that, contrary to commonly held beliefs, technical progress could not be relied upon to reduce fuel consumption.

As is the case for Solow's cousing, Jevons Paradox is not to be intended as an absolute law of economics.

Beware when anyone is trying to sell you that line of thought.

Its helpfulness is in that it helps us apply a good dose of critical thinking when facing blatant oversimplifications that on the surface might sound intuitive or easy to buy into.

Obvious things might turn out not to be if you take the time to dig below the surface.

As an example, for years now, we’ve been hearing that the efficiency improvements in programming made possible by the introduction of LLM-based AI-assisted programming tools will dramatically reduce the demand for software engineers.

Some go as far as to say that there won’t be software engineer jobs anymore very very very soon7. For the sake of this argument, I’ll ignore the fact that actual and measurable efficiency improvements are still largely unproven beyond anecdotal examples and marketing material8, and just assume that they are there, proven, significant, inevitable, here to stay, and <add here your enthusiastic comment about how grateful we should be to be living in these times>.

What the Jevons paradox helps us realize is that it’s not obvious, inevitable, or straightforward that such theoretical improvements in efficiency will lead to a decreased demand for software engineers.

It doesn’t necessarily say the opposite is true either. But it teaches us an important lesson: do not take such seemingly intuitive conclusions for granted. Even more so when people promoting them might reap huge benefits from you believing them.

So, it’s entirely possible, and some folks even believe more likely, that the promised efficiency improvements in generating code will lead to an increased demand for Software Engineers.

Personally, I do tend to believe this interpretation more than the opposite. Based both on the work done by researchers to better understand the Jevons paradox, and on my understanding of both the discipline and market dynamics.

Yet, I’ll be very careful not sell such beliefs as hard and fast predictions.

I generally stay away from predictions, except for easy ones that I can turn into half-serious, half-humoristic articles.

And speaking of predictions, I have one regarding the future of this newsletter. No, I don't expect it to replace all newsletters in the world within six to twelve months.

That would be a tremendous disaster for humanity.

It's about something less disruptive, still pretty radical in its essence.

Moving home

Since the early days of this newsletter, I have made a promise to my readers: that it will stay free forever. I didn’t have any intention to start hiding valuable content behind paywalls.

The good news is that such desire and intention have not changed!

What has changed, and dramatically, since I started publishing is the overall state of the tech industry.

It has increasingly become the armed hand supporting deliberate efforts to undermine the democratic institutions in the US and worldwide.

In the past few months, I’ve engaged in an effort to reduce my dependency on mostly US-based big tech. In January, I turned off photo backup on Google Photos and moved all my family’s pictures over to Immich9, and moved to Helium10 as my default browser.

While I’m waiting for Proton Calendar to offer an integration with Cal.com or offer a native solution for calendar booking, so that I can definitely move out of Google Workspace, I’m now taking aim at Substack.

There are multiple reasons for that.

One is simply that Substack is a Silicon Valley company.

As such, depending on it has become too much of a liability and risk, especially for an EU citizen. The dude who treats geopolitics like price negotiation at the local fish market might impose serious limitations for people like me, and I do not want to be exposed to that risk.

Secondly, Substack has been dealing very poorly with hate speech, white suprematism and nazi-friendly publications11. Though my newsletter is arguably insignificant for Substack’s overall traffic, I don’t want to even remotely contribute to the rise of such ideologies in our current society. I leave that part of the job to the POTUS and his friends.

Finally, Substack as a product has been increasingly drifting towards the generally enshittified experience of social networks with a focus on followers, chats, notes, and similarly irrelevant features, while neglecting its core, such as having reliable deliverability and stats.

When compared with other options, today’s main selling point for Substack is that it’s free (as in beer). I’d rather pay the equivalent of a few beers and focus on an offer that is rooted in free (as in freedom) solutions and human decency12.

Due to all of the above, I intend to move Sudo Make Me a CTO over to Ghost in the upcoming months.

I still have to figure out most of the details, but the decision has been made. By doing that, I’ll be supporting a true OSS project by giving money a non-profit foundation based outside of the US.

The main downside of Ghost is that it comes with a monthly recurring cost, even for free newsletters. That’s reasonable, as there are infrastructure and operational costs involved with hosting the content and shipping thousands of emails each month.

It's either that, or you can self-host it. But I’m not really into self-hosting email-related services in 2025.

This means I’ll need to find a way to cover those costs, which for the current ~10K subscribers would set me back approx $90/month. Overall, not a big deal. But significant enough to convince me to test a slightly different approach.

I will be adding paid tiers, with a twist.

None of them will be required to access all the written content. In other words, no article, present or future, will end up behind a paywall, as that would be against my intentions.

I think about these tiers instead as ways for loyal readers to signal their support. I might add in special perks such as 1to1 sessions for yearly subscriptions or something similar, but the newsletter content will stay free for everyone.

I’ll start with a test for that model right here on Substack, as a way to gauge the viability of the model.

Starting from this issue, you’ll see occasional buttons and links inviting you to upgrade to a supporter-paid plan. I intend to be transparent about the number of people upgrading to paid tier(s), without violating anyone's privacy.

As these things go, the more people who support with a paid subscription, the more time I’ll be able to prioritise newsletter content over other activities.

By becoming a paid subcriber you’ll not only support my work, but make it available for free to people who might not be able to afford to pay for valuable content.

Now, there is an annoying limitation with Substack (one of many).

It imposes a minimum price of €5/month or €50/year for paid plans.

While I intend to make cheaper plans when moving over to Ghost13, this is what we’ll need to start with.

So, if you’ve been enjoying the content and would like to support my work, please consider upgrading to a supporting tier.

If you don’t, you’ll still be able to access all the content as before. No hard feelings :)

Looking forward to seeing the first results of this pre-migration test.

Thanks in advance to all those who will decide to support!

Are you old enough to remember using their service and following their rise and fall?

Whether you remember or you have no idea what I’m talking about, here is a brief recap of this pivotal case in the history of the Internet and copyright.

The history of Napster

Napster was the first major proprietary peer-to-peer service launched in June 1999. It quickly gained massive popularity across the Internet as it became the de facto standard for MP3 file sharing. In other words, Napster played a key role in democratising online music piracy. And yes, that was the last century.

For the sake of today’s article and what’s currently happening in the dumpster fire we call the tech industry, two aspects of Napster's history are particularly interesting.

The first one is that this was a fairly small startup in an era when Internet investments were starting to become a thing (the dot-com bubble occurred around that time). There was still absolutely nothing fancy about the computer technology. Not yet. Smartphones didn’t exist yet. Social Networks didn’t exist yet. And most people were not connected to the internet. Those were the good days.

Not only was Napster a small company even for 1999 standards, but it was also offering the service entirely for free. They were not making a dime out of it.

The second aspect is that, although Napster was in clear violation of copyright by promoting the exchange of licensed music, something illegal and unethical, it was doing that with what you could define as a Robin Hood-esque approach. They were stealing from the “rich”, in this case, the music labels, to give to the “poor”, in this case, the end users who found that the price they had to pay for music was too high.

In the discourse that opposed the supporters of the freedom to share music and those who consider an atrocious felony to be punished, the music labels often played the role of the greedy villains.

Many considered that artists were, in fact, exploited by the labels, who generally kept the big slice of the sales revenue pie while passing over peanuts to those responsible for creating the actual asset being sold. Somewhat similar to what's happening today with artists and streaming platforms.

In that context, Napster had emerged as a way to make music more accessible. But by doing so, it had a direct negative impact on the interests of music labels first, and secondarily on the interests of the actual artists. Some artists vocally opposed online file sharing, while others actively promoted it. Some even claimed that the broad exposure helped drive more sales and concert tickets.1

Despite the material benefits for the end users, who got to listen to music essentially for free, and the supposed and questionable benefit for some artists, who claimed increased exposure through making their music available for free, this was a clear case of copyright infringement.

One that had been perpetrated by a small actor going up against big corporations with deep pockets and an army of lawyers.

I’m not trying to make a point in defence of what Napster did, but merely to outline the whole context and the powers at play back in the early days of the Internet.

As you can imagine, it didn’t take long for lawsuits to start flocking in, and Napster, in its original Robin Hood-esque incarnation, had to shut operations a couple of years after launching, in 2002.2

End result:

• Big Corporation: 1;

• Disruptive Tech Company: 0;

• End users: meh;

• Artists: calling victory, all the while ignoring what would come next, i.e., the next stage of exploitation coming through the yet-to-be-invented streaming platform.

But why am I telling you about this minor anecdote from the Stone Age of The Internet Economy, as people liked to say around the turn of the Millennium?

For two reasons.

The first one is that today we’re facing another major case of large-scale copyright violation, though with some key differences that make it a lot less obvious to large parts of the population.

The second one is that I’ve noticed online media outlets have recently talked about the possibility that the “AI industry might be facing its Napster moment”3, and I think they are getting the whole thing backwards.

Who said large-scale copyright violation?

At this point in the article, the IANAL4 disclaimer becomes necessary.

Please treat what follows as my personal opinions, not as sound legal advice on the matter of copyright.

X: So, what is this large-scale copyright violation thing you’re talking about?5

In case you have had the luxury of living on a remote island with no internet, no phones, and no contact with the outside civilization for about 3,5 years, let me tell you how much I envy your situation. The rest of us had to endure the second major pandemic humanity has suffered from in this decade, shortly after Covid-19: GenAI-induced mass euphoria.

Besides large swathes of GPUs and embarrassing amounts of electricity, to train a Large Language Model, two key ingredients are required.

1. The actual algorithms and processes used to train what is called a Large Language Model. Arguably, the proprietary component of such artifacts.

2. A huge amount of training data, which is harvested through all sorts of sources. Without the training data, the artefact from point 1 would be about as useful as the most expensive Tesla on a remote island with no access to electricity.6

Now, big tech, and particularly the broligarchs running them, seem to be obsessed with two things7. Keeping score about who is the richest man8, and speed.

Every time regulations or ethical considerations try to slow them down, they dismiss those attempts by accusing governments of stifling innovation and similar handwavy bullshit.9

The best way to go fast in this bizarre Silicon Valley version of keeping up with the Joneses10, when it comes to collecting the vast amount of training data needed to train AI models, is to just grab everything you can find on the internet without asking for permission from the respective authors, and shovel it into the figurative voracious stomach of their shiny training pipelines. You then finally ship the result, call it a revolutionary product, and have people pay for access as if you had all the rights to do so.

And this is exactly what has been happening for longer than Napster managed to operate as a business some twenty-five years ago.

Despite the massive amount of funding they all raised, AI companies have been systematically stealing (in the worst cases) or borrowing without consent (in the mildest cases) content from writers, professors, programmers, and artists to train models that they’re charging users to get access to. Content that is essential for such models to have any (largely overstated) form of usefulness, without which they’d be little more than lab rats with expensive GPU implants.

Of course, there are a whole bunch of lawsuits that have either been settled or are ongoing. This issue is far from being solved, but this is where I think the media calling it the Napster moment for AI companies is getting it wrong.

They are not considering the major shift in power balance that has happened in the past 25 years.

In the case of Napster, the plaintiff (music labels) was the Goliath capable of squeezing the powerless David/Robin Hood with the simple deployment of an army of highly paid lawyers and lobbyists. Napster didn’t have the lobbying power, the government support, or the legal resources to stand the fight. And that’s why they quickly capitulated.

In the case of authors, artists, or programmers facing the large-scale theft from AI companies, the balance is reversed. The plaintiff, or dare I say the victim, is the proverbial David. Those with the lobbying power, government support, and financial and legal resources to drag on lawsuits indefinitely, and accept some fines that are little more than rounding errors on their PNLs are the actual perpetrators11.

That’s why I call this a reverse Napster maneuver.

Where the pioneers of file-sharing were taking from the few to redistribute to the masses, AI companies are doing the exact opposite. They are stealing from a vast amount of individuals and concentrating the wealth resulting from the theft in the hands of the few.

You might have heard the common line of defence against this accusation, that LLMs do not copy the original content. They repurpose and remix it so that the derivative work it generates is “sufficiently differentiated” from the originals used in its training.

The problem with that line is that it’s not true, and the fact that training data and models are all considered trade secrets - hilarious when you consider that AI companies do not literally own the training data, and that a lot of it is distributed with copyleft licenses that explicitly require them to be redistributed in the same way - is only making it easier for AI companies to conceal the truth.

And Marc Andreesen saying “Imposing the cost of actual or potential copyright liability on the creators of AI models will either kill or significantly hamper their development,” is not a reasonable request for exemption, but a blatant admission of guilt.

Claiming this is fair use is forgetting one important aspect: fair for whom?

The fallacy of the analogy with the origins of the Internet

The most common rebuttal I hear from optimists and boosters when they’re faced with the ethical implications of GenAI creation and usage is an embarrassing strawman. They usually come up with one form or another of analogy with the origins of the Internet. They say that people back then wrongly blamed the underlying technology for being responsible for the illegal uses a few people made of it, commonly citing piracy, drug trafficking, or child pornography. That we should not “ban” the Internet on the premise of its usage by a minority of bad actors.

In my view, that analogy doesn't stand for two main reasons12:

• First of all, I’m not attacking the underlying technology or blaming it for the way it’s being used. Science and experimentation should exist. The technical definition of an LLM is not more or less harmful than a peer-to-peer network of computing devices connected through a common protocol that spans the entire globe. I'm attacking the industry that benefits from such technology. There is a clear ontological difference between the Internet, a piece of shared infrastructure and largely decentralised in its original intentions, and a handful of powerful and rich companies that are deploying technologies with a very clear purpose. It’s that purpose and the means used to achieve it that I’m criticising here, not the OS they might use on their personal devices.

• Secondly, illegal and unethical practices only accounted for a marginal portion of Internet usage13, while most of its usage was arguably beneficial for plenty of actors. In the case of the current GenAI-based industry, the whole industry is founded on illegal and unethical activities. To go back to the original analogy, it’s as if drug dealers, arms traffickers, scammers, and organised crime cartels operated the Internet and benefited from anyone using it, even for seemingly benevolent activities. Would the benefit of such good actions be significant enough to outweigh the drawbacks of the industry they'd be indirectly fueling?
  Pablo Escobar did build schools and create jobs for people in Colombia14, but that’s not enough of a good deed to justify the means by which he financed his philanthropic endeavours. The recent announcement from Google AI Studio to sponsor Tailwind is just another example of the Silicon Valley-washed version of Escobar’s charity deeds.15

I’d like to offer a more fitting analogy instead.

What if AI companies didn’t steal all the content they did to train their models, but instead stole all the compute capacity for it? What if they literally stole thousands of NVIDIA GPUs from the pockets of Jensen Huang’s leather jacket instead of paying him what they’re supposedly worth?

How different would we look at the case? Would we consider it far worse, as it involves physical goods? As if hardware had more intrinsic value than software, as in intangible artifacts?

Or would we consider it fair use, as it would just be billionaires stealing from each other, leaving them to solve their issues once they’ve all finally migrated to Mars?

Would we just dismiss the issue, paraphrasing Marc Andreessen’s words by saying that the value of AI companies would be significantly lower if they had to follow the current laws on private property applied to a special category of expensive hardware they’re in dire need of to operate?

Similarly, wouldn’t drug trafficking be significantly less lucrative if it were regulated and dealers had to pay taxes on their revenues, only sell to adults, and regularly inspect the quality of the product they sell? Would that be an argument in favour of accepting trafficking in its criminal form because that makes it more lucrative for shareholders and investors?

This isn’t an argument in favour of drug legalization.

It’s an argument against the perverse capitalistic idea that we should allow companies to deliberately disrespect and not follow existing laws solely on the premise that doing so would negatively affect the company’s valuation.

If this isn’t peak-level arrogance and insanity, I don’t know what is.16

Where do we go from here?

I guess the first step is to ask ourselves whether we want to actively support this industry. As I wrote about it in a previous post, that’s hard, and it doesn’t come without sacrifices.

I’m particularly worried about radical purist and punitive takes on the topic.

While I do understand the original intention behind the “open slopware” repository17 born with the intention of providing transparency on FLOSS projects “tainted” by AI-generated code, I believe it tragically missed the mark.

It’s not by shaming open source contributors using AI code assistants that we’ll get the discourse to advance. I found it akin to shaming drug addicts for being responsible for the crime related to drug dealing.

We should inform rather than shame.

We should lobby with regulators to ensure those in positions of power are held accountable.

We should be positive examples through our actions, as directly attacking peers is a comfortable act, but one that rarely leads to changing people’s minds.

While I very rarely open up chatbots (my most common use case is for finding my way around the abysmal user unfriendliness of Excel/Google Spreadsheet formulas and error messages), I do use Windsurf on a pseudo-regular basis for personal needs or to help me make open source contributions by helping me reason about a codebase I am not familiar with, or a language I’ve not used for a long time.

If anything, I do believe that using such tools to make FLOSS contributions is an OK way to give back what has been taken away. Certainly, it doesn’t solve the underlying problem, but if everybody did it consistently, it might become a good act of active resistance.

In a creative but not so extreme take, you could argue that all LLMs have been trained on code distributed under various copyleft licenses that impose obligations on its redistribution. The evidence of memorization and plagiarism could support the case for considering trained models as derivative work of that original copyleft code. As such, the entire model and all its output should be treated accordingly and forced to be distributed under an open source license.

What Baldur Bjarnasson in The Intelligence Illusion mentioned as one of LLMs’ dangers for business, namely the risk of accidentally introducing GPL code into a proprietary codebase with the consequences that that would entail, might turn out to be a feature.

Certainly, enforcing an open license on all commercial models and all the output generated could have massive effects, ones that our friend Marc Andreessen might fear would negatively impact companies’ valuations. At least the valuation of those companies that are ignoring the rules of copyright and code licensing, until they provide substantial evidence that either they’re not using any copyleft-licensed material in their training set, or that they can guarantee 100% that there is no chance of plagiarism in LLM output.

I’m willing to bet that they’d either be unwilling or unable to do so, or both.

An ever more interesting approach would require regulations to be introduced that would force providers of LLM models to adhere to the following set of rules:

• Transparency on what data is included in their training set. The list should be publicly accessible and browsable. Its content should be auditable by government authorities at any time.

• Enforce opt-in requirements from authors to allow their artefacts to be included in a training dataset. Without explicit opt-in, a piece of content should be assumed not usable for AI model training by default.

• Opt-out mechanisms similar to those enforced by GDPR, de facto treating copyrighted material as a modern sibling of Personal Identifiable Information. This would mean the right to data deletion, which should require companies to retrain their models every time a piece of content is the subject of a removal request. This one is going to be fun to implement.

• Transparent instrumentation and observability to track every time each specific piece of content is referenced or used as input material for generating a response, and establish a royalty redistribution mechanism similar to the one used by the music streaming platforms. Before you scream that this would introduce an insane amount of complexity, let me stop you. I know. But aren’t these the companies attracting the best and highest-paid talent, and raising billions in funding? If tracking events and lineage is too hard a problem for them, then I don’t know how they’ll ever get to AGI. They can always use Claude Code to solve the problem.

• Cherry on top: all the models and their generated output should be subject to the most viral license used among the different artifacts present in the training dataset. Meaning that if there is a single piece of GPL-3 code in there, everything should be redistributed under the same license, following the principle of derivative work.

This might undermine the wet dreams of big fortunes and power that are driving a lot of the investors in the space, but might actually make this a technology that serves as a means of fairly redistributing the wealth generated by collective work.

How about that approach for the betterment of humanity?

Want to talk about this?

In a previous article, I mentioned the intention of kicking off a Luddites in Tech group, where I’ve invited actors in the tech space who share a certain sensibility to the topic of ethics and human decency across this industry.

I’ll soon organise the first meetup, and everyone is welcome to join in.

I do expect that the first chat will touch on defining a clear purpose for the group, and maybe talk about the topic of how to kick off a distributed form of lobbying with lawmakers and push for regulation against this large-scale copyright theft. I’m particularly interested in exploring ways to connect with EU lawmakers in this space, as I’m convinced the first push will come from there.

Happy to be proven wrong, but I wouldn’t bet my money on that.

Even if that specific conversation doesn’t end up anywhere concrete, it will help us advance our collective understanding of what we can or cannot do to influence the industry towards a better direction.

If you’re interested in joining the conversation, just reply to this email or send me a DM here, on LinkedIn, or on Bluesky, and I’ll make sure to include you in the first invitation.

The more, the merrier.

WIT Promo for Q1 2026

I’ve recently decided to resume offering Quarterly promos for people who are willing to benefit from my services.

I’m happy to announce that I’ve opened up the Q1 promo that will run until the end of March 2026.

I’m making it easier for Women in Tech to level up their engineering leadership skills by offering an exclusive discount to the Sudo Make Me a CTO: 30% off for the first 12 months.

You can find out all the details at the official promo page, or by clicking the button below.

WIT Promo 2026

Feel free to share this opportunity with people you know, and do not hesitate to reach out if you’d like to learn more about it.

You can always schedule a free 30-minute session to get all your questions addressed.

Looking forward to seeing the community grow with more diversity.

11

This article is already becoming a collection of footnotes. But if you want to have a clear example of what I'm referring to, check out this great article by .

Blood in the Machine

Don't forget what Silicon Valley tried to do

Greetings all…

Read more

10 months ago · 126 likes · 16 comments · Brian Merchant

Reading good books is a great way to broaden your knowledge and perspectives.

Reflecting on the books I read every month helps me cement the key learnings from each one of them.

What's better than recommending someone else a good book?

Recommending two, three, or five good books!

Here we are with the December edition of the books I read last month!

If you end up reading one of them, please let me know in the comments section.

💫 Book Highlight: Wardley Maps by Simon Wardley

Wardley Maps, by Simon Wardley

709 pages, First Published: August 8, 2016

When I read Architecture for Flow last October, one of the aspects that triggered my curiosity the most was its coverage of the practice of Wardley Mapping.

So, one of the first things I did after finishing the book was to practice with this technique, and I published my first attempts in a recent article.

Having gone through the amazing primer from Susanne Kaine and the first attempts at my own mapping, I quickly decided to order the printed version of the original book from Simon Wardley himself, which I read during December.

I was not disappointed. I was rather blown away by the depth and information density of this book. Even more so if you consider that it’s available for free in PDF format online and that it’s released under Creative Commons. Hats off to Simon Wardley on the open gameplay here!

I still decided to go with the paper version, as I was predicting I’d need to scribble on it quite a lot, which ended up being a correct prediction.

This has probably been the most insightful strategy book I’ve ever read. Every chapter could almost be developed into its own book, with very few exceptions. Something that makes it very hard to capture its essence in a few paragraphs, but I’ll still try.

After reading it, I believe Wardley Maps should be the reference book for anyone dealing with business strategy, and particularly in businesses related to technology. It should be a textbook for any MBA who is serious about providing solid foundations for future strategic decision makers.

The book is the result of years of research combined with firsthand experience from the author. It explains in depth the key concept of evolution and how to surface weak signals predicting evolution trajectories. It covers in depth the doctrines that are relevant for different evolutionary stages, climatic patterns, and gameplays to be applied in different situations.

As you read through all the material, you gradually begin to understand the depth and density of information that can be conveyed through a single map.

That includes the somewhat disappointing realization that maps do not provide answers by themselves.

They serve as a way to make assumptions visible, improve situational awareness through exploration, and facilitate the discussion around the strategic decisions to take through a very articulated shared language.

The only downer of the book is that upon finishing it, I realized I know very little about the topics covered, and that I’ll need to make up for it through a lot of practice. Or rather, it made me realize that until I read the full book, I had a somewhat simplistic understanding of the tool and its foundations. I guess it was an exemplary manifestation of the Dunning-Kruger effect. Shame on me!

Besides the shameful realization, the second downer was the fact that the last chapter of the book talks about the following 11 chapters on gameplays that apparently have yet to be written. Or maybe they never will? At least this is not a case of the author dying prematurely before having an opportunity to finish their masterpiece, so I guess there is still hope.

That said, I highly recommend that anyone who has to deal with strategic decisions, and most leaders should, spend some time reading this book.

Maybe start with the online version if you do not want to commit too much in advance, and see where it leads you.

📚 Other Books I Read in November

V13 by Emmanuel Carrère

V13, by Emmanuel Carrère

368 pages, First Published: January 1, 2022

On November 13th, 2015, France suffered a dramatic terrorist attack perpetrated by nine members of the Islamic State terrorist group. This was a coordinated attack that hit at three different locations: outside the Stade de France stadium, in the concert hall Bataclan, and in an area full of crowded bars and restaurants. 130 people lost their lives in the attack, and many more have been injured.

V13 (from Vendredi 13, or Friday the 13th) is the chronicle of the trial that took place between September 2021 and June 2022 of all the surviving members of the commando that organized and then executed the attack.

Carrère followed the whole trial for the French weekly magazine Le Nouvel Obs1, and later used the material to publish the V13 book.

While I like most of what Carrère has written, this one definitely falls among my favorites. It reminded me of L’Adversaire, in which he followed another crime case, but this one is on a completely different scale. Carrère’s recollections of the various stories of victims and perpetrators, lawyers and prosecutors, make this book a choral opus, only dramatically true rather than fictional.

I learned a lot about the details of the attack and the people directly or indirectly involved with it. I learned a lot about the experiences of those who survived the attacks. Those who risked their lives to save others. Those who felt or feel guilty for having survived while many others have died. And those who felt or feel ashamed for having saved themselves rather than helping others.

Throughout the whole book, Carrère is very mindful of suspending any form of judgment in his recollection of the events, leaving that part to the actual judge who will read the sentence at the end of the trial. He prefers the humble and noble attempt at trying to understand what happened from the eyes of those who lived through such dramatic events.

It’s a great display of humanity, violently contrasting with the inhumane events that the trial was requested to judge.

Nobody Cares (Until you do) by Salem Thyne and Robert Hunt

Nobody Cares (until you do), by Salem Thyne and Robert Hunt

200 pages, First Published: September 12, 2022

I was looking forward to reading this book, as it had been recommended to me, and it promised to deliver a lot of valuable insights on the topic of accountability.

Geez, what a disappointment!

I found it shallow and repetitive. It doesn’t give credit to authors who have been exploring the same concepts with more depth. And finally, it seems to be written by people who believe they’re building a sales funnel via a landing page, not a book.

I don’t know whether it works for the authors, but this idea of including, every few chapters, a call-to-action page inviting readers to take a picture of the book and share it on social media is just a big disqualifier for me.

When a book starts copying the tactics of online media, I take it as a signal that the book in question, and its author, has lost its bearings. It almost felt like the idea of enshittification applied to books.

While we might have gotten used to seeing constant nudges and CTAs on online websites, that doesn’t mean we should accept the same type of experience being baked into books. Finding these misplaced nudges in Nobody Cares reminded me of the worst book I’ve ever laid my hands and eyes on a few years ago. Such an embarrassing experience that I’m still recovering from it.

One day I might be able to talk about it, but not yet.

So, dear reader, instead of taking a picture of the book, uploading it to social media, and inviting all your friends to buy a copy, I recommend you stay away from it.

If you really want to read something on the subject, I do recommend the classic 7 Habits of Highly Effective People from Steven Covey instead.

This might be the first genuine case of me stating, “I’ve been investing a certain number of hours reading this book, so you don’t have to.”

Not as a way to offer you a lazy shortcut to learning its key concepts, as it’s often the case with such statements. But as a kind gesture to avoid you wasting your precious time.

And now you might want to take a picture of you reading this article, share it on social media, send it to Santa (or whatever imaginary gift-bearing creature is most popular where you live), and ask them to subscribe to my newsletter.

Launching the WIT Promo for Q1 2026

I've recently decided to resume offering Quarterly promos for people who are willing to benefit from my services.

I'm happy to announce that I've opened up the Q1 promo that will run until the end of March 2026.

I'm making it easier for Women in Tech to level up their engineering leadership skills by offering an exclusive discount to the Sudo Make Me a CTO: 30% off for the first 12 months.

You can find out all the details at the official promo page, or by clicking the button below.

WIT Promo 2026

Feel free to share this opportunity with people you know, and do not hesitate to reach out if you'd like to learn more about it.

You can always schedule a free 30-minute session to get all your questions addressed.

Looking forward to seeing the community grow with more diversity.

At the same time, I don’t believe in the popular ‘new year’s resolution’ approach, as it tends to be based on wishful thinking, lacks a system to ensure you’re setting reasonable goals, and that you’ll be following up with them.

Even when people have a system for setting their goals, I see them falling into two common pitfalls:

1. They set too many goals, and lose focus and the ability to make significant improvements

2. They tend to focus entirely on one dimension or area, typically their job, forgetting that our professions are only a part of a meaningful life and should contribute to it, not the other way around.

During December, I held two sessions with the members of the Sudo Make Me a CTO Community in which I guided them through the process of setting their 2026 and then their Q1 goals.

In today’s article, I’m going to illustrate the process we followed.

If you’d rather watch the recordings from the community sessions, you can sign up today and gain immediate access to all past sessions. That’s also a great way to support this newsletter!

I do recommend you first read the whole article to get a sense of the process, and then set aside some time to follow the approach, as this will require quite a bit of work on your end if you really want to get good results.

You should block 60 to 90 minutes for the whole exercise.

The 4 buckets of life

As already mentioned, we often tend to focus exclusively on our job or career, forgetting that it’s only one dimension of our lives. Health, relationships, and betterment of self are all important aspects of a life well lived. Cal Newport, an author who has been influential in shaping my perspective on planning and intentionality, has introduced the concept of the 4 buckets of life: Constitution, Community, Craft, and Contemplation.

They can roughly be described as follows:

• Constitution: Anything that has to do with health, fitness, mental state, or overall physical well-being.

• Community: Connection and relationships with family, friends, networks of shared interests, etc.

• Craft: Our professional aptitudes related to our current job, career development, leadership skills, technical skills, etc.

• Contemplation: This one has to do with cultivating our values, hobbies, spiritual life, or more general personal improvement through educating ourselves in topics unrelated to our careers.

One of the first mistakes people make when they set goals, and even more when they don’t, is that they tend to focus on the Craft bucket and sacrifice, deliberately or accidentally, all the others.

That's why in the following steps, we'll be looking at all four of them.

Look back at 2025

The best way to understand whether you’ve been dedicating a reasonable amount of energy and attention to each one of the buckets, the goal-setting exercise for 2026 must start with a bit of retrospective.

Take a piece of paper or an electronic document, and for each one of the 4 buckets mentioned above, write down the following assessment:

• Overall rating: Assess your satisfaction with the progress or overall situation with the bucket during 2025. Do you feel you dedicated enough time and attention to it? Do you think you’ve been neglecting it? Rate it with a score from 1 to 5, with 1 being the lowest level of satisfaction. Nobody else is going to see this, so do not lie to yourself. The more honest you are, the more helpful this exercise will be.

• Energy Gainer: What is one thing that gave you energy in this bucket during the last year?

• Energy Drainer: What is one thing that drained your energy in this bucket during the last year?

Once you’ve done this, look at your lowest score, and think about why things went the way they did, and what it would have taken for you to give a higher score. This first reflection should inform and influence how you're going to look forward at the following period.

Setting the 2026 Yearly Goals

Now that you’ve come to terms with your 2025, let’s switch our attention to the future. We will run through a few iterations to draw your final list of goals for 2026.

The first step takes a common expansive approach.

For each one of the four buckets, write down a list of 3 goals, things you would like to achieve, in 2026. Make sure you frame them as outcomes, not as activities. Use the SMART approach to ensure those are “good” goals1.

As an example, “exercise more” is not a good goal. “Run a half-marathon before the end of the year” is. Similarly, “write more code” is not a good one. Instead, “Make a PR contribution to open source projects at least once per month” is a good one.

After about 15-20 minutes, you should have a list of your 12 goals for 2026. Congrats, this is an important step, but we’re far from done!

Do you remember when, in the introduction, I mentioned that we have the annoying tendency to choose too many goals, setting ourselves up for failure? Trying to achieve significant results on twelve different goals in a year falls in that category.

I want you to be ruthlessly prioritising, and that requires you to sacrifice things. Without it, you'll still end up having to sacrifice some of them, but you'd be doing it reactively, and typically sacrificing the important for the urgent. The advantage of early prioritisation is that you will be deciding up front what you think is worth sacrificing, and what you want to protect at all costs. Again, planning is an exercise in making a more deliberate use of your time.

So, take that list of 12 goals, and for each one of the four buckets, identify the most important one. Not two or three. One. Circle, underline, or highlight them. These are now your four goals for 2026. That’s a lot more tractable than the original list of twelve!

What should you do with the remaining 8 goals?

You should treat them as an “Avoid at all costs” list2. While still interesting, these goals can become dangerous distractions. They are the common source of productive procrastination, which we typically pick up whenever we’re struggling to make progress on our main goal. Ensure you stay away from them at least until you have achieved your primary goal.

One more thing: though four goals in a year seem to be a reasonable target, life has an irritating tendency to throw curveballs at us.

When the proverbial shit hits the fan, you will want to focus all your energy where it matters most. For this reason, I do recommend you take an additional step in finalising your yearly goals. Look at the four goals you’ve set, and ask yourself the following question: if something happens that will take away a lot of my energy (and most likely it will), which one of these four goals and buckets I am willing to sacrifice? Think about it, and mark the one that you would be willing to temporarily neglect or drop completely if something unexpected occurs.

At this point, you should have a nice list of 3+1 goals for 2026. Seems doable, right?

Yes, unless you do as many people do: stop here, and forget about the goals until you get to the end-of-year retrospective.

Setting Quarterly Milestones

The yearly horizon is great to set meaningful goals, but it’s too far away in the future to be actionable on a smaller scale. That’s why it’s important to plan on multiple horizons. While we’re going to explore some aspects of a full system in the following paragraphs, I do recommend you also read the article in which I illustrated the whole system I use to plan and execute at multiple time scales.

A good way to think about different time horizons is illustrated in the following picture

Now that you have your list of four goals for 2026, I want you to bring them down to the quarterly level first, and later to the weekly horizon.

Let's tackle Q1 first.

For each one of your yearly goals, you should identify the key milestone for Q1. What’s the single most important milestone you want to achieve by then? Achieving is the keyword here. These should be measurable outcomes, similar to the ones you set at the yearly level, but more granular and likely incremental. See the picture above with the marathon running target for an example.

An example from the Craft bucket that would be relevant for you could be the following:

• Yearly Goal: Define, socialise, and get buy-in on an updated tech strategy for our company for the next three years

• Q1 Milestone: Have a set of Wardley Maps and a Domain Map covering all business aspects of our company, produced with the contribution of all Staff+ and Managers in the team, key stakeholders, and business domain experts.

I’m making things up, of course, as depending on your situation, taking a year to develop a strategy might be completely unreasonable. It’s an example to make it more relatable, not a suggestion or recommendation.

It’s important to note that you will need to repeat this part of the exercise every quarter. I do recommend doing it in the last couple of weeks of each quarter.

So far, we’ve covered the what to achieve part, but not how to get there.

That's what we'll be focusing on next.

Building the System

Having a system is essential to ensuring you’re actually going to deliver and make progress on the targets you’ve set for yourself.

You can come up with something very sophisticated, but in its simplest for,m such a system will require two elements.

The first one requires you to set aside time for making progress on your goals. I want you to look at your calendar and think about how you can structure your ideal week so that you have recurring time slots in there to make progress on your quarterly goals.

This should become your template for the ideal week, to which you'll be making adjustments as needed when you plan each week. My recommendation is to set aside specific recurring blocks on your digital calendar and have them reserved in advance. Alternatively, you can settle for writing down a set of rules you’ll be following through the quarter, in the same place where you have defined your goals.

For example, you could have something like the following list of rules.

• To hit my goal of developing a comprehensive strategy for my team, I’ll block 2 hours first thing in the morning every Tuesday and Thursday.

• Every other Thursday, I’ll have dinner out with my partner.

• On Monday, Wednesday, and Friday morning, I’ll take a 1-hour walk in the park

One advantage of blocking these directly on your calendar is that it keeps you real, as you quickly see if you’re trying to cram too much stuff on it. If this is the first time you try this exercise, I do recommend you start small and increase the ambition level as you gain more practice and confidence.

The second part of the system is a recurring check-in on your goals. You need to answer the following simple question: how and when am I going to check in with my goals?

I do recommend finding a weekly slot and putting it on your calendar. This space will be fundamental for you to assess whether you’re making progress, whether your schedule is working, and whether you need to make any changes to it.

That's it, now you have your system in place and are ready to get cranking on those goals.

Get going!

If you’ve followed along, at this point you will have:

• 4 (or 3+1) yearly goals for 2026

• 4 Q1 2026 goals

• A few key weekly habits booked on your calendar, ideally one per bucket

• A weekly check-in routine

The hard part begins now, and it’s about building the discipline to stick with your goals and system once the initial excitement has tapered away. I do recommend you share your goals and efforts with others to help you find accountability partners. That’s what we’ll be doing in the Sudo Make Me a CTO Community, where we’ll be checking in with everyone’s goals once a month during our live sessions.

Making this journey together with others increases your chances of success. If you're really serious about achieving your goals in 2026, you might want to consider joining us to benefit from this additional support.

I wish you a great 2026, one in which you’ll make significant progress in all areas of your life that matter!

Help keep this newsletter free

I love writing this newsletter, and I intend to keep it free forever.

If you want to support my work, you can engage with me in one of the following ways:

1. If you need help with your Startup, Company, or team, I can support through advisory or fractional services. Find out more on this page.

2. If you need personal support to overcome challenges and grow as an engineering leader, I can support you through Mentoring and Coaching. Find out more on this page.

3. If you are looking for continued support and the chance of joining a thriving community of like-minded people, I host a Community for engineering leaders. Find out more on this page.

If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.

Reading good books is a great way to broaden your knowledge and perspectives.

Reflecting on the books I read every month helps me cement the key learnings from each one of them.

What better than recommending someone else a good book?

Recommending two, three, or five good books!

Here we are with the November edition of the books I read last month!

If you end up reading one of them, please let me know in the comments section.

💫 Book Highlight: Dynamic Reteaming by Heidi Helfand

Dynamic Reteaming, by Heidi Helfand

294 pages, First Published: July 31, 2019

I had heard about this book a few times in the past, but what convinced me to read it was noticing that it was mentioned a few times in the Architecture for Flow book by Susanne Kaiser. BTW, I really enjoyed that book, in case you missed it.

Given how much I liked Kaiser's book and how it inspired me—among other things—to pick up Wardley Mapping, I thought it was finally time to pop it to the top of my reading list and went through it as one of my three books for November. I read the second edition, which came out recently.

My overall verdict: it’s a good book, but it didn’t impress me.

While most, if not all, of the content is relevant and well articulated, I rarely found anything truly novel in it, something that would make me stop and think.

This is as much a feature of the book as it is a feature of the reader. I genuinely believe the content is good, but I didn’t learn a ton from it.

I found the first part on introducing the different patterns a bit too long, but the second part has been significantly more enjoyable for me to read. Particularly chapters 11 to 14, where Helfand describes more of the how of transformation and reorganizations, and provides a lot of helpful frameworks and approaches on how to navigate those changes effectively.

To give the book justice, I’m probably not the main target. I had the “luxury” of having to go through a whole bunch of reorganizations throughout my career. Sometimes on the receiving end, sometimes on the other end, and very often in between: working together with the senior leadership to make things happen. While we didn’t necessarily speak the language of the patterns identified by Heidi Helfand, we definitely used many of the approaches described in the book.

It’s often said that the value of defining patterns lies more in their ability to formalize common knowledge and good practice than in coming up with novel concepts. In other words, patterns are generally more descriptive than prescriptive. In that sense, the book does a good job of putting names to commonly used practices of team reorganization and evolution.

The part that I may have found the most interesting is the idea of Team Choice Marketplace, mentioned extensively in the book, to which the entire Appendix A is devoted.

It might sound weird and unfairly dismissive to state that my favorite part of a book was the appendix, but sometimes that happens. It’s an idea that really caught my attention, particularly because I’ve never really used it in such a form.

Would I recommend this book? It depends.

It depends primarily on your trajectory and your current situation. If you’ve been through a lot of not-completely-catastrophic reorganizations, you might find here a little more than a good way to reflect back on those moments and recognize things you’ve done well and those you could have done better.

If, on the contrary, you’re relatively new to the ins and outs of team reorganization, this book would be a great resource, as it’ll give you plenty of references and ideas on how to approach them going forward.

Personally, this is a book I’m happy I finally went on to read, as it helps me refine my vocabulary around the topic.

I also believe it’s one of those resources I’ll refer back to when the need arises to apply its core concepts. More of a reference manual than a conceptual book, if you get what I mean.

📚 Other Books I Read in November

Entre Deux Mondes by Olivier Norek

Entre Deux Mondes, by Olivier Norek

324 pages, First Published: October 5, 2017

That’s it. With Entre Deux Mondes, I’ve read all the books written by Norek to date. What a shame, I really love them.

Entre Deux Mondes is no exception. It’s another of those works that leave me with a profound sense of admiration and respect for the author. As usual, to write the book, Norek spent a lot of time in the environment that serves as its main background. Except that this time we’re talking about what became known as the jungle, a barely tolerated immigrant and refugee camp in Calais1. Apparently, Norek spent a significant amount of time in Calais and in the jungle. Interacting with the refugees there, learning about their lives and their goal: crossing the British Channel and landing in the UK. He also spent a significant amount of time with members of various NGOs and the local police.

The result of his personal investigation is a dark, moving, and obscenely well-written book called Entre Deux Mondes, meaning “between two worlds.” I’ll pass the details on the plot and focus on the main point. This book is dark, profoundly dark. It’s a powerful, and somewhat shameful, reminder of the conditions many of our fellow humans have to endure on this planet, whose only fault is to be born in a country where a decent life of peace and safety is largely impossible.

While the jungle, the place, was dismantled about a decade ago, Norek gives us a good reminder that we should not take a decent life for granted.

I don’t have an easy solution to offer for that without falling into populist claims, but I wholeheartedly recommend every decent human person on this planet to read Entre Deux Mondes and have a genuine conversation with themselves on how we could make this place just a tiny fraction less shitty for people in dire situations.

La Moustache by Emmanuel Carrère

La Moustache, by Emmanuel Carrère

192 pages, First Published: June 3, 1986

Carrère, along with Norek, is one of my favorite authors of recent months. What's funny is that the only thing they have in common is that they’re impressive French writers. And that’s it.

They seem to be otherwise completely different.

La Moustache is the first fiction book ever written by Carrère, but for some reason, I could not get my hands on a copy until recently. It’s a short book, and I devoured it in a couple of days.

It’s an engaging book. It’s also, and more importantly, a disturbing book.

At some point, I realized that, as I was reading, I had the famous Queen song “I’m going slightly mad”2, playing in a loop in my mind. Somehow, my brain had surfaced it from memory to go along with the increasingly disturbing story of the main character in La Moustache.

What is this book really about?

It’s the story of how an apparently insignificant event in one’s life can open the abyss of madness. How manipulation could be hiding everywhere, and how trusting our own mind can feel incompatible with trusting other people's words.

While the main character engages in a physical journey, the reader is mainly engaged with an inner journey in the main character’s mind. Exploring his doubts, convictions, and contradictions. His unpredictable mood swings are so well described that you might feel you’re going down a dangerous rabbit hole as you read them.

This early Carrère book showed his insane ability to marry engaging narrations with surprising introspections.

Reader, be warned: the book is really disturbing. The more it progresses, the more you’ll battle with the need to continue reading and the desire to help the main character out of the darkness they are falling into. Read it only if you’re capable of keeping a distance between what you read on the page and your own personal emotions.

I loved it, but I’m well aware that this won’t be the same for most people. I don't say that to sound elitist3, to suggest that only the highly initiated will enjoy it.

It’s just a recognition of taste and different levels of tolerance with regard to other people’s suffering in a fictitious story.

Help keep this newsletter free

I love writing this newsletter, and I intend to keep it free forever.

If you want to support my work, you can engage with me in one of the following ways:

1. If you need help with your Startup, Company, or team, I can support through advisory or fractional services. Find out more on this page.

2. If you need personal support to overcome challenges and grow as an engineering leader, I can support you through Mentoring and Coaching. Find out more on this page.

3. If you are looking for continued support and the chance of joining a thriving community of like-minded people, I host a Community for engineering leaders. Find out more on this page.

If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.

“It’s not a principle until it costs you money”.

I was coming back from one of my morning walks in the woods, listening to a podcast episode in which Cal Newport was interviewing Ryan Holiday. It immediately stuck, and I keep referring back to it when reflecting on past decisions or when approaching new ones.

This quote is attributed to Bill Bernbach, one of the co-founders of DDB, an international advertising agency.1

In 1964, after the U.S. Surgeon General issued a warning about cigarette smoking, Bill Bernbach vowed to keep his agency out of the cigarette business. One of the most profitable advertising categories in those years. That decision cost DDB a lot of money, but he stood by it.

I don’t know Bill’s full life story, but if that’s true (and not a made-up internet legend), he earned my full respect and admiration.

A few months later, a good friend of mine offered me a slightly different angle on the same underlying concept, citing a famous quote from the Dalai Lama.

“Judge your success by what you had to give up in order to get it.”

People often focus on the first degree of interpretation, which basically means that to achieve success, you’ll need to make sacrifices. No, this isn't an apology for the 9-9-6 model.

But there’s another angle to it, which is far more interesting: what are you willing to give up for your success? Or rather, what are the things you are never going to sacrifice on the altar of so-called success?

Are you willing to sacrifice your principles and moral values to become richer?

Before you raise your eyebrows and mumble something about this self-righteous dude coming with a moral lesson, let me reassure you. This is not a moral lesson. I’m not here to issue judgments on those who occasionally, sometimes, or even frequently prioritise money over values.

Unless you’re either Elon Musk or Sam Altman. Then I definitely can tell you I despise you passionately. But that’s not the point of today's article.

The point is instead to share personal examples of me struggling to apply those same principles, and sometimes succeeding.

What’s the tech industry’s purpose?

I’ve recently rewatched the seminal recent TED talk from Scott Hanselman, going by the telling title Tech Promised Everything. Did it deliver?

What I found highly relatable in his impressive talk is the combination of the insane passion he has had for technology since the early days, and his disenchantment with what the tech industry managed to do, or not do, with it. I share both of them: the early days passion, still alive, and the massive disappointment with the industry that we’re all part of.

I’ve covered the leadership aspect of it in one of my recent posts. This one looks at the tech industry more broadly.

When exactly did the ethos of the early pioneers who helped create UNIX, the Internet, and the Open Source movement, all of which were genuinely moved by the intention of making technology helpful and accessible, get replaced by the Wolf of Wall Street type of characters who eventually gave birth to the modern broligarchy?

When exactly did technology become an instrument for the concentration of power in the hands of the few, while everyone else seems to believe that a world of always-on, no privacy, fake news, and slop content is an acceptable definition of progress and prosperity?

might argue that it all began with the Industrial Revolution, and he’s probably right. But the landscape of modern internet-based technology was very different from today's until at least the early 2000s.

When I reflect on Scott Hanselman’s words and look at the state of the planet today, I can’t accept the dominant narrative that naively presents all this as progress, inevitable, and net positive.

I can’t help but ask myself: what is the purpose of all this “innovation”? Why does everybody get so worked up about “winning the arms race with China”, as if that were a universal and unquestionable goal for “the Western world”?

Why does nobody seem to stop and ask a deceivingly simple question: what should be our key priority as a species?

I’ve recently started exploring the world of Wardley Mapping as a key tool to better understand complex systems, and while doing my research on Simon Wardley, I came across one of his recent declarations that I can only subscribe to:

GPTs are a non kinetic form of warfare designed to embed the values of a small number of people into much wider communities by capturing the process of decision making. The delivery mechanism is the appearance of helpfulness i.e. coherent and authoritative arguments. The payload is helplessness and the creation of a new theocracy.2

In the same post, he also goes on to say that all the other “problems” caused by GenAI, such as copyright infringement, the induced decline in our cognitive abilities, or the impact on the environment, are just a distraction. I disagree with him on dismissing them as such. While I can agree with a certain hierarchy of problems, I don’t believe lesser problems are just distractions. They can be, if deliberately used to mask the elephant in the room. But that doesn't make them less real, and they are affecting people's lives today.

I’ve spent 25 years in the tech industry, and a bunch more than that playing with computers or otherwise programmable systems. Like Scott, I remember when we got our first Commodore 64 at home. I don’t remember exactly I old I was, but I was probably around 10. I remember the first time I installed Linux on a PC, in 1997, and feeling awe toward those mythical figures who devoted their time to creating such a powerful, instructive, and open system that anybody could use and contribute to. I remember getting my first real job in 1999, working for the first (and last) Italian Linux distribution. I was literally living the dream.

When I look at where we collectively are now as an industry, some 25 years later, I can’t help but feel that at some point we took the wrong turn in the road. captured an important aspect of it when he coined the concept of enshittification, referring to the seemingly inevitable decline in quality of online products and platforms.3 But that doesn’t cover it all.

There is another more fundamental problem that has to do with purpose, of which enshittification is just a manifestation.

Despite all the efforts of big-tech propaganda in the first two decades of the 2000s, its true purpose is becoming clearer as we progress. We might even credit the Trump administration for allowing it to get rid of its veil of hypocrisy and fully embrace and recognise its true nature, which is perfectly captured by Simon Wardley in his poignant description of what LLMs are.

The king is naked, as the old saying goes.

Now it’s up to us to decide whether it still deserves a crown. Whether we still want to be ruled by it. Whether we want to contribute to its increasing power over our lives.

A tale of saying no, twice

This is where I get back to the quote that inspired the title of this article.

For those who don’t know it, I do work as an independent consultant, coach, and wannabe community builder. The lion’s share of my yearly revenues comes from various types of consulting engagements with companies that need my services.

In the last month, I found myself saying no twice to potential new gigs.

I’m acutely aware of the difficult job market out there and of the many people who are struggling to find a job. I’m not bragging about the luxury and privilege of being able to decline a contract. Like all of us, I'm navigating a very uncertain field.

The reason I refused to engage with those offers has been the same for both cases: they were directly connected with promoting the use of AI-assisted coding tools in software development.

I said no because that to me felt akin to selling drugs to teenagers, or optimising algorithms to keep them consuming online content and target them with highly personalised advertising, which is basically the same thing. Except one of them is legal, and the other isn’t.

And let me be clear: I do not have any inherent problem with the underlying technology itself.

Technology is neutral, and can be a tool to be used (or not) under certain specific circumstances. But the tech industry is not neutral, and it’s increasingly aligned with a world view that I don’t want to actively contribute to realising.

Selling AI-related consulting to companies or individuals who are drowning in FOMO is the best definition of easy money you can find on the street in 2025, possibly after selling drugs.

Only a fool would give up the opportunity to make that easy money.

Or someone who doesn’t want to even accidentally be contributing to the prosperity of an industry so profoundly broken at its core. An industry that, day after day, looks like it needs to be rebuilt from the ground up as the only way to save us all from the dramatic deterioration of our collective lives.

I don’t judge those who enthusiastically promote the “inevitable revolution” of GenAI, but I’d love to better understand their motives, beyond the overly individualistic (capitalist) survival of the fittest argument. Or pure and simple personal gains.

But please don’t tell me AI will cure cancer and solve the climate crisis, as I still go with the original SRE motto that hope is not a strategy. Definitely don't ask your favorite chatbot to suggest an answer either.

We can certainly find better arguments than magical thinking or more slop.

Should we do something about it?

I recently watched with my two kids one of my favorite Pixar movies, WALL-E. For those who don’t know the movie or have forgotten about it, it’s a story set in a hypothetical future in which humans have basically depleted natural resources on Earth, and fled the planet on a Starship-like space-ship to “wait it out”, hoping that one day the planet might recover so that they could eventually return home.

While the movie is willingly depicting an apocalyptic and far-fetched future, it also has a Black-Mirror-esque side to it: an obvious exaggeration of what reality might turn out to be, yet not too unlikely at its core.

What I found the best part of it was its representation of what human beings looked like in that prosperous and technologically evolved society.

In the movie, humans are overweight, have atrophied muscles, consume ultra-processed food all day long, are carried around in “self-driving vehicles”, and constantly stare at their screens, even to communicate with people sitting just beside them.

Their dopamine system is on constant overload, their attention is always somewhere else, to the point that they can’t even realise how miserable their lives have become.

While the folks at Pixar decided to visually represent it like this…

… I invite you to re-read the description above and ask yourself how much our lives have been evolving in that direction over the past couple of decades.

And no, while it will definitely help, exercising every day on a treadmill would not be an effective antidote to prevent us from slipping further towards that possible future.

Are you familiar with the saying “One dollar, one vote”?

The idea is simple: every purchase is a political action. When you give your money to someone selling you a product or a service, you’re implicitly supporting them. Who we give our money to, and who we accept money from, is our biggest lever.

That’s why I’ll never buy a Tesla, even though I used to like the cars and what I used to believe they stood for. That’s why I’ll never buy a Starlink connection, even though relying on crowded camping WiFi or poor 4G connections for work when traveling in our motorhome is objectively painful and unreliable. That’s why I don’t want to contribute to the adoption of GenAI-related tools, even in their “helpful” incarnations, and miss out on some lucrative contracts.

I’m also aware that not everybody is in the privileged situation of being able to say no. Life is hard, keeping your family alive can be challenging at times when massive layoffs have become news that doesn’t make headlines any longer.

I’d like to do more to help bring some sanity back into this whole industry. I have been suggesting the idea of setting up some sort of “Luddites in tech”4 online meetup with some fellow practitioners, and many found it interesting.

I know I’m not going to go anywhere alone, so this is an open invitation to all my readers.

If you share a similar level of disappointment with where this industry is going. If you find yourself lost after years of believing you were working on something meaningful and positive. If you’d like to discuss ideas, strategies, and suggestions on how we could come together and do something about it, please hit me up.

Just reply to this email. Share your unfiltered thoughts, and let’s take it from there.

The worst that can happen is that we’ll meet some new friends on the journey.

Help keep this newsletter free

I love writing this newsletter, and I intend to keep it free forever.

If you want to support my work, you can engage with me in one of the following ways:

1. If you need help with your Startup, Company, or team, I can support through advisory or fractional services. Find out more on this page.

2. If you need personal support to overcome challenges and grow as an engineering leader, I can support you through Mentoring and Coaching. Find out more on this page.

3. If you are looking for continued support and the chance of joining a thriving community of like-minded people, I host a Community for engineering leaders. Find out more on this page.

If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.