Github is much more than a git repository, it's also

• a social network where the open source world fights for stars
• a software factory (Github Actions)

And if we talk about numbers, Github has 180M registered developers, an estimated market share above 50%, with Gitlab (US) and Bitbucket (US-AU) sharing a large portion of the rest.

In short, if you're a developer, you probably have an account on it, to fork open source products, for your own projects or those of your company. The global software economy relies in part on this US actor, which raises some questions. What happens when your software economy relies on a foreign actor if it becomes hostile?

• In 2019, developers residing in Iran, Syria, Cuba, North Korea and Crimea saw access to their private code repositories as well as their paid accounts completely blocked.
• In 2025, 20,000 private Github repositories were indexed by the Bing search engine and accessible for Microsoft Copilot AI.

And broadly speaking, Microsoft/Github is subject to the Cloud Act and FISA, which requires it to provide all this data to the US administration upon request, particularly for threats to national security, which includes the protection of US economic interests. If I translate into simpler terms, you have no guarantee that your code is protected if the US administration decides otherwise.

Fortunately, there are alternatives in Europe, and that's what we're going to talk about today.

Self hosting

The first option is to host open source solutions. In this category we will find many solutions based on gitlab and gitea.

But open source doesn't mean neutrality. These two companies are US-based and can change their terms of service or embed hostile code that triggers based on geolocation. This doesn't prevent forks, but you then have to manage to create a community of developers to maintain it. So I'm dismissing these choices.

For Gitea however, there is already a European fork: Forgejo maintained by the non-profit organization Codeberg.

Forgejo is notably what was chosen by the Dutch administration to host the source code of public administrations.

If you're a fan of self-hosting, Forgejo is presumably the only available solution. However, self-hosting comes with its own drawbacks, maintenance and management of infrastructure. So I propose to look at hosted solutions.

Hosted solutions

On the market of hosted solutions we will find products based on Forgejo precisely, of which the most obvious solution is codeberg.org. But this is a solution reserved for open source projects so not at all suitable for your business needs if you have any.

We could also mention tangled.org, an excellent project born in Finland, one of my favorite finds, which is based on the ATProto protocol. The project is only made for open source today and includes a social dimension by default. But perhaps the arrival of spaces in ATProto will make it usable later for private projects. However, as it stands, for a business project, I cannot recommend it.

I'm completely dismissing all solutions based on managed Gitlab, they're very good solutions but that doesn't satisfy the idea of finding a European solution. On the other hand, for managed Forgejo we can mention:

• ++Codebahn++ (Sweden)
• ++Codey++ (Switzerland)

Beyond that, we can find two solutions that have just emerged and are not based on Forgejo:

• pushin.eu
• rickub.com

Both are in beta with wait list or invite only but I was fortunate enough to test rickub which is becoming my development platform for Writizzy and Hakanai.

Testing Rickub.com

(First game, I'll let you find the reference hidden behind the name)

Comparison

Rickub positions itself as a Github replacement. We find most of what we're interested in on it, private and public repos, CLI, an MCP, Rickub actions (largely compatible with Github actions).

Under the hood, Rickub uses MicroVMs for CI, which is supposed to guarantee shorter startup time, better isolation and faster execution. Which we can verify on the Hakanai API build (3min vs 7min on github):

::gallery{columns=3} ::

In terms of interface, we find our bearings quite easily since it takes the habits we can have on Github.

On the migration side, the process was fairly simple. I created a .rickub/workflows/deploy-api.yml file. It's the same format as Github action but with some subtleties that are described in the CI/Actions documentation and in the migration documentation.

One thing I particularly liked is that test reports are native without having to go through an external plugin.

And that, believe it or not, is really nice. I would love in the future to have a historical dimension to know since which build a test fails or if certain execution times increase, if there are flaky tests etc… But all in due time, the product just came out.

Pricing

On the pricing side, we find a free plan that allows you to have 5 private repos, 500 CI minutes and 50 AI reviews (I didn't use this feature).

It's very good for many personal uses. It's a bit less generous than Github which offers unlimited private repos and 2000 CI minutes. But for CI, I would say that the gap should be measured knowing that Rickub's CI is faster. 500 min for side projects is more than enough.

Then you have paid plans. I chose the €3/month plan to benefit from 3000 CI minutes, much more than what I need, and here it's slightly cheaper than Github which charges the equivalent of €3.50/month (4 dollars).

In any case, I don't really care, this amount is relatively painless in my case, and here I'm buying the fact that I'm no longer the product as on Github, and that I'm favoring EU products. Yes, tech has a price, some products have accustomed us to being free by appropriating our data and creating a monopoly. €3, I pay them without problems to get out of that.

Open source repos

I partially migrated for Bloggrify but in this case, the final decision to fully migrate hasn't been made yet.

Github is also, and even mainly, a social network. An open source project on Github has more ease because most people have an account there, so they can contribute easily. Most open source project evaluations are based on the number of stars, stars that we find on aggregators.

For example, the position of Bloggrify on jamstack.org depends on the number of stars on Github.

Similarly, there are robots that crawl Github to read projects related to a given tag, that's how Bloggrify was listed by certain sites in the past.

So already on this dimension, it's complicated to get rid of Github. So I left a mirror replication between the two but I'm not sure it's very cool to manage issues and PRs on two systems at the same time.

But beyond that, for now, rickub doesn't handle OIDC id-tokens which allow you to publish packages on NPM, which prevents me from automating my Bloggrify releases on NPM.

Conclusion

Bottom line, I migrate without any regret for Hakanai and Writizzy. It's probably less obvious for open source projects. For professional/business use, I consider Rickub to be very promising and well deserves our attention. I imagine that not everything is perfect yet but that's precisely with use that the product will improve.

And if you're in Europe and you're still using US products, now's the time to start thinking about exit doors before it's too late…

But it's far from "just" a clone, Bluesky was born from research projects within Twitter. It's literally the evolution that Twitter should have followed if the company hadn't been acquired by Elon Musk in 2021.

It was Jack Dorsey (then CEO of Twitter) who announced it in 2019. It was then Parag Agrawal who took the lead on the project before becoming CEO of Twitter.

So, it was a key project at Twitter that aimed to decentralize social networks.
The idea of decentralization was to find a solution to everything that killed Twitter: the concentration of too much power in the hands of a single company.
Bluesky wanted everything to be transparent and open to prevent all the abuses we can see on X with its algorithm widely biased to serve personal interests from being reproduced.
Moderation, recommendations, hosting, everything can be delegated to others, so each user can, in theory, choose what they see, where their data is hosted, and what gets recommended to them.

But this ideal does have some flaws. And that's what I'd like to talk about today.

Decentralized and Federated Networks

Bluesky isn't the first to propose a decentralized network.

But if we're talking about social networks, in the more modern sense of the term, I'd say one of the first is newsgroups that worked on usenet. If it appeared in 1979, I personally used it much later, during my studies (between 1997 and 2001). I mean, in 1979 I was more interested in learning how to properly put food in my mouth than in browsing American university servers.

Oh yes, by the way, since I was talking about my studies, it was during that same period that I started doing fansubs, amateur subtitling of Japanese anime, and that's when I discovered other decentralized social networks like IRC or Direct Connect. Knowing that part of the illegal downloading of subtitled anime was done via newsgroups anyway. The loop was closed.

But for these networks, we're not really talking about federated networks. That is, if you were present on one IRC channel, you couldn't see what was happening on another IRC channel, and the same with Direct Connect.

The first federated social networks appeared around 2008 with Laconica/StatusNet then Diaspora in 2010. But there I have no personal anecdotes to tell about these networks because, I don't know why, but I completely missed them when they came out.

Still, there are plenty of interesting things to say about these two networks. Originally Laconica/StatusNet is a sort of refuge for the free software community against Twitter and besides the first versions of Mastodon ran on the OStatus protocol, itself a direct heir to the work done on StatusNet. So we can talk about a lineage between StatusNet and ActivityPub/Mastodon.

As for Diaspora, it's a bit less cheerful. If the project starts well with a successful kickstarter campaign of $200,000 aiming to create a decentralized Facebook, one of the founders, Ilya Zhitomirskiy, took his own life at only 22 years old which gave a serious setback to the initial project. The Diaspora network then became notable in 2014 for being the digital refuge of the Islamic State. The very nature of the network prevented any central action to combat content created by Daesh, which highlighted some of the challenges of federated networks and had consequences on the design of Bluesky later on.

We had to wait until 2016 to see a new initiative appear with Mastodon and then the ActivityPub protocol in 2018. The network achieved some success with 15M users (but only 1M monthly active users) but it faced several design problems:

• a certain form of complexity in registration (choice of a server)
• identity that is tied to the server which makes moving difficult

Registering is already making a choice since the server can decide who it federates with or not, its internal moderation rules and if the server closes overnight, your account dies with it.

The fact that a server can be autonomous on everything, moderation, permission to leave etc… led several people to say that we left a kingdom instead to a federation of feudal fiefs.

And that's when Bluesky arrived with its ATProto protocol in 2019.

Bluesky is Not ATProto

Bluesky is the standard bearer but Bluesky is only an implementation of a protocol. With this protocol, ATProto, there is one objective: it's that anyone can recreate an application like Bluesky, offer hosting for your data on a server (a PDS), enrich the protocol to add new types of applications. Recreate Facebook, LinkedIn, Instagram, everything becomes possible, with the same user base.

In practice we long pointed out that apart from Bluesky, there didn't seem to be anything else. But that was before. Bluesky now coexists with Eurosky, Graysky or Blacksky for microblogging and with many other applications like Tangled, Sifa.id, Flashes etc…

And to address the moderation questions raised by Diaspora, a user can now choose their moderation services and an application like Bluesky can also hide content.

This makes it possible to quickly address content that wouldn't belong on the network but it's flexible enough to allow you to view it on your own AppView if you wanted to.

As for the problems raised by Mastodon, around identity portability and the risk of choosing a server that changes its rules midway or decides not to federate with servers that interest you, well that's also solved. Identity is not tied to the server but to a directory and all functionality (moderation, feeds etc…) is portable from one AppView to another.

Now that I've sold you the protocol a bit, I need to circle back to my original topic. Why is one of its greatest strengths also a risk for you?

Default Transparency

On the ATProto network, everything is public. That is, you can view the entire network, know the number of users, the active ones, conduct network studies to observe the spread of a specific idea, create tools to identify networks of suspicious accounts.

It's a huge advantage and one of the main criticisms leveled at X since they closed their APIs. In Europe, X had a legal obligation to provide data access to approved researchers to combat misinformation. Musk having a certain interest in not being able to study algorithmic biases on his platform, he is now in conflict with European authorities on the subject.

But that's impossible on ATProto. Except this strength also proves to be a real problem for you.

You may have seen the new "news" tab in mu.social (an alternative client to bluesky)? In it you can indicate your preferences in terms of information:

And you can also select newspapers to follow:

But note the last remark:

I understand my topic and source selections will be published as a public record linked to my account, and agree to share them.

Everything is public.

But in reality, that applies to everything. All my likes are public, all the people I follow, all the people I block.

But it goes beyond that. I invite you to look at my PDS data.

You have plenty of information here:

• I have a profile on sifa.id
• I have "endorsed" people on sifa.id and you can know who
• I have a publication on Offprint (an alternative to Writizzy that I wanted to test)
• I published Writizzy on atstore
• I have a publication on Writizzy (this blog)

In short, all my activity linked to my handle @eventuallycoding.com is publicly available on my PDS.

And that, oddly enough, is a problem.

You don't need to know who I'm subscribed to on standard-reader, and therefore what I read. The same way you don't need to know my political, sexual or religious orientations.

The point of decentralization is, in part, to avoid giving a single company too much information about me by crossing all my data. With my use of ATProto, I just gave this intersection away for free to everybody.

Imagine a forum powered by atproto where I would come to talk about personal problems, an addiction, a complicated family situation. You shouldn't know about it.

Anyway, I really like the potential of ATProto. For example, I admit I was seduced at first when I built my profile on sifa.id: https://sifa.id/p/eventuallycoding.com, a sort of neo-LinkedIn. Well first, technically it's super interesting on one hand and it appeals to the geek in me but that's secondary for the general public. The other point is that I found it powerful to see that sifa.id automatically aggregated my bluesky posts, my tangled contributions, or my blog articles.

But thinking about it, there is a risk. I don't necessarily want to see my vacation photos posted on flashes/instagram or posts on the forums I mentioned earlier arriving in the same place.

Anyway, transparency yes, but up to a point.

What If Information Became Private?

For now, atproto has no concept of private data. But that could change. A new feature is being rolled out with ATProto Spaces.

On paper, it seems promising. It will make it possible to have private information on which I could decide who has access. The use cases we can quickly imagine:

• forums with private sections reserved for members
• native private messages on bluesky (currently private messages are not stored on ATProto)
• member-only content on a blog (Writizzy already handles this case, but by not using atproto precisely)
• private drafts on a blog

etc…

But beware, this is far from sufficient. There is no notion of encryption. Data is private, it's the PDS that will provide access or not to the data but it is stored in clear text. Sure, that limits who has access to the data, but the data exists, accessible to administrators of your PDS.

You could of course host your own PDS, but without encryption I wouldn't make it a safe for sensitive information.

In any case, that doesn't solve a conceptual problem, the fact of associating a handle (your identity) with a bunch of information that shouldn't be mixed.

On the classic Web, we separated our uses through compartmentalization. I created an anonymous Reddit account, a LinkedIn account etc… Here, the promise of portability pushes the opposite effect: a single identity, which brings together all the info on a server (a PDS).

The Solutions?

ATProto is an excellent technical foundation to allow us to build all kinds of decentralized and federated social networks and finally get out of Big Tech.

First we need to wait for some important protocol developments:

• end-to-end encryption on some data. Yes I understand that it's difficult to encrypt Spaces and manage key rotation at each entry/exit, but we could however encrypt DMs between two individuals.
• a mechanism for hiding metadata (for example my news display preferences, my likes, the people I block) like Zero knowledge proof

But maybe the real issue is personal.

What is certain is that atproto, even if it makes it possible to solve the problem of excessive centralization by a private player, should not give us illusions. If it solves the problem of transparency, it doesn't address that of respect for our privacy. I expect more from what it proposes but in any case, the challenge of confidentiality rests with us.

We must put in place a certain form of personal hygiene with respect to these networks by recreating the compartmentalization we had before with a strict separation of identities. Even if it's tempting and encouraged, we must develop the reflex of using multiple identities to separate activities (Public/Professional/Associative etc…). We should have multiple handles. Don't treat the Bluesky login the same way you might have treated the Google login.

Finally, many of us have too easily gotten into the habit of entrusting sensitive information to the internet. Nobody needs to know your date of birth, your location, your marital status and so on. Don't recreate your own panopticon.

But there's one theme that seems to unite just about everyone, pro and anti AI, it would be a bubble, and it's going to end up bursting.

Well, now's the time to ask the question. Is it a bubble? Can it burst and when? And what would the consequences be if it did?

Is it a financial bubble?

If the question seems obvious to many, it deserves a closer look. Are we really in a financial bubble? Is the value we're giving to AI companies realistic?

Are we witnessing a historic transformation... or a speculative bubble?

First clue: valuations that seem absurd

A financial bubble isn't simply a sector that rises very quickly. Otherwise Amazon in 2010, Tesla in 2020, or Nvidia today would all have been bubbles. The central question is one of sustainability: is the value attributed to these companies realistic? Are massive investments in AI based on solid financial foundations?

At first glance, it doesn’t look good.

Anthropic generated about 850 million dollars in revenue in 2024. Yet, a few months later, the company was valued at nearly 19 billion dollars. More than twenty times its annual revenue.

You need to understand that in finance, there are two logics:

• For a traditional company, the value of a stock corresponds to known performance in the present. It depends on profits generated and physical assets (factories, stores, inventory) or intellectual assets (patents).
• For a tech startup, however, the value rests on the promise of future gains. Its valuation doesn't reflect its current revenues, often low, but anticipates their explosion to come. A "multiple" is then applied to its revenue or recurring revenue. If this multiple rarely exceeds 10 to 15 times revenue (especially since the interest rate hike post-2021), AI pioneer companies today reach levels well above that, sometimes ranging from 20 to over 50 times their revenue.

However, just because these multiples are enormous doesn't mean they're unusual and abnormal. They're abnormal for the period, but not abnormal in absolute terms. In the past, Shopify, Snowflake, Amazon, all these companies exceeded x50 and the bets turned out to be winning.

So, wrong trail.

Verdict: ❌ inconclusive

Second clue: an avalanche of capital

Over the past three years, more than 1,000 billion dollars have been committed to the AI ecosystem.

According to the BIS (Bank for International Settlements), 5% of US GDP is today linked to investments in AI. This amount exceeds what was observed during the previous internet bubble in 2000.

And in absolute value, the Internet bubble represented approximately 600 billion dollars of the time. Adjusted for inflation, we're again approaching current investments in AI.

On the other hand, by contrast, the subprime crisis involved over 10,500 billion dollars in residential mortgage debt. But be careful, we're comparing apples and oranges in this specific case.

What's certain is that the amounts at stake are colossal. But colossal doesn't mean abnormal. Telecoms in the 80s/90s, mobile in the 2000s also attracted gigantic sums without people talking about a bubble at the time.

Verdict: ❌ concerning but inconclusive

Third clue: what if the customers were... the investors?

Here we touch on one of the specifics of the potential current crisis: the revenue of AI companies increases through their own spending on AI.

AI actors aren't just companies that create LLMs. It's also cloud hyperscalers or chip manufacturers. It's a perfect form of circular economy (round tripping)

NVIDIA invests in OpenAI
        ↓
OpenAI reserves computing
        ↓
OpenAI signs cloud contracts with Oracle, Microsoft, etc.
        ↓
These providers buy NVIDIA GPUs
        ↓
Revenue comes back to NVIDIA

The problem with this circular economy is that it self-feeds and we don't yet know if real demand will follow. If the only customers for AI are the other AI players, let's just say that's at least suspicious.

All projections for new datacenters, investments to build new chips, etc... would potentially be thrown away in case of market reversal since for now the only customers for these companies, at this scale, are themselves. And the sums we're talking about are in the tens of billions.

Verdict: ⚠️ concerning

Fourth clue: non-existent profitability

Investments in AI are not profitable except for NVidia but that's a bit natural when you're selling the hardware (see clue 3). For the major players (Amazon, Google, Microsoft, Meta), for every euro spent, less than 10% of the sum comes back in revenue, with Meta winning the small palm for having only 1% coming back in revenue.

Even major players like OpenAI, Anthropic (or Mistral in France) struggle to exceed 40/50% of the sum in return.

In short, these players aren't profitable.

But this clue is very shaky. It's rather common to over-invest in the startup phase, especially in industrial fields that require investment.

Amazon wasn't profitable until its 9th year, Tesla until its 17th year, Uber 14 years. A phase of significant losses is nothing unusual when a sector is building the infrastructure for a new market. It's even almost expected.

In reality, the problem isn't that AI isn't profitable today, that's normal. The real issue is whether it can be profitable tomorrow, once investments have stabilized. This question remains largely open. Are today's investments sustainable or do we need to reinvest the same amount every year?

For now, given the obsolescence of the hardware used (chips for training and inference), the answer doesn't seem to be going in the right direction.

Verdict: ⚠️ concerning

Fifth clue: when history begins to repeat itself

Remember the bubble of the 2000s?

In 2000, all you had to do was rename your company with a .com, like sausage.com and boom, valuation increased. Irrationality was so great that investors rushed at anything and everything, and especially everything, just to not miss out on the next gem.

And let's remember that investors aren't always the best when it comes to rationality, because each time, during major crises, we get a new version of "this time, it's different" which basically justifies that economic fundamentals can be neglected.

Well, we're seeing something similar today. All companies are integrating AI, at least in their investor pitches. Some have started reserving .ai extensions just to ride the wave and I'm more than suspicious of the valuations of some companies like Lovable (6 billion), Cursor (60 billion), Devin (26 billion). It's cool for their creators but, making a wrapper on existing AIs, I'm not convinced that's worth that price.

Verdict: ⚠️ concerning

So yes, I can't say 100% that we're in a financial bubble but it looks like one. Extraordinary valuations, gigantic investments, an economy that runs largely on itself, companies still far from profitability and, above all, discourse that's starting to sound oddly similar to that of past major bubbles.

At this point, the most interesting thing therefore maybe isn't to know if a bubble exists.

It's to understand how it could burst.

Because all bubbles don't burst the same way.

The triggers

Bubbles always end up bursting but the detonator is often unpredictable. We can easily identify the weaknesses but it's sometimes a trivial event that ends up bringing down the system.

Despite this, I propose we play a game and try to list the possible triggers for a potential AI crisis.

Option 1: The IPOs of Anthropic and OpenAI go badly

Anthropic and OpenAI are planning upcoming IPOs. While the exact dates aren't yet known, this could happen between the 4th quarter of 2026 and the 2nd quarter of 2027.

During these IPOs, we'll see if "retail investors" decide that the stock price is actually worth what we're paying for it today. And precisely, there are several problems as we've seen:

• valuations seem far too high compared to revenue generated
• profitability is too low

To that I'd add another important problem: the amount of liquidity available on the market.

The theoretical valuation of Anthropic is 965 billion dollars and OpenAI isn't far from this figure. Obviously an IPO won't be for the full value but a part, let's say 10% (100 billion).

The records for IPO amounts oscillate between 35 and 50 billion. To go buy 200 billion (for Anthropic and OpenAI), will markets follow? Will the first raising, which would already be exceptional, not handicap the second?

Option A: both raisings happen in these orders of magnitude, it will necessarily be by selling other assets to mobilize cash, so by creating a drop in the prices of other companies.

Option B: it's impossible to raise these amounts, and the values of both companies drop

Despite this, I want to set this scenario aside because I find it obvious, too easy and therefore unlikely.

Option 2: Big investors reduce their sails

Today it's hyperscalers that are investing the most in the big AI companies, OpenAI and Anthropic to name just them for now. And when I speak of investment, I also speak of material investment with facilitated access to infrastructure.

Except that for now the return on investment is low. So imagine that tomorrow, Microsoft announces it's reducing these investments and lowering these datacenter/infrastructure costs.

The market won't just look at Microsoft and LLM publishers. It will look at Nvidia, AMD, TSMC, electricity producers. The whole chain.

Despite this, this option doesn't suit me either. True, for Microsoft or Amazon, the situation isn't rosy, but it's not catastrophic either, because these companies benefit from public contracts, particularly in the military field. And deciding to cut investments now would be precipitating failure, shooting yourself in the foot, which seems unlikely to me.

Option 3: Physical slowdown

This trigger is based on a very simple idea: datacenters have enormous resource needs. Eventually we know that these resources won't be available, whether for energy or mineral resources.

Imagine that tomorrow:

• we have supply difficulties on rare earths, for example related to a conflict with China (60 to 70% of mining extraction and more than 85% of refining comes from China)
• that available electricity can no longer be supplied for datacenters (e.g. in Dublin, the US, and Singapore)

We could imagine a slowdown not financial... but physical. And we fall back on option 2. We won't just look at the datacenter, we'll look at the whole chain, all planned investments that won't be made.

This option is much more credible, in my opinion, but in the medium term. It seems difficult for me to imagine a significant event before 2028. However, I may be naive because relations with China keep degrading and datacenter construction refusals are already increasing. I therefore classify this lead as credible.

Option 4: AI hits a ceiling

This is a real issue. Imagine that Opus 8 is "only" 3% better than its predecessor? Investors pay to see exponential growth. This is exactly what motivates all the circus we usually see at each release from these giants' marketing teams. They have to sell us the incredible, because they'll only be paid for the impossible.

What would happen if this rate of improvement in model performance slowed? Again, we come back to option 2. A major investor could decide to lower these datacenter expenses and you know the rest.

Is this option credible? The improvement over 1 year has been staggering and almost frightening. Despite this, I have the impression that the room for progress remains significant. But I say that being far from being a specialist. I would however tend to reject this option for at least the next 2 years.

Option 5: A macro shock

This option is more traditional. What if tomorrow a huge shock shook the economy with no relation whatsoever to AI. It could be an energy crisis, a political crisis (an open conflict between Europe and Russia for example), the Chinese real estate crisis that's been brewing for years.

This is typically the option where unknown unknowns are more numerous than others. Since this option is by nature completely unpredictable, I won't consider it either.

At this point you might tell me, "ok but you haven't retained any option, so you don't think the bubble will burst?"

That's not quite it. I think most of these causes are too predictable, or too long term. Again, predicting the trigger is particularly difficult. It will maybe be a combination of factors with a domino effect we don't anticipate today. The trigger for the burst of the internet bubble in 2000, for example, was the Federal Reserve's rate hike.

In any case, I have trouble not imagining a trigger in the next 2/3 years.

On the other hand, the consequences won't necessarily be what everyone imagines.

The consequences

I'm not done bothering you with multi-section chapters :)

We often imagine that the burst of a bubble is like the 2000 internet bubble or the subprime one: a huge market crash, lots of companies on the ground and done.

Well, not necessarily. Bubbles always end up bursting but it can be slow and smelly and we'll see again several scenarios.

Scenario 1: The bubble bursts violently

That's the easy scenario, the one we all have in mind. Valuations collapse, some major players go bankrupt, followed by layoffs in the tens of thousands and project shutdowns.

For this scenario to be as impressive as possible, we can imagine a Big Tech company going under, a sort of modern Lehman Brother, or Worldcom to draw the parallel with the internet bubble.

Beware, this scenario is obviously the most painful because it won't just affect "just" tech. We're talking about all hardware sellers, electricity suppliers, insurance companies that covered transactions, retirement savings plans, stocks etc... because yes, a large part of current investment is based on US values, particularly in tech.

I insist, it will be very painful even if you think you're far from AI. The burst of the internet bubble was between 60 and 80% loss of value of stock indices, millions of jobs lost.

Scenario 2: A dilution

We might not necessarily have as cinematic a scenario as the first. We could simply have a gradual decrease in investments but a maintenance of infrastructure and a reabsorption of large LLM publishers by hyperscalers.

It would potentially be the end of the game for Anthropic, OpenAI as independent entities and the losses would be largely absorbed by GAFAM.

(I'm not talking about xAI which is already part of a consortium or Gemini which is part of Google)

It wouldn't be an explosion but a dilution of the AI bubble into the accounts of big techs

I speak of dilution but we could also speak of consolidation. We'd certainly have fewer actors but a large part would be absorbed by the more resistant ones, Google, Amazon, Tencent for example.

It would be less spectacular but not without consequences either. Part (and only part) of the investments would be set aside. Heavy investments planned for in 5 years would be stopped, so with more time to rebuild correct budgets. There would still be layoffs but less massive.

My little pinch in the heart in these two scenarios is that I can hardly see a European player like Mistral survive this scenario without being completely absorbed, unless Europe decides to invest massively through public procurement. The gap is large and I find their strategy poorly lisible today, and even poorly anchored in the tech ecosystem. But I wish them the best, because we need a European champion on the subject. Even if at worst we'll cobble together things with open weight models.

Now you know what?

If we exclude the Mistral case, despite all this, I'm almost hoping it happens and I'll explain why.

Why it wouldn't be so bad

A bubble, let's remember, is misallocated capital. Now, I'm not saying that AI as a technology isn't worth it. It's completely redefining many professions. But is that reason enough to do anything and everything, I'm not sure.

When Google questions its objective of carbon neutrality 2030, it's a failure for everyone. And then, is it healthy to have this race to the bottom for datacenters that we know we can't all power with electricity, except to reopen gas power plants?

Besides, when I talk about misallocated capital, I'm very happy for the people who created Lovable or Cursor, that's cool for them. But all this capital to create a tech that's already being competed with by tons of products vibe coded 2 years later, that's a shame. The same money could have funded something more useful.

Capitalistic irrationality, excesses on mineral resources that plunge us into a RAM and component crisis, increased tensions between countries, and simply the current climate around AI that's becoming unbearable between pros and antis, I find that's a lot of reasons to hope it stops.

If the bubble bursts it will sign a form of return to rationality. I don't believe in the disappearance of the tech, the same way the internet didn't disappear in 2000 and the train also survived the railway bubble of the 1840s.

What disappears in a bubble isn't necessarily technologies: it's mainly absurd valuations, projects that had no viable business model and investments made because "everyone's doing it".

More rationality means better thought-out investments, R&D more focused on optimizing what we've already learned: mixtures of experts, quantization, pruning, HBM, model optimization. We need to now do as much but with less. It's a necessity.

We already have enough to work with what we have in hand and it wouldn't be bad to pause a bit, think about the uses that work, and there are already some, find a real path to profitability and redirect capital, particularly toward the challenges of decarbonizing the economy (electrification of the vehicle fleet for example) or adaptation measures to climate change.

Will the burst of the AI bubble see the end of AI? Not so sure. It will be more of a landing. But whatever the scenario, it will be beneficial, a return to economic AND ecological fundamentals.

Don't be mistaken, given the sums already invested, the burst will hurt, a lot, but the longer it takes, the worse it will be. The band-aid needs to be ripped off, quickly.

• European software
• Non-US open source software (self hosting)
• US open source software
• Non-US software
• US and Chinese software.

(Despite this, you will see that I have 28% US software)

Here I only talk about the basic building blocks for creating a company, support software, observability, emailing, payment, etc…

::toc{open="true"} ::

Hosting

Payment

Criteria: Merchant of record, metered billing, coupons, connect

Alternatives that I couldn't test:

Analytics

DNS - CDN

Support

alternative often cited: Crisp (France)

Monitoring - logging - observability

Alternatives currently being evaluated to replace Sentry:

Feedbacks

European Alternatives: upvoty (FR), LiteFeedback (FR), Feedfast (RO),

Emails

No European actor allows me to send marketing emails at AWS prices. It's on average x10 on prices, which is totally prohibitive.

Company blog

Well yes, of course I use my own product, what did you think I was going to put? :)

And this subject of networks is particularly sensitive. Because while they are often seen as simple leisure tools where you post cat pictures, they are actually real information highways. Media, politics, sports, culture, social and family ties, romantic relationships, everything goes through networks.

But as you should know, information is power.

What happens when a handful of people control these networks? When they can collect and analyze a considerable amount of information about us, decide what we see or don't see, based on their own interests?

In short, we would be wrong not to take them seriously, and it's an issue, particularly in Europe at a time when we regularly talk about sovereignty.

But it's difficult to create social networks. It's expensive in the first place. Few investors in Europe are willing to finance the next LinkedIn, the next Twitter, or the next Youtube. And most importantly, to hope for success, you need to convince you, but also convince your friends, your family, your colleagues because otherwise, it has no interest. This is what we call the network effect: the value of the product is proportional to the number of users using it, which makes the arrival of new players almost impossible.

And yet, there is today another way.

What if, instead of trying to build the next Twitter, we completely changed the way social networks work?

What if we returned, in a sense, to the origins of the Web: a more open and decentralized Web, where you could choose your provider without losing access to the rest of the network?

In short, let me introduce you to a protocol that could help us redefine our social networks and create opportunities, particularly in Europe: ATProto.

Bluesky is not ATProto

You may know Bluesky?

Bluesky is a new Twitter with around 43 million users. If its success remains modest compared to its predecessor, its growth has been rather dynamic over 4 years and varies depending on regular waves of departures from X. Thanks Elon…

But you might say, Bluesky is just another US company, so another monopoly in the making. Yes, certainly, but you need to look under the hood.

Bluesky is based on a protocol: AT Protocol. This protocol defines the data present on the network, how we store it, how we view it, how we can moderate it (label it), in short, how the network works.

More precisely, it means that Bluesky is not required to own your data to display it. On Twitter, Substack or Medium, the data is owned by these companies and can be filtered, modified, or monetized without your consent.

Here it's different. Your data is hosted on a PDS (Personal Data Server), and this PDS doesn't necessarily belong to Bluesky. For example, my data is hosted by Eurosky, a European PDS.

And I'd like us to pause for a moment on the Eurosky homepage:

Eurosky is also behind mu.social, an alternative Bluesky client, and mu is the first prefiguring thousands of other social apps.

Because yes, the ATProto protocol is so open that each piece of the puzzle can be replaced or extended. And that's where we can start having fun.

Everyone can build on top of it. We can define our data, so we can build alternatives to Instagram (flashes, grain), to Pinterest (current.is), to Substack and Medium (Leaflet, Writizzy), to Tiktok (Spark, Skylight), to InoReader (Gleen), or even to Github (Tangled), all based on the same architecture, but especially, already benefiting from a user base of 45 million people.

The network effect is already there.

Bluesky is not ATProto, it's one piece of a much larger ecosystem: the atmosphere.

The lexicons

By default, the data present on ATProto is made to display short messages. It's the famous Bluesky message you already know: a message, an author, a number of likes etc…

But, at first, you can't post long messages and besides it's not really designed for reading blog articles, videos, or source code.

But we can extend all of this via lexicons. A lexicon is a common language, a data schema, it's roughly the set of vocabulary on a network record, and that certain applications will use.

For example, the lexicon of a Bluesky post is defined by app.bsky.feed.post and we'll find fields like text, createdAt, langs, embed (when there's an image) etc…

But anyone can define a new lexicon. Obviously it won't be read by all applications. Bluesky won't read your lexicon but your application can.

And precisely not long ago I came across a lexicon that particularly interested me for blogging platforms: standard.site.

The initiative comes from three platforms that partnered together: Leaflet, pckt.blog and Offprint and they proposed this new format for long-form publications.

This format pleased so many that it is now available via a plugin in the WordPress ecosystem, for static blog generators via Sequoia, and now it's also becoming central in Writizzy, the product I'm building and which runs this blog (and probably soon also Bloggrify which I also maintain).

This integration therefore allows you to have native understanding of your Writizzy publication in Bluesky/muSocial. Note the "view publication" link which doesn't normally appear for a simple base link.

But most importantly, this allows all posts published on Writizzy to be visible in all readers that scan the atmosphere for blog articles: standard-reader, Heron, potatonet, docs.surf, leaflet etc… In short, in one step, Writizzy becomes a member of the atmosphere and can expose a new article to millions of users.

And this example shows us that we can now create new apps, with their own vocabulary, on existing PDSs and benefiting from an already established network.

The return of an open and decentralized web

Beyond this specific example, ATProto offers many opportunities to return to a more decentralized web under your control. You could, for example, have your own PDS (personal data server) that participates in the AT Proto network.

And you can go even further. The entire protocol provides that each feature is composable and that includes moderation or feeds. It's not Bluesky that imposes them on you. Again, Bluesky provides a service, but it's not ATProto.

If you want to use another labeler (a tool that allows moderation), or if you want to create your own feed with your topics, you can. I could create in the future a feed of all Writizzy tech blogs for example.

In short, you can regain control over your data, the algorithms that push content to you, and the associated moderation.

But more than that, it's huge opportunities to rebuild all the social networks we're missing in Europe: LinkedIn, Youtube, Tiktok, Instagram to name a few.

Hoping that indeed, mu.social is only the first among thousands.

This open and composable web won't happen by itself, and it won't come from Silicon Valley. Today, the infrastructure is ready, the user network exists, and the foundational building blocks are in place. It's up to us, European developers, creators, and entrepreneurs, to seize ATProto to build tomorrow's platforms, on our own terms.

PS: oh yes, and if you comment below the post on Bluesky/mu.social, the thread should come back as a comment on the blog

But this opposition reminds me of a bad memory: the fight against nuclear energy in previous decades. By trying to move away from the atom, part of the green political movement plunged Europe into dependence on fossil fuels and Russian gas. I fear that with data centers and AI, we are making the exact same strategic mistake.

Let’s be clear: energy consumption is a crucial issue. We must lower our consumption, our usage. But rejecting these infrastructures on our soil won't erase the need for computing power: it will only move it to where energy is carbon-intensive and environmental standards are non-existent. Pitting digital sovereignty against ecological transition makes no sense. Wanting a green future without controlling our digital infrastructure is choosing powerlessness.

Growing digital consumption

Some opposition to datacenter installations is based on one argument: we must stop increasing pressure on planetary resources and the digital sector, and the growing digital sector is the perfect scapegoat and the easiest target to hate.

Easy to hate because it symbolically represents, for many, screen addiction, automation, job losses, and the techno-fascism of Thiel and Musk. Even if, like any symbol, it's mostly an extreme oversimplification that ignores the other, positive side of the balance.

On the ecological front, we can only agree on the fundamentals. Our planet is pushed to its limits and we must lower our consumption. Yet digital usage is exploding in a world where every sector should aim for the opposite. Its share in France's carbon footprint has risen from 2.5 to 4.4% in recent years in France. This growth is roughly identical on a global scale and trend projections predict further increases.

Can we afford this? Certainly not.

But is "digital" a homogeneous whole? Not so sure, as this IEA study shows (International Energy Agency).

• Digital technology, and especially AI, has positive impacts when it comes to optimizing energy systems, renewable energy management, weather forecasting models, and medicine.
• However, digital technology and AI are also, unfortunately, accelerators for the fossil fuel industry, enabling better exploitation of existing deposits or the discovery of new ones.

And what's missing from this IEA study is the environmental pressure linked to the AI industry's consumption of mineral resources to build increasingly powerful equipment and ever-more energy-hungry data centers

We could also mention the trend in the US to build new gas plants to power datacenters.

Obviously for these reasons, I can only agree with opposition to datacenter installations. But opposing without nuance is also forgetting the positive impacts of digital, AI included, which is today necessary to optimize our logistics and energy flows in a world of 10 billion inhabitants.

And also, this opposition in Europe seems to me to overlook a key detail as Charles Gorintin pointed out on LinkedIn:

Refusing a data center in France eliminates no requests. It will be served elsewhere, on a gas or coal network, with an economic loss for us. Every gigawatt we don't build here gets built where electricity is dirtier.

I'll even go further, pitting sovereignty against ecology is counterproductive.

Sovereignty vs Ecology: the false dilemma

Ecology must take priority over the economy. Obviously. Because yes, having a rising stock portfolio in a burning world doesn't make much sense, which is what Mathilde Saliou essentially tells us:

make a small effort to break free from the economic reasoning to which we are all most accustomed. Take a step back to escape the reflex of direct competition with the United States and China. If it's about reproducing their model, in any case it's a losing game. And then what is this masochism, which consists of trying to "catch up" with countries that are examples of neither democratic nor environmental terms?

However, I have another reading of this: failing to address sovereignty issues leaves us unable to control our own choices on ecology.

If you don't have your own champions, your own infrastructure and a strong market, you suffer the standards of others. Americans will prioritize profitability and hyper-consumption, while China will arbitrate according to its strategic interests alone.

When I speak of suffering, I'll clarify my point.

Our digital dependence is a huge flaw in the European model. We are dependent on more than 70% of US digital products in Europe. Our data is in the US and we pay a constant digital tax from our economy that goes there.

This vulnerability is not just economic. It's a sword of Damocles hanging over our political institutions. It's for example:

• direct attacks on the International Criminal Court to cut off access to American software
• massive manipulation on social networks to influence voters' choices

No, we're not just fighting to have a few more euros. Sovereignty is ensuring that we remain master of our choices. It's ensuring that we can still say no when the American administration tries to impose the abandonment of corporate diversity policies on us, or when it tries to influence French judges on trials.

Economic power ensures independence and guarantees that our voice is heard when we speak about ecology or human rights.

Pitting sovereignty against ecology is a false dilemma. There is no world in which we can choose our future on ecology while being economically and politically dependent on other countries.

And AI, like the construction of data centers, is part of the keys to remaining sovereign. Saying "Not in my backyard" (see NIMBY phenomenon) makes no sense.

Because digital (and AI) are today tools of economic and political dominance. They are increasingly deployed in cyber warfare, network manipulation, and military drones that have become the new standard on modern battlefields. And I'm not saying that these are perspectives that delight me, but remaining on equal footing will allow us to remain calmer with each new moment of madness from a foreign president who would seek to harm us.

But beyond this simple defensive posture, it's also giving ourselves alternatives.

Sovereignty as a lever for control and exemplarity

Sovereignty over data centers is the ability to regain control of digital infrastructure in Europe, a battle certainly lost in the last decade, but not beyond recovery.

Regaining control, having a hand on our tools allows us to impose our energy mix (decarbonized), our efficiency requirements and our eco-design rules. Impossible on a 100% American or Chinese cloud.

Sovereignty and more broadly, economic power, is giving ourselves the means to impose standards (eg environmental regulations) that foreign markets are forced to follow if they want to sell us their products. Because yes, as long as it remains attractive to sell to a market of 450 million inhabitants with good purchasing power. That gives us leverage.

And sovereignty is not necessarily "producing more", it's giving ourselves the institutional power to say "no" for example if an industrial player wants to create a gas plant to run a data center, or to impose energy consumption caps.

Finally, sovereignty is not just industrial and economic muscle; it is resilience to climate, energy, and supply shocks. A form of sovereignty that destroys its own environment undermines its very conditions of existence in the long run.

Deployments yes, but not at this speed

We must regain control of our infrastructure. This involves datacenters in Europe and European development of AI to extract ourselves from our dependence on the US and China.

This is also the conclusion of the shift project in this 2-hour synthesis video that covers all their recent work on the subject:

we are not saying that you must not do AI, but not in this deployment trajectory

Including a question about sovereignty at the end of the video which is answered in two parts:

• It's important to reduce our share of energy spent abroad, for dependence reasons (preferred term to sovereignty in their case) but also to be able to impose our arbitrations, on consumption or type of use.
• It's important to have our own models developed in Europe, and/or to favor open weight models, less consumptive

For these reasons, ++we need datacenters in Europe++ BUT managed by European actors.

So yes, even the shift project says so.

Now, what does it mean to be digitally sober? And are all the large European investment projects realistic?

What is our energy consumption in Europe? What is our capacity to increase energy production? What are the necessary projections of electrical power needed for the construction of datacenters? And most importantly, is it realistic? What trade-offs do we need to make?

It's not a question of being for or against a technology, I still think we must create our infrastructure. But is it physically possible?

The figures

It's good in theory but we need figures.

The current electricity consumption of datacenters in Europe is approximately 75 TWh/year (or nearly 2.5 to 3% of continental electricity).

Projections for 2030 (on consumption) envisage that datacenter consumption will reach 150 to 170TWh (4.5% of electricity produced). For 2035, 230Twh is expected, or about 155Twh more than today. First question, are we planning to increase our energy production by 155Twh?

There's a physics problem. The increase in expected consumption is greater than the increase in production.

On the production side: Between now and 2030, Europe plans to put into service approximately 150 to 200 TWh additional decarbonized electricity (solar, wind, nuclear). This will be the result of massive projects that take years to come to fruition.

::callout{type=warning} Warning, this is a prediction of an increase but the IEA emphasizes in its Accelerated Case that the actual speed of deployment of networks and wind/solar farms struggles to maintain the necessary pace of ~25 to 30 TWh/year net growth across the entire continent. ::

On the demand side: there is competition for use. Europe must electrify cars (moving to 100% electric), industry (decarbonizing steel mills) and heating (heat pumps). Datacenters enter into direct competition to capture each available decarbonized gigawatt.

To be clear:

• Datacenters alone are demanding +155 TWh over the same period.
• But the ecological transition already requires powering heat pumps, industry and millions of electric vehicles, which already absorbs the entirety of the remaining 50 TWh (from the most optimistic scenario).

The balance: There is physically ++at least++ 50 TWh missing in decarbonized energy by 2030 to satisfy both the objectives of the European Green Deal and the current trajectory of digital technology.

If we go slower on decarbonizing transport to fund digital, that would be a fundamental error.

Moreover, certain locations are already under enormous energy strain:

• Ireland, 20% of its electricity consumption is dedicated to datacenters and had to put in place a de facto (imposed) moratorium on the construction of new data centers
• Cities like Frankfurt, London, Amsterdam, Paris, Dublin are under strain. In some places, you can no longer build new homes due to lack of available energy.
• in Germany, the Netherlands and the United Kingdom), pending connection requests for energy and industrial infrastructure today represent more than 500 GW of power (equivalent to several times the total installed capacity of France).

Not to mention grid connection issues. In Europe, it takes an average of 7 to 10 years to strengthen the electrical network and connect a large datacenter.

An infrastructure project filed today is assigned grid connection dates between **2032 and 2038** in several European hubs. The demand is not only greater than production: it's growing 3 times faster than the network's capacity to lay cables and build substations.

The 230 Twh trajectory is not physically realistic.

So can our network absorb it? No, and especially not at any cost, not by sacrificing the rest of decarbonization efforts. France has a unique advantage in Europe: electricity among the most decarbonized on the continent thanks to nuclear and renewables. But our production capacity is not infinite. Blindly accepting all datacenter projects would create a direct conflict of use with reindustrialization or the electrification of our transport.

So there are two possible scenarios:

Choice 1, we suffer: we can indeed refuse these installations. Tech giants then create these capacities in the United States or elsewhere, sometimes by turning gas or coal plants back on, while selling us their services, imposing their terms on us, including environmental ones. Europe pays for the service, suffers the global footprint and loses control.

Choice 2, we choose: Europe and France assume building datacenters on their soil, but since electricity is not infinite, they use sovereignty to arbitrate and ration.

We will need digital sobriety. And being sober is not about refusing to build infrastructure at home out of ideological and moral posture. It's using our sovereignty to condition and select.

Being sober and sovereign means:

1. Rationing network access: Reserve our decarbonized electrical capacity for datacenters run by European actors or engaged in strategic uses (health, climate, research, industry), rather than to the overconsumption of foreign recreational services (yes, we can tell ourselves that Grok nudes and Ghibli-style images might not be the priority, right?).
2. Impose drastic environmental standards: Prohibition of water-cooled systems, efficient PUE (energy efficiency for short), mandatory ecodesign (for example recovery of waste heat to heat neighboring homes)
3. Bet on frugal models: Favor the development of smaller, specialized and "open-weight" AI models, far less greedy for computing power.

The overconsumption predicted by Big Tech is not inevitable. It's based on a financial bubble and lots of investments in closed circuits that sell investors a growth plan. This overinvestment makes it possible to fund loss-making uses, uses that shouldn't be free (like Grok on X for example), a multitude of frontier models, hundreds of software to do the same thing, tensions on resources minerals, tensions on components (see the ram crisis) even though some mass public uses are already addressed. We won't sort our emails faster with Opus 72. Most open source models are already sufficient for the vast majority of uses. We have already made enormous advances in optimizing training or inference costs. Technology continues to improve in energy efficiency but uses intensify. New chips have appeared, new algorithmic approaches have come to light. It's time to pocket our gains and invest now in these avenues.

I hope this bubble bursts to clean up the market. But on the other hand AI won't disappear with the bubble, any more than the internet disappeared after the internet bubble burst in 2000.

But I hope, for us, that a European actor remains after this explosion.

What is the sustainable trajectory?

So what's the limit? For digital to remain sustainable and not become an energy burden, Europe must impose a landing ceiling.

Instead of accepting the 230 TWh projections pushed by Big Tech and the current bubble, the sustainable trajectory for Europe is around 80 to 100 TWh/year by 2030-2035 (or about 10 to 12 TWh for France, which corresponds to the prudent scenarios of RTE). At this scale, the datacenter footprint would remain contained at less than 3% of European electricity.

This "electricity budget" of 80 to 100 TWh makes it possible to reconcile the two imperatives:

1. Fund sovereignty: Provide the computing power needed to develop our own champions, secure our data and run strategic industrial and scientific AI.
2. Preserve climate: Don't siphon off the decarbonized gigawatts that our electric cars, heat pumps and factories urgently need to get out of oil and gas.

Conclusion

Pitting ecology against sovereignty is a mistake. We won't chart a viable ecological course isolated in our own corner without economic and digital independence. But the other way around, we won't be able to continue increasing our uses indefinitely without hitting the wall of physical reality.

Building data centers is about rebuilding sovereignty and giving ourselves back the power to choose. It's not a blank check to build without limits. But it's the only political tool that gives us the right to say no, to set rules and enforce caps.

Refusing datacenters on our soil under the pretext of ecology is an illusion. It only exports pollution to neighbors with a carbon-intensive energy mix, while depriving us of the keys to our future. If we want a digital world compatible with planetary boundaries, we must have the courage to build its infrastructure at home, to have the power to dictate its rules.

In reality, it's a bit more complicated.

The Compromises

Sometimes there are services that I'm so used to using that I've forgotten they were US, I'm thinking of Sentry for example. It's a service I've been using for at least a decade and I really struggle to do without it. The worst part is that if I find an equivalent service, it's rather simple to get out of it but since it costs me 0 euros today, I tell myself it's not really an urgency either, I'm not funding a US product for now.

I gladly accept suggestions ;)

(EDIT I’m currently testing BugSink)

Critical Dependencies

Then there are critical services, open source, but very much US, I'm thinking of Let's Encrypt. One could tell me it's just plumbing, it's open source, we don't care etc… In reality, Let's Encrypt banned its use in Iran and Russia as well. This is part of the basic building blocks we should have in Europe to remain sovereign.

Among other critical services, there's payment. I use Stripe, and even though there's an official branch in Europe it remains a US product. There isn't currently an equivalent of this quality but we're starting to see some rather interesting products emerging, I'm thinking of Creem.io, Paddle, or Mollie. There are always little features here and there that prevent me from really making the switch but the alternatives are now serious enough to be usable in many cases.

But as of yesterday I'm facing a new obstacle, emails.

The Email Problem

Sending emails isn't as simple as it seems. So first, a quick vocabulary point, we're going to distinguish:

• transactional emails (password reset, address verification etc…).
• marketing emails, sent in bulk to multiple recipients (for example a newsletter)

Now that we know the difference, we need to understand that some operators refuse to send marketing emails for many reasons (desire to preserve their IP reputation to avoid being blacklisted, and to limit their exposure to certain legal risks related to how marketing emails are sent).

Unfortunately, Writizzy is a service that can be compared to Beehiiv and Substack. I send newsletters.

If I originally chose Scaleway, it was for two reasons:

• It's in Europe
• The cost per thousand emails (CPM) is 0.25 euros.

The Economic Wall

And that's where everything gets complicated.

CPM is the lifeblood. At this level, a few dozen cents difference completely changes the product's economics. All other competitors in Europe are between 0.4 and 1 euro in CPM. Between 2 and 4 times more expensive than Scaleway.

At that price, it's impossible to be profitable against my competitors. I can't sell a competitive offer with a CPM above 0.25 if I choose a European solution.

At this point, three choices are available to me:

• Build my own operator.

I can use an open source product (postalserver or hyvor relay), build what's missing on top and become an email operator myself. It's a titanic undertaking (really…)

• Switch to an American provider.

There are solutions at 0.10 CPM, up to 10x cheaper than some EU products !!

• Give up offering a competitive service.

In the long term, the 1st option seems most sensible to me. But in the short term, I already have customers, and economic necessity will take over.

Do we really want that to be the price of sovereignty? Being less competitive internationally?

And So?

It pisses me off to have to choose between my values and economic viability.

If I wrote this article, it's not to say it's impossible to build a European SaaS. On the contrary, I think it's increasingly realistic. The problem is no longer really finding alternatives. They now exist in many domains.

But they need to be competitive, especially on certain critical services where margins are extremely tight. Don't tell me we can't do it cheaper than a US service. I know the reality of US companies, salaries are higher, their marketing costs are higher, there's nothing that justifies us being between 4 and 10x more expensive. And it's not a scale issue either, by selling more expensive than the market, it's normal not to have more customers.

I will continue to favor European solutions whenever possible. Not because they're European, but because I want them to become the best one day.

In the meantime, some decisions will be dictated by economics rather than my convictions.

And we also need to speak up when something blocks us. Not to complain, but to show where opportunities remain. And there are some.

Context: several applications in monorepos (hakanai, Writizzy, Bloggrify), polyglot (Nuxt, Kotlin, JS), solo dev, code written largely by agents, continuous deployment to production.

::toc{open="true"} ::

The guiding idea

Even though the latest generation of agents are now capable of producing quality code (much better than the majority of human developers), code production represents only part of what I call software quality. The rest includes:

• the intention (why, for whom)
• does it satisfy the 4 risks identified by Marty Cagan:
  • Value
  • Usability
  • Feasability
  • Viability
• we can add: performance and reliability

Part of these risks is resolved with a good understanding of your market, benchmarks, interviews, manual testing, mockups. All of this is also part of my "software factory" even if I don't describe everything here.

The code produced is now almost 100% generated, but that doesn't mean it's vibe coding. Vibe coding as defined by Karpathy was experimentation and letting yourself be carried along by a dev session. Here, I'm going to talk about context engineering. The goal is to provide all the necessary context, at the right time, so that the software matches an intention and is systematically controlled. Even though I don't write the code, I'm responsible for it and I need to maintain control over it.

The tooling described here answers several questions:

1. What does the agent know? (context, memory, code graph)
2. What can it do deterministically, without improvising? (skills, procedures)
3. What stops it when it makes a mistake? (hooks, architecture tests, quality gates)

Layer 1: the context

Here are the files read by agents before starting. Be careful, the size of the context must remain controlled. Too large a context costs money and degrades the quality of responses if it becomes too heavy. We want to save tokens and optimize when information is loaded.

The separation matters: permanent context stays short, specialized context loads when it's useful.

Long-term constraint as context. Concrete example: I plan to open-source part of the code. The rule "code intended for open source should never depend on proprietary code" is written in the rules and verified by a test (see layer 4). Writing a future constraint in the context avoids paying for a refactoring later.

You can also find constraints on:

• marketing copy (labels in the application)
• how to write migrations
• types to favor for database fields
• asynchronism patterns
• etc. (list far from exhaustive and enriched regularly)

A constraint is specific to a project and a person. It's not a matter of software quality in the strict sense. It's not better or worse to do feature flagging for example, but it's my preference for partial deployment and feature activation in testing.

There's no point in telling an AI to "write quality code", it doesn't make sense. You need to make your own constraints explicit.

Example of a rule that allows deferred loading depending on context:

Every time I ask you to commit, use the commit-convention skill

It's simple, but it avoids loading the entire skill in a rule (which would be loaded systematically).

Here's a more complex rule:

---
paths:
  - "api/**/*"
---

You act as a Senior Expert in Kotlin and Spring Boot (DDD, Spring, JPA).
You have patterns to follow. BEFORE writing code, you MUST invoke the skill corresponding to the task you are performing.

## Skills to invoke depending on the task

| Task                                                                           | Skill             |
|---------------------------------------------------------------------------------|-------------------|
| JPA entities, repositories, data model                                          | `kotlin-jpa`      |
| Database schema changes, Flyway migrations, and Hibernate/Kotlin entity mapping | `db-migration`    |
| Services, business logic, transactions                                          | `kotlin-services` |
| Controllers, REST APIs, DTOs                                                    | `kotlin-api`      |
| Unit or integration tests                                                       | `kotlin-tests`    |
| End of task, validation before confirming                                       | `kotlin-review`   |
| Feature gating by plan (offers.sql, FeatureService, quota, conditional access)  | `offers`          |
| Unleash feature flags (progressive rollout, admin-only, maintenance, runtime toggle) | `feature-flags` |
| RabbitMQ producers, consumers, outbox pattern, retry/quarantine, AMQP config    | `rabbitmq`        |

Here there are two important things:

• the activation pattern, which specifies that this rule only loads if you touch the api directory
• the table that lists all available skills, to be opened only if needed. If the AI doesn't make schema changes, there's no point opening the db-migration skill

Layer 2: the skills

A skill is a procedure written once, replayed identically. The agent loads it itself when the context matches. This automatic loading can sometimes fail. In that case, you need to explicitly ask to use the skill.

The criterion: am I repeating myself? If I explain the same thing a third time, it becomes a skill.

I have about thirty, grouped by family:

Two things I've learned:

• "Multi-file procedure" skills are the most profitable. Example: adding a block to the content editor touches three different rendering surfaces. Without a skill, the agent systematically forgets one.
• "Up-to-date doc" skills are very important on code that evolves quickly. It allows an agent to understand the entry points and intentions of a feature.

Sub-agents: for tasks that generate a lot of reading without much decision (audit, broad exploration, doc writing), I delegate to a sub-agent. It consumes its own context and gives me a conclusion, not a dump of files. I use them less and less, recent agents make their own fairly targeted delegations.

Layer 3: the tools

You often hear that an AI is non-deterministic and can make mistakes on trivial things that need to be deterministic, like calculating 2+2.

That's largely false now, and an AI is no longer "just an LLM": it has many tools to control output. Nevertheless, the best way to ensure a form of reproducibility is to delegate to tools whose job it is.

Compilation, test execution, linters, all of that is delegation. You can delegate to MCPs, or to skills that use themselves a command-line tool (CLI). I try to avoid MCPs which consume more context, but I have a few anyway.

MCP

GitNexus

The repo is indexed in a graph (symbols, relationships, execution flow). This allows you to measure impact levels and find all links with the code being modified:

• impact(symbol) before modifying: blast radius, callers, risk level
• detect_changes() before committing: did I only touch what I wanted to?
• find an execution flow rather than grep a function name
• rename via the call graph rather than find-and-replace

The real issue isn't speed, it's detecting all side effects of a modification.

Claude-mem, persistent memory

I use two levels of memory:

• Claude's internal memory
• Claude-mem, which allows capturing decisions between sessions

What we want with these tools is to avoid repeating mistakes, document decisions, and not start over with an empty session each time.

Claude Code's internal memory mechanism has improved and becomes more relevant than before with the latest versions. However, you need to control it and not hesitate to ask it to delete rules it creates on its own which are sometimes a bit silly. Claude-mem, I honestly have a hard time measuring the negative or positive impact. I don't have enough perspective on it yet.

Output filtering

A wrapper (here RTK) prefixes shell commands and only returns what's necessary. It remains very limited, only available for a few tools. The gain is sometimes canceled out because Claude runs the command twice. It doesn't hurt, but I think there's still room for improvement. Note that Claude builds its own tools on the fly in Python or Bash, and also knows how to use filtering mechanisms with grep, tail, etc. to optimize the outputs of the tools it uses itself and save tokens.

Debugging with access to logs and database

I use two skills for incident resolution:

• a Sentry skill to read information on Sentry and retrieve stack traces
• a db-query skill that gives read-only access to the database (read/write access is possible directly via psql on the Docker container in local dev)

I could also mention the Stripe MCP, read-only as well, which allows in certain specific cases to investigate Stripe configuration issues.

Layer 4: executable guardrails

Guardrails prevent the randomness associated with understanding and executing an instruction. It happens that an LLM ignores a rule. You need to provide tools that execute automatically.

Hooks

Scripts triggered by the agent harness, not by the agent itself.

Other uses that work well: block editing of generated files, require a test alongside any new module, forbid a dangerous pattern.

Architecture tests

Structuring rules become tests that break the CI.

Real example, I have an architecture test that preserves the boundary between future open source code and the rest:

• no file on the "open" side references the "proprietary" side
• every production file belongs to one of the two sides

It's part of the automated tests, so it can't be bypassed, unlike a rule.

Pattern linting

I use several things:

• ESLint for syntax
• ast-grep for architecture decisions, for example forbidding any call to fetch without going through the OpenAPI client
• typecheck for typing

Layer 5: the factory

One blocking quality gate, per application

Each app has its workflow on GitHub Actions.

push to main
   └─> quality gate: lint → pattern lint → typecheck → tests
        └─> build docker image
             └─> push registry
                  └─> deployment webhook

The deployment job has a needs: on the quality job. Nothing goes to production without passing the gate. It's essential in general, even more so for automatically generated code.

Test at multiple stages

I shouldn't need to re-explain this, but just in case, I have several types of tests.

I give Claude instructions to explain the test hierarchy, gitnexus tells him what to replay to validate these modifications, and he has instructions to write them when he adds/modifies code.

Layer 6: the product process

As I said in the intro, the goal isn't just to produce code, it's to produce code that serves a purpose.

The process often starts with a spec, then a design, then an implementation.

Spec first. I have a folder of numbered specs, one per functional domain, indexed in the permanent context. Two skills frame the cycle: one for writing the spec and its plan, one for closing it by updating it with what was actually built.

This spec and the discussions can rely on a 'product-marketing-context.md' file that I create in each project and which summarizes my personas, my competitors, my positioning etc...

The design. By design I mean two things: technical design and interface. Technical design is part of the spec phase. Most of the time a spec is enough, but some tricky cases require a spec dedicated to a technical component or a technology choice. On the other hand, the design/mockup phase is separate. I do it in Claude Design. I make a functional mockup and iterate until it's perfect. I verify understanding, labels, usability. Then I can pass the result to Claude Code.

The implementation. Claude starts from the spec and mockup. He follows the plan made in the spec phase. The spec is meant to be delivered in stages (protected by feature flag). This allows me to do several small implementation sessions rather than one large session, which tends to degrade in quality if it gets too full.

The closing step is important: without it, specs become obsolete in six months.

Explicit rule in the context: if a spec is vague or inconsistent with what exists, the agent should ask the question, not guess.

Progressive delivery.

I work trunk based. However I use feature flipping and gating, which represent two different things:

I have skills that explain the difference, so agents don't do anything wrong and respect my working process.

Where to start

If you're starting from 0, the first step is the quality gate if you don't have one. You need a control mechanism that runs tests, linters etc... Then start light with a Claude.md that describes the essentials, the why. Add rules as you go for important architecture patterns. As soon as you see procedures that come back often, document them as skills. And then equip yourself with cli and MCPs to interact with your main tools, jira, sentry, etc...

Be careful, any skill, MCP, code taken from outside must be scrutinized. These are dependencies that can be vectors of attack.

Key takeaways

1. What matters must be executable. An instruction is followed "most of the time", but it can be forgotten. A hook or test is followed all the time.
2. An error must be documented. Every error must be recorded in a skill or in memory.
3. Context is a budget. Wrappers, filters, sub-agents, summaries: everything that reduces noise keeps reasoning on the problem.
4. Measure impacts before and after editing. We want to avoid the effect "1 bug fixed, 10 produced".
5. Repetitive procedures don't improvise. One skill per procedure.
6. Spec documentation dies if its closure isn't in the process. You need to plan the update and maintenance step.

To improve

Updating skills/rules

You need to take into account that the technology is still very young, February 2025 if we consider agentic programming. Tooling is improving but you also need to constantly review it. Mid-2025, some instructions in a Claude.md made sense, for example "write a test for each new service". Today it's noise and Claude does it naturally. So you need to be wary of your old rules, sometimes they're obsolete and create noise. I have no way to measure and know if an old rule has become obsolete.

Latest versions of Opus are increasingly autonomous. AI takes the initiative on its own to build, look at produced content, read dependency code to understand calls, find bugs, run tests in the browser. It's almost creepy and more rigorous than 99% of humans. Let's be honest, I'm increasingly less useful in implementation phases, but I don't want to lose control of the produced code. I'm torn between satisfaction at having an increasingly efficient software factory and the risk of losing knowledge. I need to find a way to control designs a posteriori, to appropriate the result.

The rabbit hole problem

I recently added a boyscout.md rule

Always leave code a little better than it was before. If you see flagrant errors, report improvements to me. If you notice gaps with documentation or information present in your skills, or in this file, same thing, report them.

But I find myself having endless sessions. I think I've never worked on a codebase that maintains itself as much. I've rarely improved the product at this level of detail. But it comes with a cost, cognitive overload.

I think I'd rather automatically note these elements and categorize them in an online TODO list (trello, todoist etc...). I think the workflow for maintenance should move elsewhere, and be partially automated.

Lack of standardization

I still copy and paste my skills/rules etc… from one project to another. And sometimes it's dependent on my station based on a skill installed locally.

I need to find a way to package my skills to deploy them where relevant and to centralize maintenance.

The rest

In other pending improvement points:

• my dependency on Claude. I want to test open weight models but I don't have the hardware for it. Moderate risk in my opinion, the entire ecosystem is moving upward
• the IDE is becoming obsolete compared to this new workflow. I still use Intellij but I no longer find it suited to our time. I haven't seen an interesting alternative yet.

Or… why not?

I'm developing a product, writizzy.com and I started asking myself this question by wondering how to make sustainable software? Is open source a path for that?

Beyond sustainability, I've been working since the early 2000s and overall my profession has drastically changed. One of the main reasons is linked to the rise of open source.

Sure, when I started my computer science studies in 1997, we were already working on linux with many open source software, but my first experiences in the working world looked more like archaeology. My mission was to find the scattered documentation CDs on the floors, and to question the right experts to understand why the software we used reacted in such or such a way. Without access to the source code, I had to guess how it works and especially I had to reinvent the wheel constantly for pretty much everything, which resulted in very questionable quality software.

I saw my profession change and open source become one of the foundations of all modern computing. So yes, I want to contribute in turn.

But I'm concerned about the constraints that come with it.

I'm torn between the desire for a return to a more open web and, basically, economic imperatives.

It's this dilemma I want to explore here. Through the example of Writizzy, here's why I'm hesitant to open my code, what I would nevertheless like to do, and what I'm considering for the future.

The benefits of open source

Well first, why do open source? Off the top of my head I'd say:

• to contribute to an ecosystem
• for wider distribution
• for contributions and serendipity
• for transparency
• for a more open web

But as we'll see, it's not that simple.

Simplified marketing and distribution

Let's be honest, open source is a communication lever. Open source allows wider use and thus gets known through word of mouth. It's the possibility of having providers that would offer Writizzy as white label, or users who could make their own themes/plugins and sell them on a marketplace (like Ghost). It seems like nothing, but once an economy is established around your product, it guarantees it a certain notoriety. It's free "advertising".

Ok but, at what cost?

Whether it's Wordpress, Ghost or Gitlab, how many really use the commercial service offered by the publisher? And how many commercial services have attached themselves to these software, while avoiding contributing directly to the open source project?

Here are the estimated annual revenues for several competitors of Writizzy:

• Substack: $45M
• Beehiiv: $30M
• Ghost: $10M

Ghost is the only open source platform of the 3. It's estimated that the economy revolving around Ghost creates approximately between $15 and $25M.

That is to say that approximately $20M is captured outside of Ghost.

Let's imagine that Writizzy works, let's be crazy, don't I have the risk of having actors who commercially exploit Writizzy, don't contribute to the open source project, benefit from my advertising investments, and leave me to manage all the difficulty of software maintenance?

Yes open source is noble, but it doesn't put food on the table and I don't want to end up like one of these countless open source projects that survives poorly and eventually closes.

Two options are possible, having a restrictive license that prevents commercial use, or just… not care.

Ghost doesn't care. Because it's a company without shareholders to pay and they're not seeking to maximize their profit.

But if I think about it well, it's the same for me. Well first, I would be very happy to have even just one tenth of Ghost's success. If I manage it, in part, because the open source model allowed the product to be talked about, I can also tell myself that I've achieved my goal, right? And besides, it would be hypocritical of me, I also use open source building blocks to go faster, right?

I'm creating a commercial product, I'm not going to hide it. But I'm not aiming to create a multinational company with 400 people, so having an ecosystem that's created around the project and that lives on its own but that also increases the visibility of the project, why not?

But anyway, I don't want to make you think that "open source = success" magically. If the project interests no one, it will maybe be the same even in open source. It's kind of what happened to me on Bloggrify.

(Unexpected) Community Contributions

You know how a product improves? Through feedback from its users.

I'm used to saying, "you're never right on your own".

You can be an expert in your own software, it's when confronting it with real users that this software becomes truly perfect.

Because each user can come with new ideas, because you can measure what matters most to people and therefore better prioritize what needs to be done or because you can have direct contributors.

If someone improves your product, it's a useful contribution for everyone.

But that comes with a cost, having to respond day and night to hordes of users, not always respectful of the work provided for free. Remember:

• Jacob Thornton, co-creator of Twitter Bootstrap who clearly ended up burned out
• Salvatore Sanfilippo, creator of Redis who also ended up cracking

Finally, that's when there's success. The vast majority of the time, your project will just have 0 users and almost no feedback.

In the past, I had created two projects that fell pretty much into this category:

• pg-mongo-streamer: a connector to feed pgsql by replicating mongo events in real time
• Bloggrify, a static blog generator, a kind of equivalent to Jekyll in the Nuxt ecosystem

In both cases, the user base was very small so feedback was almost nonexistent. In the case of Bloggrify, it mostly became a burden of trying to implement certain open source project standards for virtually no results.

In any case, yes, this dimension scares me. I can only hope that Writizzy has traction and find myself in the first case. And at the same time, I'm afraid I won't be able to keep up.

I'll admit I largely understand Ben Johnson (litestream) who chose to limit the opening to contributions to protect his mental health and the viability of the project, in other words, choose open source but limit contributions. Today, my issue isn't going faster in terms of code production anyway.

Now when I talk about contributions, I also think in terms of ecosystems. It's the opportunity that things are created unexpectedly. It could be theme marketplaces, community hosting, plugins, … things… by definition if it's unexpected I can't really list them anyway :)

Transparency: Exposing Your Weaknesses

An open source project inspires trust, in theory. It gives the illusion that, being open, all of its code has been blessed by a community of experts.

In reality, open doesn't mean being read. I doubt you've read the source code of the vast majority of tools you use under linux, for example, and you're not alone. We could cite the xz backdoor affair or the log4shell CVE.

In any case, I remain convinced that it's preferable to closed software. Does security through obscurity really work? Not really, and sometimes it's the publisher itself who places backdoors in their software.

But precisely, if I open Writizzy's code tomorrow, I'm not entirely confident. I did everything possible to make it well-designed and secure software, but let's be honest, am I 100% sure that no one will find security flaws? Not at all. A friend had actually detected flaws in Writizzy a few months ago. I have users in production, what happens if malicious individuals actively search for flaws in my code with each release? That's clearly part of my concerns.

As for the "quality" of the code, that's another topic. I would always find people to criticize it, but I've been working for 25 years, it slides off me a bit. Criticism is easy, art is difficult. But for security, that's another matter, impossible to ignore.

And today I don't have a sense of versioning. I deploy to production continuously. Should I abandon this principle to leave a rest period before deploying a new version? It would be extra burden I'd impose on myself and I don't necessarily have the luxury to do so.

So yes, partially today I'm counting on the fact that no one can read the errors I may have made before I fix them. If it were open source, that would no longer be the case. It would impose another way of working on me, heavier, and more dangerous for my users. That's clearly a brake.

Is Writizzy's Architecture Compatible with an Open Source Project?

Another point that worries me, once I open the code, is that Writizzy has certain architectural complexity. To run the application today it's:

• 1 Kotlin API
• 1 front app for the CMS part
• 1 front app that runs the blog
• a PostgreSQL database
• a RabbitMQ message queue

A user might want to have a single application and I understand that.

All my architecture is based on the fact that I run all the clients on the same instance in multi-tenant and I have the entire commercial site that exploits my users in the "CMS" application.

How can I offer that as open source? It's very far from a standard like Ghost or Wordpress.

Well, that wouldn't be the only software like that. I recently installed PostHog and you just need to use a Docker compose to hide this complexity, so I suppose we can find a solution. I even want to say that it's become the norm, nowadays the unit brick for installing is the docker compose.

On the other hand, I imagine I would really need to separate the admin part and commercial site from the CMS (EDIT: that's been done as of today). That part would remain proprietary. And we'd need a "mono-tenant" mode to hide all the complexity of multi-tenancy so that a user can just launch their app for themselves.

If I have some ideas, they remain additional constraints nonetheless.

So what's the plan for Writizzy?

Well then, what's the plan? I'm building Writizzy with a desire to also find a more open web, to get out of US platforms, to encourage people to write too. Because writing, reading, informing, is more than necessary in today's world.

In a previous article I was questioning whether to create sustainable software, open source was part of the solutions.

So yes, I'm torn. I'd like at some point to make it an open source product. Concretely, I've started making significant modifications to the software to separate the "commercial" part from the application itself. I have a trajectory in mind to isolate what belongs to my application that allows me to sell and host Writizzy, from the rest, the CMS and the blog.

It's in progress. It also allows to reflect on dependencies, to simplify. But maybe it won't work out.

I don't want to repeat the mistakes of Bloggrify (too much burden for not much). And maybe I should wait to see that Writizzy has more hype behind it? Many questions, few answers :)

In any case, if you have experience with opensource projects, I'd be interested in your feedback.

a+

You could tell me I have a short memory. The internet sparked plenty of criticism around the destruction of brick-and-mortar retail, print media, and the end of human interaction. Same for mobile, with added, legitimate reproaches about addiction and the ease of surveilling individuals. We could also mention crypto, a massive Ponzi scheme for some, a way to reclaim power from central banks for others.

And yet, with AI, I feel like we've crossed a threshold. There would be only two possibilities:

• The Doomers (declinists) who envision an ecological apocalypse, total destruction of employment and placing public opinions under the guardianship of Big Tech controlling AI.
• And the Bloomers (accelerationists), who advocate blind faith in progress, convinced that AI will liberate humanity, eradicate diseases and generate infinite growth, and for whom slowing research is the real crime.

Pick a side, friend, and if you don't, others will do it for you. The "safest" bet is not to talk about it at all, but burying my head in the sand feels cowardly, if not impossible when you work in tech.

Simply put, I need to stick my head out and try this exercise without resorting to clichés. And since we're in the middle of a heat wave, it seems obvious that the first subject to address is ecology. Is AI as catastrophic as people say? Is the impact of an AI query truly astronomically higher than a Google search? How does it compare with other digital uses? Let's take some time to look at all this.

Ecological Impact of AI

First, let's establish some basics about what we call ecological impact.

This impact falls into several categories:

• Electricity consumption (which translates into CO2 emissions)
• Water consumption for cooling data centers
• Resource extraction, required to build the data centers and user devices themselves

To keep things simple, an AI consumes energy at two distinct stages: during training (when the model is created, like Gemini, Llama, Claude, etc.) and during inference (when users actually query the model).

Electrical consumption during training

When looking at carbon footprints, models vary wildly, but the estimated range for training a single major model sits between 500 and 12,000 tonnes of CO2 equivalent.

To put that into perspective:

::callout{type=primary} The massive gap between US and French household equivalents stems from the fact that France’s energy mix relies heavily on nuclear power, which is virtually carbon-free. ::

Electricity Consumption During Usage

Operational consumption is another moving target. It depends on the complexity of the prompt, the location of the data center (and its corresponding energy mix), the model being used, and so on.

But it's estimated to vary between 0.03g, and 1g of CO2 per request. We'll see below how that compares with internet, gaming, streaming etc…

Water consumption

To talk about water consumption, we must first address a common misconception: No, we don't destroy water.

Earth’s water operates in a closed loop. When water is used in a cooling system, whether in a data center, nuclear power plant or anything else, it's not destroyed. When water evaporates, it eventually falls back as rain.

However, evaporation causes water to displace. If water moves more than 800km, the region where it was drawn from has effectively lost it, temporarily but lost nonetheless.

In ecology, we distinguish water withdrawal (borrowing water and returning it to the same place after use) and water consumption (drawing water and evaporating or releasing it elsewhere, making it unavailable locally). AI consumes water.

On a planetary scale, it's not necessarily a problem. On a local scale, however, it can trigger severe water stress, creating direct competition between residents, agriculture, and data centers.

To be fair, technology is advancing. The majority of new data center projects use closed-loop water systems so water isn't evaporated. Some countries (Ireland, Sweden, Finland) take advantage of their cold climate to reduce water needs by 90% and we see other systems emerging. But to look at the flip side, the vast majority of existing data centers use evaporation systems and in any case, these systems require electricity which creates tensions, for example in Sweden or Ireland.

Now that we've said all that, what's the consumption for evaporation data centers?

Training a recent model is estimated to consume approximately 40 to 80 million liters (a small lake). In a water-stressed region, that can make a difference.

And if we look at usage, for a request, it's between 2 and 6.5ml of water per request.

Resource extraction

::callout{type=warning} This section is the trickiest for me because it’s the one I’m least familiar with, and honestly, it probably deserves an entire article of its own. So, while we will only scratch the surface here, I promise to dive much deeper into this specific topic in a future post. ::

We often focus on electricity and water, but the environmental footprint of mining is one of AI's biggest blind spots.

To run AIs or train models, you need ultra-powerful equipment and colossal infrastructure that will require copper, aluminum, cobalt, lithium, nickel, rare earths and I imagine I'm forgetting some.

Well, these resources are in limited quantities on earth but I'll discuss that in a future article, recycling in this sector is currently negligible but moreover, the extraction itself is extremely polluting.

To make matters worse, we must add that current equipment becomes obsolete much faster. In the AI race, we replace equipment much faster. Certainly, new equipment is more efficient, particularly in terms of energy but this ultra-rapid rotation creates a volume of electronic waste we don't know how to manage.

Despite everything, I don't yet know from which angle and with which figures to illustrate all this, especially since these subjects also pull along many other geopolitical subjects (tension over Taiwan, tension over rare earths etc…), so we'll set that aside for future publication. We already have plenty to do with the first two subjects.

AI vs. Other Digital Habits

With these orders of magnitude in mind, is AI "stratospherically" different from the rest?

How does it compare with a Google search for example? Or with streaming, video call, an online video game?

AI vs Internet

By comparison, a query to a search engine (Google) is approximately 0.2g of CO2.

Depending on the complexity of the question and the model used, an AI prompt can cost slightly less than a Google search, or up to five times more.

So, it is not "stratospherically" higher than a standard web search.

Furthermore, if a topic requires you to do multiple Google searches and open several websites to find your answer, the gap quickly narrows, and can even reverse.

But we must separate simple uses: "give me the strawberry pie recipe", from complex uses: "analyze this PDF document of several megabytes for me and create an application that displays results with charts".

AI vs gaming vs streaming vs video call

I propose we do an exercise and compare 1 hour of streaming, 1 hour of gaming, 1 hour of video call, and one hour of AI-assisted software development (a relatively power-consuming use).

::callout{type=primary} Why such strong variations when considering AI-assisted development? Because it encompasses vastly different habits. Consumption will be drastically different between an "amateur" coder copy-pasting a few lines from a browser, a "pro" user partially delegating tasks within their code editor, and an "intensive" power-user running automated tools where code generation is almost entirely outsourced. ::

In other words:

• There is only a 2x ratio between gaming and professional AI-assisted development.
• video call is what consumes the least
• Streaming is remarkably close to professional AI development usage

No matter how you look at the data, it is hard to find evidence of a "stratospheric" gap.

What About Creation Costs?

And to go further, we could look at the impact of AI model creation compared to the ecological impact of creating a video game, or a movie.

An AAA video game (big-budget), developed by a team of 150 people, costs between 500 and 3,000 tonnes of CO2 depending on development time, travel, and motion-capture filming. To this, we must add the annual maintenance for live-service games that push out continuous updates and DLCs (like World of Warcraft or Overwatch).

For a big budget film, we can estimate a carbon cost between 3,000 and 4,000t of CO2, including transport, filming locations, generators, set construction.

Granted, training a massive AI model can cost more than a single movie, but the difference isn't orders of magnitude apart. More importantly, we must remember that the world releases thousands of films and video games every year, whereas the creation of new foundational AI models remains relatively rare.

So, is AI Not That Serious After All?

Let's be careful here. It would be lazy whataboutism to simply say, "Sure, AI is bad, but look at how much worse everything else is." That is missing the point. The real goal here is to question our consumption habits as a whole.

What is certain, however, is that the reality is far more nuanced than the mainstream narrative suggests. Today, the hyper-focus on AI serves as a very convenient distraction, allowing us to forget the environmental cost of our other digital habits. But you don't earn moral virtue points by campaigning against AI while actively indulging in online gaming, streaming blockbusters, or flying to international sports events.

If you've followed the numbers well, the ecological impact of AI is relatively close to other impacts in digital (streaming and gaming for example).

That doesn't mean it's good. In the world we live in, each additional tension on the planet is to be questioned.

But it forces us to realize that all of our digital behaviors need to be reassessed, not just the fact that "I asked ChatGPT a question."

I don't pretend to be able to rank these activities against one another. Comparing gaming, streaming, and professional workloads is highly complex. And even within professional uses, And I certainly won't decide, on my own, what constitutes a "good" or "bad" use of technology. But collectively, we might soon be forced to make those choices, not out of kindness, but by constraints (See next chapter).

The core issue isn't about outright banning AI. This is precisely what organizations like Shift Project, France’s leading think tank on the energy transition, are trying to convey: we need to look at data volumes and digital use cases in their entirety. The argument isn't that we should abandon AI altogether, but rather that we cannot afford its current, unchecked trajectory

Let's take an example: the FIFA World Cup generates between 9 and 15 million tonnes of CO2, which is roughly equivalent to the annual energy consumption of all US data centers combined..

Again, the idea isn't to say, they do worse. We'll get nowhere with that mindset.

But I like this example because of the contrast it highlights. Playing football doesn't cost much. Gathering thousands of people across 3 countries and having them fly everywhere is absurd, as is air-conditioning football stadiums, or trying to organize winter games in a desert country.

AI operates on the exact same spectrum. There is a massive gulf between a professional, high-utility application, like using AI in biochemistry, mathematics, meteorology, drug discovery, medical imaging, satellite analysis, or precision agriculture, and a purely recreational use aimed at generating thousands of Ghibli-style images just to dump them on social media. Yes, we can, and should, question the latter (and that’s an understatement).

Ultimately, understanding these orders of magnitude is what empowers us to make informed choices instead of just parroting the absurdities we hear on TV. Once you know the real numbers, you can weigh your choices accurately.

I said earlier that one hour of video call was between 30 and 60g of CO2. Ok, but that might replace a Paris Lyon trip. By car it's between 60 and 90kg of CO2 saved. By train it's about 1kg.

Similarly, one hour of streaming costs about 100g of CO2. But if it prevented you from driving 20km to the local movie theater (which would cost around 4.4kg of CO2 in car emissions), streaming turns out to be "not so bad" after all.

In the end, once we have the data, it is up to each of us to make those choices.

What About the Explosion of Data Centers?

A question I asked myself before writing this article was:

If the carbon footprint of AI is actually pretty close to our other digital habits, and assuming it replaces some of them (if I’m using AI, I’m not doing something else), why on earth are we building so many new data centers?

Ok, this question might seem naive but it's estimated that data center electricity consumption could double, or even triple by 2030 (See BCG study and this IRIS article). So why? Is it linked to AI?

According to articles, partly yes, but only partly. The majority of electricity consumed by data centers (about 2/3) should be dedicated to historical digital uses and acceleration of cloud migrations.

Yes AI plays a role, but it's mainly that digital is taking up more and more space. The share of digital in global CO2 emissions went from 2% in 2010 to about 4% today, with an annual increase of about 6% even though the global objective is to reduce our emissions by 5% per year to hope to ++stabilize++ the climate.

Where AI genuinely worsens the problem compared to other tech is its rapid hardware obsolescence. However, the root cause is the massive scale-up of all our digital habits: the ubiquity of 4K/8K streaming, cloud gaming, high-fidelity music streaming, and the explosion of connected IoT (Internet of Things) devices.

Forecasts vs. Financial Bubbles

Of course, we should take these data center growth forecasts with a grain of salt. They remain predictions. They could easily be overestimated, just like the predicted "tidal wave" of data that was supposed to arrive with 5G but never quite materialized.

Many of these projections are pushed by tech giants that have bet their entire financial futures on these exact growth scenarios. If you are Nvidia, Google, or Oracle, you have no choice but to reassure your shareholders by guaranteeing this growth will happen to justify the colossal investments already made. Honestly, if the AI financial bubble were to burst tomorrow, it might actually be good news for the planet, as it would instantly ease the pressure on our resources.

That being said, we are looking at contracts that are already signed, budgets locked in, and massive public announcements, like the Stargate project or Europe's future investments. Every current scenario predicts a 2x to 3x increase in demand. Digital consumption is going up, and AI-related infrastructure is leading the charge.

Will these digital habits replace physical ones (like my earlier example of a video call replacing a car trip)? Or are they purely additive? Evidence suggests they are additive. While some AI applications will certainly accelerate decarbonization in specific industries, that impact remains relatively marginal for now.

And, according to the Shift Project, it's mainly that the electrical consumption needed to run all these data centers will exceed our infrastructure capacity, and thus force using thermal sources (gas power plant) to compensate or create usage conflicts.

So yes, it's alarming. Again, it's not about banning AI, the subject is much more global than that. How do we make our consumption and pressure on the planet decrease?

At our individual scale, we have to audit our own habits. We need to question our obsession with upgrading devices, over-equipping our homes, and engaging in mindless, heavy recreational uses (like generating endless Ghibli images just for a laugh).

At a collective level, we will eventually be forced, likely much sooner than we think, to make hard choices. We will have to decide whether to route precious electricity to a data center or to power and heat local homes.

But let’s remember one crucial thing: the future isn’t set in stone. If we collectively choose to consume less, we won't need the electricity these companies are dying to sell us. If data centers are multiplying, it's only because there is a planned demand for them. To paraphrase a famous French comedian: "To think that if people just stopped buying, it wouldn't sell anymore!"

We are in a classroom, unhygienic and unheated, like all suburban Paris classrooms, because the high priests of 'Macronomics' decided it was more interesting to pay millions of Euros for McKinsey PowerPoints than to actually invest in our future! ... I'm getting off track

Briefly, a circle of people gathers, on small wooden chairs that hurt like hell. I'm present, looking grim. Actually no I wasn't listening to Jean-Michel who just spoke but I'm still trying to understand how the Spurs managed to mess up so badly in the last games of the 2026 NBA Finals.

And then I get up and introduce myself.

"Hello I'm Hugo Lassiège, I'm first and foremost a backend developer and here's my first version of Malt in 2012"

Basically, I'm terrible at design.

So how in 2026 do I manage to propose designs like this blog's? That's what I propose to show you in this post.

2011, the army of clones

::callout{type=primary} If the somewhat historical part doesn't interest you that much, you can skip directly to the next sections to go to my current workflow which is described further down. ::

2012 was quite a long time ago and at the time I was using Bootstrap primarily, which explains that little very characteristic style from the first screenshot (mixed with frankly questionable aesthetic tastes, I'll grant you).

Because yes, in 2011 a framework came out, Bootstrap if you've been following, which offered to make available the official UI kit used at Twitter. Inside we found the guidelines for making buttons, forms, progress bars, all in the spirit of the blue bird. We also found all the tools to more easily build responsive websites with the famous grid system that would last a long time. A very long time.

For backend devs like me, that is to say those with more than modest taste for design, it was an opportunity to start with simple bases to finally make websites that don't look like they came out of a koala's acid trip imagination.

Following Bootstrap several other libraries came out, Foundation, Materializecss, and so on but always with that little syndrome for sites using them of "but damn, what is this army of clones".

From atomic design to design systems

Now it was nice to have a standard grid and buttons, but you still had to assemble them together. If buttons, input fields, text blocks were atoms, you needed to give a structure to assemble them in the form of molecules.

::gallery ::

This is exactly this analogy that would be progressively pushed starting in 2013/2014 by Brad Frost, under the name of Atomic Design.

This notion of molecules is really what you might call a component. A component fixes the assembly of our molecules as well as a behavior. And that's exactly what we find in several frameworks released in the same period, React (2013), Vue (2014) and even more generally Web Components (2011).

As an aside, in my previous company (Malt) we grew in the same period, we thought it would be a great idea to mix all of this. We did Bootstrap, then we grouped all of that with an in-house framework (HopModules), we added Vue around 2015, then built Web Components, then used Nuxt a bit later to finally realize around 2023 that actually, that was a lot of everything...

(But it's another story I tell here).

Briefly, we started building "components" that we assembled, standardized to finally arrive at what we call today, a design system, that is to say sorts of Lego bricks that you can assemble together and that guarantee a certain identity, a voice for a site. Design systems that are even often public and that you can find and study on different sites.

Tailwind and design tokens

To build a design system, there was a missing brick. It's nice to say for example that your buttons have a border radius of 4px. 4, not 2, not 6 but 4.

And it's rather simple to express globally:

.button { border-radius: 4px; }

But imagine you also want to align this radius on all your cards?

Imagine you want to define a global padding, a "primary" color for your main buttons, the possible font sizes across the entire site.

If the button is the atom, in reality there was a missing element below, how do you create our atoms?

During the 2010s (perhaps via Jina Anne at Salesforce in 2014), someone introduces a new term: the design token.

A design token is the definition of the interface structure by these tokens.

For example:

• #0055ff becomes the color-brand-primary token
• 16px becomes the spacing-medium

etc...

And that's exactly the approach of Tailwind in 2017 which arrives with definitions of design tokens via a bunch of utility classes that will become very very used in current websites.

So, Tailwind doesn't get unanimity for many reasons and it was never introduced at Malt. But for my new projects, it became the default solution. And now we can talk about my design workflow :)

My pre-2024 workflow, Tailwind and its component libraries

Pre-2024 (soon we'll talk about the pre-AI agent era...) I launched Hakanai.io. Let's not fool ourselves, it's better than what I was doing in 2012, but it's also as cheerful as an autumn day in Melun.

Despite this, here we find my 2024 design workflow, the use of Tailwind and component libraries such as preline.io or Flowbite.com. It's an assembly of more or less visually coherent blocks but which have the advantage of having structural coherence through Tailwind's design tokens.

It seems like nothing but it's already good. The spacing and breathing are consistent, the colors give an identity, the fonts are uniform, in short, it's a design system properly used. So yes, even Harry Potter drained of his soul by a Dementor looks better, but it works.

And that's broadly the spirit of most "indie" sites released in that period. Correct. But nothing to write home about.

And then came AI

Starting in 2024 through early 2025, my workflow became less manual. I started building interfaces by asking Claude to do it. It was still copy-paste between the chat in the browser and my IDE. It was only HTML/JS/CSS and then I did the adaptation by hand.

And then Claude came into the IDE, so it could directly create mockups in my code. However Claude reproduces the style it sees in the other pages, so since the site was created pre-2024, well it reproduced my somewhat "meeehhh" style from before.

So already in 2025, I started changing my workflow for certain pages and especially the first themes available on writizzy.com. I started from a blank slate, giving some constraints but making sure Claude didn't rely on existing work.

Sometimes I asked it to draw inspiration from known software, here with Notion:

Despite this, Claude has a certain tendency after a while to produce pretty much the same patterns and you can increasingly recognize an interface made by an AI. It's clean, it's better than what I produce alone, but it lacks originality. For admin interface in a SAAS it's not a big deal but to stand out on the internet, you have to make more effort.

I started seeing skills appear to avoid the "slopification": tasteskill and impeccable but which I haven't personally tested. On the other hand, for some time I've been systematically using Claude Design and there, I see a significant improvement in what I produce.

First, what is Claude Design?

Claude Design is specially optimized for interface creation, whether for its system instructions which are optimized for UI (but not UX!!), and through its tooling.

CD will indeed be able to visualize the result and iterate autonomously via screenshots. You'll be able to have a "tweaks" panel to visualize options, make low fidelity mockups or finished interfaces, comment on areas, etc...

But especially CD can start from a screenshot to get a vibe. So if I take the tux theme we can see in the screenshot above, I started from a site whose graphic vibe I appreciated, I gave it an image and instructions for it to capture the essence: the grids, the particularly bright accents in certain places, the thick and tilted underlines etc... I had to iterate, the first draft had issues but the result is rather interesting.

The big limitation is that CD can't understand animations (except to copy paste the code from the html page), yet that's one of the strengths of the original site and for now it remains a weakness of my workflow.

Another use case is to start from a design system. You can define one directly, or iterate based on the model that seems most relevant to you. Here for example, it's the Writizzy dashboard in its new style. And now each new page starts from this one which serves as a "design system" to build the next ones.

In short my workflows are as follows:

• creating a mockup with Claude Design with 3 options:
  • from a brief
  • from a screenshot
  • from a design system
• implementation in my own code via an "implement-mockup" skill that explains how to transcribe the html code produced by Claude in my technologies (nuxt-ui, tailwind)

And more recently, I'm testing:

• use of agent-browser or playwright to test the interface, especially in responsive

So don't be mistaken, I much prefer working with a designer and I would when Writizzy gets bigger. But to get started, for an indie site, it remains much better than what I could do before and the level of expectations from users has become so much greater now that anyway, it's no longer really an option to do "like before". Because yes, design gives a voice to a site, an identity. That and of course the text, on the page, the way you address readers. Without identity, a site, an application, doesn't hold your attention.

Of course it's less true on a blog post, you come to read the content, not the container, or on an admin interface of a software. But still, you don't want to be punished visually and give the impression of "meeehhh".

Now let's take a step back, is it perfect? No.

Yes, if you look at the path traveled in 15 years, it's easier to build websites. Since Bootstrap we've sought order, structure, standardization and it works.

But at what cost? We've classified components, documented margins, frozen systems. We've rationalized beauty. The problem is that by wanting to systematize everything, we've created an incredibly clean web, but terribly boring. A web without friction, but without soul. And AI, by its very nature, is the absolute queen for reproducing this kind of lukewarm consensus. If you ask it for "clean", it will give you clean.

Do I sometimes feel a little nostalgic for the ugly web of the early 2000s? Maybe.

Well, not always.... It depends! I don't know!!!

But maybe that's exactly it, if AI relieves us of the plumbing, if the technique is automated, it's an opportunity for us to put back intention, identity, emotion (I didn't think I'd write that one day). Maybe that's what the evolution of the coming years looks like, breaking the rules, and making ugly things again, but with a beautiful voice.

Building a product, an application, a website, that's good. It's already not given to everyone but it's actually the simplest part. Because yes, the difficulty comes after, when it comes to getting known.

A good product that nobody uses is about as useful as an election platform the day after the election. Everyone couldn't care less.

(I hope this joke will please the person who criticized me for talking politics in my last blog post :))

Anyway, in this post we're going to talk about online advertising.

Paid acquisition

Paid acquisition consists of spending money to try to create traffic to your site.

Inside we can categorize several things (non-exhaustive list):

• SEA (Search engine advertising) which consists of placing ads on search engines via Google Ads or Bing Ads
• SMA (Social Media advertising) for ads on social networks (Linkedin Ads, Reddit Ads, Meta Ads etc..)
• Retargeting: targeted advertising, the thing that shows you diaper ads on all the websites you visit because you had the misfortune of looking at an ad somewhere once
• Sponsoring, which consists of paying for space in a newsletter, a video, a podcast etc… Yes, it's the famous VPN ads we see on all YouTuber channels for example.

I'm starting out, I have a small budget, so SEA and SMA are the two most affordable channels for me.

So I isolated Google Ads and Reddit Ads but not everything went as planned.

Conversion tracking

Most tools like Google Ads, Reddit Ads and the like will try to optimize the display of content to the audience that is supposed to "convert" best.

Yes, because, selling diapers to teenagers for example, that's not the most effective.

You're going to pay for displaying an ad but at any given time, many people also want to display an ad so you're in competition with them on a bidding mechanism.

By default you can just say "on this keyword, I want to bid a maximum of €3" and that's it.

But for several years now, most ads platforms offer you to put tracking mechanisms on your site to determine if the conversion really happened, if the user really made a sale, or a signup. And this signal will then be used by the platform to decide whether to bid or not.

In short, before we used to say: "I'll pay a maximum of €3 for this keyword" but now we give a maximum budget over a period of time and ask the platform to spend it and figure out on its own to make it as effective as possible. Platforms will analyze thousands of signals in real time to decide whether they bid €1, €5 or nothing at all because the user is unlikely to convert.

Except that, bad luck, on Writizzy.com I don't want to put any overly intrusive tracking tools that store private information and cross it on multiple sites. This is what allows me not to put cookie banners because I'm fed up with cookie banners everywhere and also because I don't want to base my product on selling my users' data.

Now I'm not saying I don't do any tracking, simply my objective is not to send private data to a third party and to calculate the conversion myself to adjust my budgets.

::callout{type=warning} Not sending conversion information to platforms has many limitations. You have to manually cut off campaigns that aren't working and the algorithm of these platforms won't be able to adapt to the right audience. I'm well aware that in this specific case, my ethics handicap me. And I will probably look for solutions in the future to give conversion signals without sending private data. At some point you have to make a choice. ::

Conversion metrics

Here we're going to be interested in several metrics:

• raw traffic: the number of visits related to an ad campaign
• traffic conversion: are these visitors doing something useful for me
• customer acquisition cost (CAC), that is the ratio between the budget and the number of new users

For example if I spend 100 euros to get 1 customer, then my CAC is 100 euros.

It becomes interesting when CAC is less than LTV.

Ok, this sentence is cryptic.

The LTV (lifetime value) represents the value of a customer over their lifetime, basically the revenue generated by your customer.

For example, imagine a subscription at 9 euros per month. If the average duration of a user on your platform is 12 months, then the average LTV is 108 euros. In reality it's less, since you would need to subtract operating costs (the server for example) but let's simplify it like that for now.

Ideally you estimate that you should have LTV = 3 x CAC

For Writizzy.com, I only have 6 months of history so my LTV is necessarily limited to 6 months but I still have customers who took annual subscriptions.

Stripe tells me my LTV is 181 euros.

Ok, this might seem weird since I told you I only had 6 months of history and therefore not enough hindsight to have customers who spent this amount.
Stripe actually uses this formula:

$$LTV = \frac{ARPU}{Churn}$$

• ARPU (Average Revenue Per User) represents the average revenue per user per month.
• Churn is the percentage of customers who cancel each month.

So it's more of a prediction than a reality.

I still think my history will greatly evolve this value. We'll see later but overall it means that already if by spending 100 euros I can sign a customer, then I'm winning.

Reddit Ads

I preferred to start with Reddit Ads to spend my first 100 euros. I tried to use Google Ads but without success and the fact that I didn't have tracking active on my site created lots of errors for me. It's theoretically possible to do without it but Google refused to spend my money :)

Reddit, if you don't know, is a sort of mega forum where people talk about pretty much everything. It's estimated to represent between 1 and 2 billion monthly active users. It's colossal.

Reddit is organized as sub-forums, the subreddits. Each subreddit talks about a topic, for example raclette, people who photograph slices of bread attached to trees… or channels reserved for AI. Ok…

And it's possible to display ads on subreddits, so in theory to well-targeted populations, like, people who like writing blog articles and sending newsletters, which works well for me for Writizzy.

I set up two campaigns to test two approaches:

One campaign emphasizes the price difference with Substack.

The second emphasizes that we must remain masters of our data.

I'll spoil it right away, I changed the ads and actually I focused everything on price after 3 days.

Here's the graph of impressions and the amount spent per day provided by Reddit:

We note:

• that I spent exactly 100 euros, at 20 euros per day for 5 days
• that my number of impressions increased drastically on the 4th day.

Because yes, I made some big mistakes…

Campaign setup

First mistake is that I thought it wasn't working. That is, I started the campaign on June 9. I did see things happening on the 9th and then for 2 days I thought Reddit wasn't doing anything anymore.

In fact each day I would come back with the same date filter so I didn't see more than June 9 and until June 11 I thought Reddit wasn't working…

To be honest, I also thought it wasn't working because I saw barely any additional traffic arriving at my site.

And then I fixed it and traffic arrived. Here's what I changed:

• I switched from a Free form ad type to Image
• I strongly restricted the audience by removing many countries from geographic targeting

The Free form ad looks like a post and then the person has to click on the link placed in the text. Whereas the "Image" ad sends traffic directly to you when people click. Let me tell you the difference is gigantic. You can see it in the traffic, nobody came with the Free-form ad.

Audience restriction has other benefits, two for my case:

• my product uses a payment platform that doesn't allow payments from all countries, so it's pointless to target unsupported countries
• I'm subject to a lot of spam attacks from certain countries, might as well stay quiet about them…

It's not a problem to target fewer people as long as they're the ones ready to convert and pay.

So I reduced the audience to North America and Europe.

Landings and conversion

Starting from June 11, I finally had traffic and we're talking about significant visits, between 5 and 7 times more than my usual traffic. Reddit became my number 1 traffic source at that point:

But it's nice to have visits, but it still needs to be useful.

At first I was sending to the comparison page with Substack. But this page isn't adapted for conversion, it's oriented for SEO. It doesn't match the ad that was on Reddit and which talked about the price difference with Substack.
(Plus here you see the latest version of the comparison page which was worse at that time).

So I quickly made another page just to be a landing page for the Reddit campaign.

The difference between a SEO-oriented page and a landing page is that the second can have conversion-oriented messaging and must limit the number of exit points outside the signup button. Whereas the "SEO" page should on the contrary participate in the internal linking of the site and should be more neutral to hope that the indexing bots propose it in search results.

The bottom line

Over these 5 days, I spent 100 euros, 20 euros per day.

In reality only 2 days were really effective because of my startup errors.

My tracking in openpanel was a bit off and I had to improve it to better see the origin of signups. I can hardly say that the signups from the period are linked to my campaigns. But it will be more the case for the next ones.

I had 1000 unique visitors over 2 days, on a population rather interested in my product. For info, I was doing 2000 unique visitors per month before, so adding 1000 visitors is a 50% increase in traffic. If I had properly configured my campaign from the start I could have aimed for 1500 more visits.

90 people clicked on signup, 44 made it all the way through. That's still a very good number!

I have no paying conversions so far. Sure, a person can decide to convert their account in the future but for now it's not the case. So my CAC is not calculable and I'm not profitable versus my LTV.

A single paying customer would have made the campaign profitable but I can still convert free users in the future.

So will I try again? Yes certainly.

With the same budget I could have doubled or even tripled my monthly traffic if I hadn't made mistakes.

And then it's up to me to better manage my conversion on site.

I'll try to see how I could send the conversion signal to Reddit without sacrificing privacy, if it's possible. Apparently I should look at Reddit's conversion API.

And I'll try other angles for future landings.

It's definitely far from my comfort zone. But actually it's interesting to play with all these parameters and especially to see results. I'm very numbers-oriented so this game is likely to be very addictive on the contrary.

You might say it's pretty straightforward.

@Transactional   
fun doSomething() {
    ... 
    // save in database through JPA
    myRepo.save(myEntity)
    // post message
    broker.publishEvent(event)
    ...
}

But what happens if there's an error, if the SQL transaction fails? You end up with a message published but for an operation that never actually took place.

Two-phase commit transactions

This is a relatively common problem and we're used to handling it with 2 Phase commit transactions. The idea being to introduce a transaction across all operations to external systems, including RabbitMQ here.

It's a somewhat complex mechanism that requires an additional coordinator to ensure everything goes well before validating the write across all systems.

But there are several problems.

The first is that it's not possible to do 2PC transactions with RabbitMQ (also called XA transactions). Which, you'll agree, is already a relatively significant problem in itself.

We could use ActiveMQ which supports 2PC transactions. But on the other hand, it would be a shame to write an article about PostgreSQL and RabbitMQ just to conclude that you need to use ActiveMQ instead, right?

The second problem is that in any case, a 2PC transaction penalizes the overall system performance. To synchronize two or more systems, not only will the total operation time never be less than the minimal time of the slowest system, but you also add a cost related to coordination.

The last problem is that you degrade overall availability. Availability being the multiplication of the average availability of each system. For example with two systems with 99% availability, the total system achieves 98% availability.

$0.99 \times 0.99 = 0.9801$

And that was basically the state of my knowledge until yesterday. I had already used XA transactions, I had already dealt with distributed systems issues and I've worked on plenty of mitigation scenarios for this type of problem.

Yesterday I added RabbitMQ to Writizzy's stack and I used another solution: the Transactional Outbox pattern.

The transactional outbox pattern

While the underlying concept isn't necessarily new, this specific pattern was popularized by Chris Richardson between 2014 and 2016.

The concept is "simple":

• rely only on the database to publish an event (step 1)
• read the table in an asynchronous job (step 2)
• publish to the message queue from the job (step 3)

The code becomes

@Transactional   
fun doSomething() {
    ... 
    // save in database through JPA
    myRepo.save(myEntity)
    // save in database
    outboxRepo.save(event)
    ...
}

We now have only a single transaction, and the guarantee that the event is published only if the transaction succeeds. Event that will be sent to RabbitMQ later.

Now, to actually send to RabbitMQ, you need a job to read the table:

@Scheduled(fixedDelay = 500)
@SchedulerLock(name = "outbox_publisher", lockAtMostFor = "PT30S", lockAtLeastFor = "PT0S")
fun run() {
    outboxPublisherService.publishPending()
}

Note the use of SchedulerLock here which allows the use of schedulers in a multi-node context, to avoid simultaneous reading by multiple applications. This allows replacing Quartz which I frequently used until now.

And you need the publication service code

    fun publishPending() {
        val events = outboxEventRepository.findTop20ByOrderByCreatedAtAsc()
        events.forEach { event -> publishEvent(event) }
    }

    private fun publishEvent(event: OutboxEvent) {
        try {
            rabbitTemplate.invoke { t ->
                t.convertAndSend(event.exchange, event.routingKey, event.payload) { message ->
                    message.messageProperties.messageId = event.id
                    message.messageProperties.headers[HEADER_ORIGINAL_EXCHANGE] = event.exchange
                    message.messageProperties.headers[HEADER_ORIGINAL_ROUTING_KEY] = event.routingKey
                    message
                }
                t.waitForConfirmsOrDie(5_000)
            }
            outboxEventRepository.delete(event)
        } catch (e: Exception) {
            logger.error("Failed to publish outbox event ${event.id} (${event.eventType})", e)
        }
    }

Note that we've enabled RabbitMQ's publisher confirms mode and we're waiting for write confirmation: t.waitForConfirmsOrDie(5_000)

But you could say to me: "you have the problem of double write to two systems again".

And... you're not wrong.

But it's simpler here. I only have 3 cases:

• Everything goes well, nothing to say, it's perfect.
• RabbitMQ fails => we go into the exception, we log, we exit, the message stays in the table and will be retried
• The PostgreSQL transaction fails. We go into the exception but the message is already sent!!

The 3rd case is important, it will happen so you need to handle it. This implies that each consumer must be able to be idempotent on message reception. That is, each consumer must be able to accept the same event twice without incident.

Here strategies are multiple:

• read the message ID and store it somewhere to check that we don't do the operation twice, ideal for calls to external services
• trigger idempotent operations (Example: set status = pending, even if we do it twice, it doesn't pose a problem)

etc...

And error handling?

But there's an issue, if RabbitMQ goes down, if it's unreachable, if the disk is full, we're going to log the exception and with a batch running every 500ms I'll let you imagine the astronomical amount of logs that will produce. So we need a Circuit Breaker. Conveniently, we can use resilience4j.

With a circuit breaker, we'll cut off sending to Rabbit in case of error and wait a bit before retrying. I'll leave the code here but won't detail it, that would be the subject of another article.

init {
    circuitBreakerRegistry.circuitBreaker("rabbitmq-outbox").eventPublisher
        .onStateTransition { event ->
            logger.warn("RabbitMQ circuit breaker: ${event.stateTransition}")
        }
}

@CircuitBreaker(name = "rabbitmq-outbox", fallbackMethod = "skipOnOpenCircuit")
fun publishPending() {
    val events = outboxEventRepository.findTop20ByOrderByCreatedAtAsc()
    for (event in events) {
        publishEvent(event)
    }
}

private fun skipOnOpenCircuit(e: CallNotPermittedException) {
    // Circuit open — state transition already logged via eventPublisher
}

private fun publishEvent(event: OutboxEvent) {
    try {
        rabbitTemplate.invoke { t ->
            t.convertAndSend(event.exchange, event.routingKey, event.payload) { message ->
                message.messageProperties.messageId = event.id
                message.messageProperties.headers[HEADER_ORIGINAL_EXCHANGE] = event.exchange
                message.messageProperties.headers[HEADER_ORIGINAL_ROUTING_KEY] = event.routingKey
                message
            }
            t.waitForConfirmsOrDie(5_000)
        }
        outboxEventRepository.delete(event)
    } catch (e: AmqpException) {
        throw e  // broker error → propagates to circuit breaker
    } catch (e: Exception) {
        logger.error("Failed to publish outbox event ${event.id} (${event.eventType})", e)
    }
}

Challenging your own developer beliefs with AI

As I said earlier, I was well acquainted with the XA transaction mechanism and the state of my knowledge for solving this problem stopped there.

I wondered with curiosity if Claude would propose a more elegant implementation and I was rather surprised. In this specific kind of case, it was the perfect opportunity to try learning with AI instead of just suffering code we don't understand.

Letting AI write code without oversight, unsurprisingly it's rarely good. You need an expert eye and ultimately the code produced remains our responsibility and we must be able to understand it. So you need to find a middle ground between letting it do its thing and micro-managing the AI.

By giving it my constraints (stemming from my experience), it was the agent that came up with the Transactional Outbox pattern proposal. And while I was initially a bit skeptical, I tried to understand each part of the code to make it my own by asking multiple questions. The code wasn't perfect, it was following these exchanges that was added:

• the publish confirm pattern
• resilience with resilience4j
• the scheduler lock to avoid multi-node issues
• the addition of messageid in headers (for deduplication)
• claude had added a state management on messages that wasn't relevant

So yes, it wasn't a smooth plan but it was a good way for me to force myself to get updated, do some research and in short, learn new things.

Beyond the technical aspect of this post, I mainly wanted to illustrate the method I use to code with an agent, which allows me to combine productivity AND craft.

It's simple: you take a place, preferably a cool one, a group of hackers (I'll come back to this term), you let it brew for a short period and you get… something, in principle a product but we could simply talk about artifacts, prototypes, applications, physical machines, etc… But not just slides. Otherwise we'd call it a McKinsey seminar.

When I talk about hackers, be careful I'm not talking about the person who hacked your credit card last month. For lack of a more appropriate term, we'd rather talk about tinkerers. People who seek to solve problems by sometimes taking a few shortcuts.

A hacker residency is, in spirit, a direct descendant of hackerspaces, shared community spaces that emerged in the 1980s/90s. In essence, there are already Hackers who move from one place to another to share, test and experiment. For Hackers residencies, the concept is strengthened with a principle: what if we invited a hacker from another country, gave him an access badge, a couch to sleep on and let him code, hack hardware or volunteer to give workshops for a month? The concept of Hacker-in-Residence was born.

And even if the lineage isn't direct, we find a historical kinship with the artist-in-residence model. The principle remains the same: invite artists, provide them with a place to express themselves, often with other artists. In short, the same fight—to create places, sometimes temporary, dedicated to creation.

Anyway, I'm in Nantes for the week with 13 other people to discuss, build things, test, and incidentally, have fun!

::gallery ::

Just yesterday, it was Github, which apparently opened part of its code as open source. Unintentionally, of course, but we can still appreciate the gesture.

Meanwhile, in France, it's 3 data thefts per day on average according to this article. But don't worry, apparently our prime minister has a solution: fire the director of the national cybersecurity agency (ANSSI)…

That said, the massive breach of France's secure identity document agency (ANTS) by a 15-year-old hacker via a trivial vulnerability was kind of the straw that broke the camel's back.

And according to some, AI would be responsible for the general decline in software quality, for example at GitHub where uptime would be in constant decline since GPT3 on this chart (and the arrival of Microslop but let's focus on just one culprit).

Okay, that's trolling. But some people wonder seriously: is AI really the source of all these problems?

That's what we're going to try to see. We're going to talk about the real reasons for the CVE surge but it will mostly be a pretext to wonder if we're really at the dawn of an era of AI-generated shitty code.

The Rise in CVEs

First, why am I talking about CVEs, and what is a CVE anyway?

A CVE (Common Vulnerabilities and Exposures) is a standard that catalogs all known vulnerabilities in a large database. Each CVE is listed under a super sexy little name, like CVE-2024-12345.

(Yes, it's quite thrilling, isn't it?)

So you're going to tell me, in the software world we talk about bugs, not CVEs, and you'd be quite right. But there's no catalog of bugs for all known software.

So here I'm taking the number of annual CVEs as a kind of indicator of the number of bugs in software because I think there's a small correlation between a decline in quality and an increase in security holes. At first glance anyway, but we'll come back to that.

And if we look at it, well the acceleration could date from 2022 with however a first step around 2017.

If we take 2017 as the turning point, it becomes hard to blame AI for the problem even with the bad faith of a a Marseille football fan (hey Max, if you're reading this, you know how you guys love to exaggerate).

Broadly speaking, the CVE increase since 2017 is probably explained by a mix of factors:

• greater pressure on software which is now expected to have a new version every day
• a general explosion of digital technology
• many more security programs (bug bounties)
• an increase in the number of software dedicated to cybersecurity.
• major geopolitical conflicts and more frequent cyber attacks

Actually, it's not unlikely that we're measuring the number of thermometers (and not just the temperature), so the rise of the cyber industry, and on the other hand, the rise of digital technology which is becoming an economic and geopolitical stake in a rather unstable context for years.

Now we can still question the post-2022 period because the slope seems to be climbing as fast as Trump's court cases.

However, I'd say that CVEs aren't the best proxy for measuring software quality because as we've seen, CVEs can increase for rather exogenous reasons. It's not because we're controlling things better than before and scrutinizing more that there are really more bugs.

So we're going to go back to the starting point and look at a sentence I hear very often: AI is the death of craft.

With AI, It's the Death of Craft

Craft, for those not following along, is kind of an umbrella term to group together a whole set of practices aimed at producing "quality" software. Assuming we can define what quality software is, but that's another subject.

With AI we wouldn't be crafting anymore and technical expertise, the appeal of the profession for many, would have disappeared.

Wait, here we have two different subjects:

• the appeal of the profession would disappear because we wouldn't be crafting anymore
• the code produced by AI would be to computing what English cuisine is to world gastronomy, i.e., not great.

(Well, let's set the record straight on the second point: no, English cuisine is vastly worse)

So some people have tried to determine whether code produced by AI was necessarily less "sustainable" than code produced by a human, in short, whether we were really building mountains of technical debt at light speed.

AI Slop and Software Maintenance

Do you know Dave Farley?

Dave Farley is notably one of the authors of the book Continuous Delivery released in 2010.

It was one of my reference professional books for years at a time when there was a lot of talk about software factories, quality, and continuous deployment. I worked for years on these subjects, particularly from 2006 on distributed CI concepts. I then worked from 2010 on industrialization themes, then from 2012 on continuous deployment.

(okay grandpa but continue your story)

Well Dave Farley participated in a study that aimed precisely to determine which code was more maintainable between code produced by AI or code produced by humans. Was there more technical debt in AI-produced code? And the answer is… no.

To be frank, even I'm surprised, and yet not at all.

I'm surprised because I know the engineering effort required for AI to work well. Without that effort, the code quickly looks like a slightly lopsided Frankenstein.

But, I imagine the study is about professionals who had time to set up their usual tools.

Building an Agentic Software Factory

I told you, I love building software factories, I've been working on this subject for years.

A software factory is nothing more than a manufacturing process, more or less industrialized and automated.

A code generator, however powerful, is not a software factory, it's just one of the factory's machines.

And if you just let one machine run, it's not enough.

When a dev only does copy-paste from ChatGPT from a browser, it's barely 10% of the work and yes, the result isn't great and often requires a lot of manual adjustments.

Now, being a bit provocative, I'd say that tweaking the generated code is a failure. Imagine the same thing in a car factory. If artisans had to retouch every car produced, it would be a bit surprising. And, I'm no specialist, but I don't think that's how it works.

Anyway, you need the other tools.

In our profession, this consists of building test and validation harnesses, defining rules to follow and finding ways to verify they're being followed, creating skills to guide AI agents' work and prevent them from crashing, allowing them to verify themselves with tools and therefore correct themselves, etc…

And that, actually, is craft. Using AI agents makes those famous best practices mandatory that everyone talks about but you don't see so often in practice.

All the people I see right now in the DevWithAI community are craftspeople trying to improve their software factory. They're people working on token compression tools like rtk, tools to simplify and standardize usage at team scale like packmind, usage guides like Florian's.

Craft hasn't disappeared. It has changed.

For a company, there's substantial effort required to introduce these tools, build a software factory on top, create tooling, do platform engineering, and you need people for that, the same way you need people to design, maintain, and evolve production chains in factories.

Briefly, no, the appeal of the profession hasn't disappeared in my view, for people who love craft and technical work.

And if we talk about quality, I'm going to surprise you but, at my scale, I see significant quality leaps in my applications.

The Writizzy Example

I develop several products, Hakanai and Writizzy. I recently put Bloggrify in maintenance mode.

Bloggrify started in 2022, Hakanai in 2023 and Writizzy in 2025.

For the first two, I barely used AI at first then gradually introduced some copy-paste from very discreet use of inline agents. So more than 90% of the code was produced by hand.

Well today I'd say that it shows.

Wait, I'm proud of what I did with Hakanai and Bloggrify. But to build an application solo you have to be very good at everything: building the application, its logic, its ergonomics, its UI, its robustness. But that's not my case. So sometimes there are places where it's a bit less good and it shows.

And beyond that, doing everything very well takes time. When building a product, you always have to choose between "perfect" and "good enough for most uses". The difference between the two being the time available.

Sometimes you give up, you know it's not perfect, but you've just spent 1 week on it, and frankly for a 5% quality improvement, forget it, we're not spending another week on it. That will be for next time. That famous next time that never comes.

Actually the quality of Hakanai and Bloggrify was variable. There were shortcuts taken, pages with ergonomics straight out of the 2000s web, and it doesn't matter, that's how we used to build products.

With Writizzy, that's completely different. I don't take shortcuts. First and foremost because to produce correct code with AI, you need a proper software factory, and that includes safeguards like tests, linters, etc… So it's non-negotiable, whereas ultimately it was negotiable before for Hakanai and Bloggrify.

Plus, the cost of refactoring has become almost zero. The small thing missing for a feature to be perfect, now I can do it.

Actually today I can take the time to handle edge cases, those famous little exceptions that before you'd leave aside because "that never happens". I can use the time saved on dev to think more about security, robustness, scalability.

Producing code has become a commodity. So I take advantage of it to produce very good code.

Briefly, I'm still crafting, but its nature has changed.

And what I produce is better quality. So I'm not convinced we've entered an era of shitty code.

Now there's still a nuance to add. AI drastically lowers the barrier to entry. That's good, but it means we end up with a flood of stillborn software, things that won't survive longer than a shitcoin promoted by a Dubai influencer, and companies that are going to cut hard on R&D costs because… laziness, and what if we increased margins. So yes, under those conditions, we're going to have an increase in the number of poorly produced software, software that will die after 3 months because their creators will get bored very quickly faced with the reality of actually managing an IT product. But good products will on the other hand be much better because craft will be a sine qua non condition for not crashing in a world where everything will move much faster.

I'm currently developing two projects: Hakanai (for static blogs) and Writizzy, which just passed 550 users in 6 months. But combined, I don't make more than 250 euros a month and my principle is not to spend more than what I earn.

So I have a big constraint: budget. I try to build my applications without burning tokens at the speed of light. And I wanted to share with you how I do it.

What is Writizzy?

Quick reminder to set the context: Writizzy is an equivalent to Medium or Substack. A platform to write, send newsletters and monetize your content. I think it's vital to have spaces for expression outside the GAFAM (and outside the US). It's the software that runs the blog you're reading.

Code-wise, we have three big pieces:

• An API in Kotlin.
• An Admin App in Nuxt.
• A "blog" App (that serves the content) in Nuxt as well.

To work, I mostly use Claude. Why? Because it remains the best-rated model on the code benchmarks.

But I'm thinking about an alternative. I'll tell you more about it at the end.

Context Engineering: Constraining the AI

The idea to work effectively is to give the LLM the necessary and sufficient context to limit its solution space. We want to give it guidelines and ways to verify itself that it stays within the lines. If you don't do that, don't be surprised when the AI hallucinates APIs or uses old doc versions. It's normal.

The Claude.md file

It's the entry point. You'll find the project objective, the general structure to prevent the AI from browsing through all the code randomly, and especially the list of specs.

This list is fundamental in my development process, I'll come back to it later. It also serves as an index for Claude.

Note that I have other claude.md files in subdirectories, these files are loaded by Claude if it enters them. I have one per application (app, blog, and api). I use it to list available technologies but I tend to use rules more and more.

The Rules (.claude/rules)

These are rules that can be loaded conditionally. For example here, if Claude enters the /app directory, it loads the Nuxt rules.

In this rules file I define the patterns I want to see used, for example: obligation to use Nuxt UI, to run a typecheck or eslint pass before finishing, etc.

These rules, I built them empirically. That is, the file was empty originally, then I added rules based on the errors I saw coming back. More recently I'm trying to limit Claude's exploration so I systematically ask him if he saw patterns he should document in the rules to avoid spending tons of tokens exploring. Plus I don't really like him guessing based on the code he encounters.

Example of a question I recently asked him:

I'm looking to improve the rules I've already put in place. I find that you had to read a lot of files to understand the context and patterns. Why? Give me a summary of the patterns you were looking to understand to see if we can make them into rules

Actually, building these rules files is a kind of safety harness. But you also need to understand that it's not a guarantee because LLMs will regularly ignore rules. So you need to strengthen control means: tests, linter, CI quality gates, etc…

I note that it's easier for those used to developing with good practices to work correctly with AI. These practices serve as safeguards but for many companies, it was a bit of window dressing but not very effective in practice. And precisely, in companies where these methods aren't mature, AI doesn't take off. One wonders why... Or not…

The "Analyst" command

A command is a sort of pre-prompt. I use an analyst command for brainstorming. I ask him to be a specialist in blogging, IndieWeb and decentralization. I ask him to challenge my needs, detect inconsistencies and most importantly to write the specs.

Specs before code

Earlier I talked about specs that are listed in the claude.md file.

Let's talk a bit about my dev cycle.. I systematically go through a spec before any significant piece of code. (Funny when I think back to when I launched Malt, there wasn't much written at first…)

With AI, the spec has two major interests:

1. Frame the expected result. We first define the direction, user flows, etc.
2. Save tokens in the future: By listing the technical entry points and key files in the spec, Claude doesn't need to search everywhere.

Indeed, when Claude reworks a feature that already exists, he'll use the spec file to understand how it works and especially easily get back to the key files. With these specs, he'll save a lot of time on that, and especially it will be more accurate than letting him guess.

Once the spec is validated, I create an implementation plan (well, Claude creates a plan). For that, I have a skill that imposes my practices: each step must be deployable, it must use feature flags if necessary, etc...

The art of managing your context window

Here I need to come back to the notion of context window because it's important for optimizing your monthly budget. What costs a lot is endless sessions. With each exchange, you send back the entire history. After a while, a simple "Ok" can cost tens of thousands of tokens. So already, that costs a lot.

But the second cool side effect, the fuller the window, the "dumber" the AI becomes. So I try never to exceed 50% capacity. That's the whole point of implementation plans. The idea is to break it down into small autonomous tasks and change sessions regularly.

Skills vs MCP: The efficiency battle

I mentioned skills before. I use them heavily to be more efficient. And there's a real parallel between efficiency and cost so I need to talk about it here.

A Skill is a competency loaded on demand. For example, my Nuxt skill forces Claude to go read the doc online (in Markdown format) rather than relying on his outdated training data.

I have skills for different things:

• APIs that specify my design patterns: api-design, db-migration, write-spec

It's sometimes a bit more than "just" specifying patterns, for example the db-migration skill lists exactly which tools to use (Flyway), the location of migration files, the file format. And on the pattern side we find my key principles of deployment strategy (rolling update, etc…)

• bento, nuxt, nuxt-content, nuxt-ui to specify how to fetch the doc
• skills that explain how to use a CLI, for example sentry-fix-issues which explains how to use the sentry CLI to get information, diagnose, and fix

On the other hand, we have MCP (Model Context Protocol). It's powerful too, but it takes up more space in the context because each method of the MCP is included in the context window. Where a skill, it's only the skill description that's included.

So I prefer Skills, except for:

• MCP IntelliJ: To properly navigate code and compile.
• MCP Stripe: To debug configuration.
• Claude-mem: supposed to remember key decisions between sessions (I'm still testing, the gain isn't clear yet).

What about design?

Recently, I switched to Claude Design. It became my tool of choice. I brief, I comment on areas, I modify on the fly, and once the HTML is clean, I give it to my Claude agent for implementation. It's well above what I was doing before in simple prompting. The results are really stunning.

Balance sheet: How to stick to the budget?

In short, with all that I manage to get by for 20€ a month but I still have a few extra tricks:

• Token compression: I use compression strategies (like rtk) or I create my own tools to only send LLMs what's necessary.
• Online AIs: If I want to brainstorm "for free", I go to Gemini. I'm generally less of a fan but it can serve as a relay before going to really work with the analyst for example.

But mostly, I have an incredible trick… I close my work session when Claude tells me I've exceeded my quota. Plain and simple.

When it's done, I stop. I go do woodworking, cooking, I write an article (that's exactly what I'm doing right now ^^).

It seems like nothing but this discipline is actually healthy. I don't see it only as a constraint but also as an opportunity to do something else, think, consolidate what I've learned, etc… It joins what I wrote in a recent article, it's good to save time, but you have to know how to make the most of it.

Next step: I'm testing local models. The idea is to delegate small implementation tasks to my machine and keep Claude only for strategic planning. It's really just the beginning so I'll talk about it more later.

I'm far from being as advanced as possible on these topics and especially I'm in a solo context. But if you have your own tips to share, don't hesitate in the comments, they'll be read carefully.

Anyway, it’s been 181 days since I launched Writizzy. It’s the blogging platform I’m using for this very article. I’m the first one convinced by my own product, which is already a small victory :)

With a bit of exaggeration, I could tell you that in 181 days, Writizzy has managed to reach the same level as Substack, Medium, or Beehiiv in terms of features.

Obviously, on the usage side, we're not quite there yet. About 480 users have tested it, with around 130 of them being truly active.

And above all, it's far from being a smooth ride. I have a huge thorn in my side: very few people are discovering the product. Even worse, my traffic is decreasing.

With 1,850 unique visitors in April, it’s my second worst month since the beginning. And one of the reasons (though not the only one) is SEO.

SEO is Failing

"SEO is Failing", that sounds like it could be the title of a gritty Liam Neeson thriller.

With 1,850 unique monthly visitors, I’m getting almost 3 times less traffic than my own personal blog (the one you’re reading right now). That’s… room for improvement :)

Most of the traffic comes from social media, Reddit, Facebook (?? I don't know why), Uneed (a product launch platform), and various blogs already using Writizzy.

There is some traffic coming from Google, but it’s what we call "Brand" traffic. These are people typing "Writizzy," so they already know the product. In that case, you can't really call it new user acquisition.

So, a few weeks ago, I wanted to self-audit to see if I could find what was wrong. To do that, I found a set of skills for Claude: claude-seo.

Claude-SEO consists of about twenty skills that test several areas: content quality, JSON-LD markup, GeoSearch (AI search optimization), technical SEO, etc.

There are 21 of them, so I won't list them all, you'll have to excuse me...

Once installed, I ran the command /seo audit [https://writizzy.com](https://writizzy.com) and here is the first result:

47/100 isn't great, but at the same time, it’s actually good news. It means there’s work to be done and the tool will be able to help me.

Insights from the First Run

Claude-SEO tests many things, especially technical SEO.

In theory, this is the easiest part since it involves structural optimizations, titles, performance, JSON schemas, etc.

I received some very relevant advice, particularly regarding home page image optimization and pre-connection directives for my Bunny CDN.

HTML

<link rel="preload" as="image" href="/herobg.webp" fetchpriority="high">
<link rel="preconnect" href="https://writizzy.b-cdn.net">

I also got a lot of feedback on the JSON-LD schemas used on the page.

::callout{type=info} About JSON-LD: You have to understand that a bot indexing a site doesn’t read it like we do. We can help it better understand what the site is about by giving it structured data in JSON-LD format. It’s invisible to the human reader but very practical for the crawler. ::

You can see the entire JSON-LD structure of the home page that I modified thanks to this site (which I invite you to use for yourself): validator.schema.org

Claude-SEO also allowed me to realize there was a bug in the nuxt-seo library I use, which was impacting all the titles and meta descriptions of my site. Every page had the same attributes!

(By the way, Claude also helped me diagnose the bug to open an issue, which has since been fixed).

But most importantly, Claude-SEO suggested several relevant additions:

• Adding an llms.txt file to improve my ranking for AI assistants.
• Adding dedicated pages for the founding team, pricing, and specific features.

Usually, we tend to create landing pages that group all this information together, but apparently, it can be beneficial to have separate pages to answer specific search intents, like "Writizzy pricing."

As for the "About" page, it's about reinforcing the site's authority based on E-E-A-T criteria (Experience, Expertise, Authoritativeness, and Trustworthiness), criteria Google uses to assess the trust they can place in a site.

Once all that was in place, I ran a second test and got a 64/100.

An Instructive Second Run and a Few Bugs

Claude-SEO is not a deterministic tool. In other words, new relevant problems can appear that weren't noted in the first run.

Second issue: sometimes page crawling fails. For example, during this second run, the llms.txt file was still considered missing even though it was there. Same for the blog, which wasn't detected.

However, there was still clear progress between the two executions, and some new problems were totally valid:

No security headers were present. It’s not crucial for SEO, but it’s still a bad signal. I installed nuxt-security, which resolved this very quickly.

More annoying: http://writizzy.com was returning a 200 and https://www.writizzy.com was sending an SSL error because the only valid URL is https://writizzy.com. That’s normal, but bad for crawling. HTTP must redirect to HTTPS, and "www" as well if you don't want to manage it. This was all handled directly at the Bunny and Coolify levels.

• Claude-SEO suggested several additions for Cache-Control directives and even gave me the configuration for Nuxt since it knew I was using it.

I'll skip other minor or less interesting detections, which brings us to the 3rd execution: 71/100.

This 3rd run mainly detected implementation errors on what had already been done, encoding errors in JSON-LD, logos with formats not accepted for Open Graph, and a few suggestions for additional pages.

The Verdict?

This Claude plugin was super interesting. I learned things (like E-E-A-T or certain JSON-LD entities I didn't know), it highlighted problems I could have seen myself (like security headers, lack of HTTP to HTTPS redirects), and it allowed me to better configure my Nuxt framework.

I highly recommend testing it on your own site.

Now, did it work? Has my SEO become the best in the world?

Well, not really. For a reason I can't explain, Google refuses to index the pages of my site except for the Home page. If you look on Google with site:writizzy.com, only the home page shows up. And this is confirmed in the Google Search Console, which lists all other pages as "Discovered - Currently Not Indexed."

And there, it’s a mystery.

Especially since I have the exact same problem on hakanai.io (another product I'm building), only the home page is indexed once again.

At this stage, I’m a bit lost. I think I’ve truly improved the SEO from a technical standpoint, but I must be missing a massive issue that I don’t understand.

For some unknown reason, my site is considered untrustworthy or lacking interest, even though I have a Domain Rating of 47 and 3,000 backlinks.

In short, SEO isn't just about tech, and for now, I don't have all the keys yet :)

If you have SEO knowledge and ideas, feel free to share, I’m all ears.

Next steps: I’m going to go through every page one by one. If Google deems my content "uninteresting," I need to understand why.

In the meantime, if you want to help me send positive signals to Google (or just test a pretty cool blogging tool), don't hesitate to start your blog on Writizzy with a little backlink, it’s a boost that could really help me ^^

Here’s the setup: You manage a country. Actually, let’s increase the difficulty: You manage a federal state made up of several countries.

This state is losing money every year because it buys more from neighboring countries than it sells to them.

This drain has several consequences: your companies sell less, so they under-invest. Your citizens have fewer jobs and lower wages.

You depend on imported products. The states selling them take advantage of this to impose their own conditions for continued business.

As you’ve probably guessed, this game already exists. It’s called Europe, and the products I’m talking about are essentially digital services.

And apparently, a solution is currently being studied to counterbalance this slow digital colonization: Open Source.

Okay, let’s explore this path and try to understand where it might lead us.

264 Billion Euros and 1 Million Jobs

264 billion euros and 1 million jobs, that’s what Europe lets slip away every year to major American Tech companies (Cloud, AI, etc.).

This figure hides massive blind spots. Digital technology means direct AND indirect jobs, risks of espionage, and proven cases of public opinion manipulation.

It’s also a constant weight on our diplomatic relations, because it’s hard to resist our digital dealer when they impose conditions, for instance, demanding we abandon inclusion policies within our own companies.

In this context, Europe wants to rely on the European Open Digital Ecosystem.

So, is Open Source the solution?

Open Source and Geopolitics?

If money has no smell, does Open Source? Not necessarily.

An open license tells us nothing about a project's governance, meaning, who decides and who captures the revenue.

A huge number of major open-source projects are simply funded by large American corporations (e.g., Kubernetes, React, VS Code). GitLab, for instance, sees a vast majority of its contributions coming from salaried engineers.

Another part of these projects is managed by foundations that may also be based in the US (Apache, Linux, Mozilla).

In the event of a conflict, even if Open Source is "open," Europe could find itself penalized.

We could be excluded from major distribution platforms, like GitHub, which has restricted usage in Iran in the past.

A project could unilaterally decide to stop supporting local standards or legislation (such as privacy regulations).

A state could influence contributors to insert backdoors.

But it’s open source, you might say. We could just create our own fork and maintain it in Europe, right?

It’s not that simple.

That would imply finding, mobilizing, and funding armies of contributors in Europe. Contributors who would spend a portion of their time "just" catching up with the original code and verifying that no backdoors were introduced to target us.

In short, it requires resources and people willing to maintain projects built elsewhere.

Then there’s the concept of the ecosystem. Take Huawei, for example: they forked Android but couldn't access the Play Store or Google Play Services, which severely limited its appeal.

You might argue that we also have foundations in Europe. Eclipse moved to Europe in 2020, making it the largest European open-source foundation.

True, but a foundation lives off membership fees, and the main contributors to Eclipse are American (IBM, Oracle, Microsoft, Intel, Amazon, Google). Not to mention that the Eclipse Foundation isn't the most advanced on current topics like AI or Cloud.

A Structural Fragility in Open Source

This isn't just a hunch; it all circles back to the question of resources.

Until now, we’ve mostly discussed massive projects, but the vast majority of projects rest on fragile foundations.

Open source is underfunded. Countless projects are simply too small to be visible, even though they likely power 99% of modern digital software (source: myself, but I doubt I'm far off).

Between maintainer burnout and the lack of resources to keep up with current demands, it’s easy to connect this fragility to cyber risks. Log4Shell, Heartbleed, and XZ are perfect examples of vulnerabilities and cyberattacks targeting open source.

Relying on such fragile actors without funding them is hypocrisy.

But this conclusion is widely shared, and Europe is planning to put money on the table to fund open source as an alternative to major US software.

We’re talking about funding programs in the billions of euros and policies favoring open-source solutions.

Digital Commons

Of course, we return to the problem mentioned earlier: open source does not mean neutrality. Therefore, Europe is setting criteria and, above all, defining the concept of a Digital Common:

A digital common is not just software (code); it is a triad of inseparable elements:

• A digital resource: Software, a database, a technical standard.
• A community: Developers, contributors, companies, and users who maintain the resource.
• Governance: A set of rules defining who can contribute, how decisions are made, and how to prevent the resource from being captured by a single actor ("vendor lock-in").

An open-source project "dictated" by a single American multinational is not a digital common, because the community has no real decision-making power.

And "digital commons" created in Europe do exist: OpenStreetMap, VLC, and even Linux and the Web.

Toward a Fragmented Open Source?

The primary fear in a digital cold war is seeing a fragmentation of open source: license wars, targeted exclusion of contributors by country, and a decline in international collaboration. It’s already becoming difficult to get visas for international events, and refusing certain foreign travel is becoming both a political and ecological act.

While this outlook is somewhat grim, it is relatively inevitable. In a closing world, open source will not live in an isolated bubble. And this will force us to create our own digital identity.

A European Digital Identity

It’s true: open source alone is not the solution because it is a fragile, underfunded, and inherently non-neutral ecosystem.

A large portion of US Open Source is funded by big US companies, often serving as a digital Trojan horse to capture revenue.

But how many companies in the US actually run on "Free Software"?

Relatively few.

This is less true in Europe. The International Criminal Court (ICC) runs on OpenDesk. Several French administrations have just announced their migration to "La suite numérique".

We could see a European digital identity taking shape, based on standards like interoperability (open formats), reversibility (the ability to easily retrieve one’s data), and the digital commons I mentioned earlier.

We could see industrial consortiums joining forces to create digital standards, such as Eclipse SDV (for Software Defined Vehicles).

We could imagine conditions in public tenders that de facto eliminate US products—for example, an extraterritorial immunity clause to protect us by default against laws like the Cloud Act.

Finally, we can imagine Europe becoming a hub for digital ethics, attracting global talent who want to contribute to projects serving the general interest rather than the stock price of a giant.

In short, open source is not a magic wand for Europe to stop being a digital colony. We will have to go further. This will require courageous public procurement, massive funding of digital commons, and strict legal protection against extraterritorial laws. European digital identity will not be a gift from Tech giants, but an infrastructure we must build ourselves.

And while this figure alone doesn't mean much, know this: it represents roughly 10 times the annual volume of pre-COVID layoffs.

So, can we really say that humans are being progressively replaced by AI as so many claim?

In France, INSEE speaks of a contraction in the job market directly linked to the rise of AI.

But correlation doesn't imply causation, so we're entitled to wonder if there's something else hiding behind all the hype.

So I wanted to dig deeper and explore the root causes to understand this wave. And it turns out AI might not be our biggest concern.

Large waves of departures blamed on AI

If you read the latest news, there's plenty to worry about:

• Oracle just laid off 30,000 people (20% of its workforce)
• Block cut 40% of its headcount

And I could've cited Meta, Amazon, Klarna, ASML, Ericsson, Salesforce—the list goes on.

In most cases, AI is cited as one of the reasons. And this narrative has a major advantage because on paper, these companies say: we're automating, we're gaining productivity, and we're cutting fixed costs. Which tends to reassure shareholders.

Block's stock price, for example, recovered a bit in February following the announcements.

Same with Oracle's stock price (announcement made March 30th).

Now doubts linger, and as one article put it: "Isn't this just layoffs with better marketing—AI washing?"

Block is really compensating for past management mistakes

Block is the new name for Square, a payments company you might know from its little payment terminal that's now fairly ubiquitous:

But Block isn't just a payment terminal—it's also companies in crypto because its founder, Jack Dorsey, is a big believer in cryptocurrencies.

Jack Dorsey is also the former founder of Twitter, which he sold to Elon Musk a few years ago.

And Jack tends to think big. Twitter had 8,000 employees when he sold it—a company that now runs with 2,800 people.

At Block, the company tripled its headcount post-COVID. We're talking about a 12,000-employee company that had just 4,000 pre-2020.

Sure, you can understand it by looking at the COVID effect on Block's stock.

Except the return to reality in 2022 hit hard. The company stagnated, and with an explosion in the payroll, things couldn't end well.

So we started seeing performance improvement plans emerge.

Because if you look at the economic fundamentals, as this article does, you realize that Block is far less profitable than its competitors, with gross margins that are half theirs.

Today, AI is mostly a "pretty" way to hide management mistakes and reassure investors.

Oracle isn't cutting jobs for productivity gains

Oracle's case is a bit different. Officially, it's not about cuts driven by productivity gains, but a reorientation of investments toward infrastructure to support AI.

In their case too, the stock price is rather concerning, but it's not the main driver of changes.

As one article puts it, it's primarily about investment:

The job cuts at Oracle come as it has invested heavily in AI, spending both on its own infrastructure and on partnerships with other companies like OpenAI. It plans to spend at least $50bn on infrastructure this year, and it has also raised $50bn in debt in order to "meet demand" for even more AI infrastructure. Oracle is also part of the Stargate initiative, alongside OpenAI, SoftBank and MGX, an AI investment fund backed by US President Donald Trump.

Here, it's really about reorienting capital from a traditional activity that's flagging to one that's supposed to replace it in a few years.

In reality, I won't criticize it. It's a strategy, a bet. A huge bet, but one that falls into the same category as what Kodak should've done when digital arrived. And Oracle doesn't want to be the next Kodak.

The market is anticipating unrealized gains

And that's really the issue—nobody wants to be the next Kodak.

When a leader (like Block, Google, or Meta) lays off 10% of its workforce and its stock goes up the next day, every other company is tempted to do the same.

Laying people off because you mismanaged your company would be an admission of failure. But laying people off because you're "transforming through AI" is a vision of the future.

And this FOMO—fear of missing out—explains a lot of the current departure plans. Gartner calls it "RIFs before reality", the anticipation of unrealized gains:

The employment deal is being rewritten in real time. CEOs are making bold moves based on AI's promise rather than its proven impact. Layoffs linked to AI dominated headlines last year, but Gartner data shows fewer than 1% were due to actual productivity gains.

This anticipation drives investment reorientations. Oracle's case is representative here. Not everyone is investing in infrastructure, but many are reinvesting in engineering to automate other business functions and, most importantly, to be ready for the future.

AI is no longer just a growth story; it's a cost-reduction tool, and firms are restructuring accordingly. What we're witnessing is a shift from headcount-driven expansion to automation-led productivity, a transition that will define the tech sector in the coming years. —Alan Cohen, analyst at RationalFX

Now, this isn't new, and I notice a certain hypocrisy among some developers who are discovering today that their profession has always been about automating others' jobs. It's a shame to discover it when it touches us personally.

Anyway, what's certain is that companies are anticipating cuts without yet having proof of the gains to come. It's not just a few layoffs—we're seeing signs, notably raised by levels.fyi's founder: we're witnessing a simplification of career paths.

A layoff plan is temporary. But when you start eliminating rungs in career ladders, it signals you're anticipating a durable, global reduction in headcount.

And yet, once again, the gains aren't that obvious so far.

Productivity gains aren't widely demonstrated yet

We all have our opinion on this.

I consider myself more productive with AI. But not everyone agrees.

But in any case, these are just opinions.

There are studies on the topic of productivity, but there's no consensus.

You can find studies showing we're less productive, but you can also find others saying the opposite.

The causes are multiple. The first is what's called the productivity paradox:

You can see the computer age everywhere but in the productivity statistics

Yes, back then we wondered if computers really made us more productive. It was far from certain.

This paradox is explained two ways.

First, companies spend more time configuring tools, training people, and reorganizing workflows than actually producing more.

Second, a new technology requires a learning period that can be quite long to master. And that's what we're seeing today—AI usage is totally new. Many are just faster at doing what they did badly before.

And it's not like we know how to measure developer productivity anyway. I'll remind you that this question still hasn't found a universal answer since we started asking it.

Now, I've also heard plenty of CTOs and IT directors privately say they have the means to prove it. But they don't want to. Because proving it would mean making decisions they don't want to make.

And I can tell you that in this period, I'm glad I'm no longer a CTO.

Deeper economic reasons

Still, as we've seen, productivity gains or not, can we really say all current layoffs are AI-related? Probably not.

A recently cited study shows that 59% of HR leaders admit that AI was used as a "cover" to justify budget cuts that were actually driven by:

• Over-hiring post-COVID
• Investor pressure to increase margins
• Internal strategy mistakes

But I think that would be overly reductive.

It's mostly the nth demonstration that we've entered a new era post-COVID. Between rising inflation, ongoing trade wars, endless debates about tariffs, skyrocketing energy costs, various conflicts that paralyze parts of international commerce—we're really in a recession.

AI is a facade to hide the rest. When Trump gets excited about his Stargate project (building datacenters), it's storytelling to hide the mess, even if it's true that AI is probably one of the drivers of the military sector in coming years and the US losing ground on it is probably making them nervous.

Yes, because the worst part is that even on AI, it's not certain the people leading the dance will be American.

Recent Chinese models like Ernie, DeepSeek, Qwen, and Kimi are largely on par with Gemini or ChatGPT, without necessarily costing the same. Kimi and DeepSeek reportedly cost 10% of their American counterparts during training phases.

Which, incidentally, is encouraging but mostly logical—technology improves, and we've never seen tech stay this inefficient over time. The computer that sent a rocket to the moon was less powerful than our smartphone despite consuming far more energy.

And for all these reasons, US companies are in full downsizing mode. Players in AI need to become more competitive. They're investing heavily while cutting payroll at the same time.

Other tech companies are following suit, further constrained by hyper-unfavorable economic conditions and in a context where saying you're laying off to increase productivity is more sellable than admitting reality.

A new era?

And us in the middle of all this? Well...

I'll be honest—I really wondered how to conclude this piece. I always try to end on a positive note, but the exercise is difficult here. I'll try anyway.

Is this the end of an era? Probably the era of unreasonable hyper-growth, which isn't so bad. This forced downsizing might help us get back to basics instead of just chasing vanity metrics (like headcount).

It's also a global economic shift and a US bloc that seems to be faltering. I want to see some positivity in thinking that Europe has cards to play. We're less affected than the US by the recent massive waves of layoffs. Probably because we have less insane payrolls than the US and more solid social models.

While American giants painfully refocus, it's our moment in Europe to catch up. These new technologies, more accessible and efficient, let us move faster with fewer resources. Maybe it's finally time to create real European tech alternatives—more sober and pragmatic.

On that note, you can go back to normal activities.

It got me thinking. I have an answer from my own experience, which I'll share with you. But I'm well aware my situation is peculiar. So I decided to dig deeper, and I realized something: the real question isn't whether you're getting faster. It's: what does that actually change for you?

Do you work less? More? Differently?

What's the impact in a large corporation? What about freelancers?

Essentially: ++if++ someone gains time, what's it actually worth to them?

Is That Time Gain Even Real?

First, let me be thorough and put things in perspective. A recent study from METR (Model Evaluation & Threat Research) shows that this time gain might not be as straightforward as we think.

The study found that experienced developers working on legacy codebases were actually 20% slower with AI, largely due to code review cycles.

Take it with a grain of salt—the sample size was only 16 people. And context matters: we're talking about expert developers working on large, complex codebases.

I won't dwell on this study because I can find others saying the opposite. But I thought it was intellectually honest to mention it, to balance the narrative and add some perspective.

The point isn't to assume that AI definitely makes us faster. I don't want to get into that debate. Instead, let's strip away the AI label entirely and just consider a hypothesis:

What if someone could produce code 20-30% faster? Or even 10x faster? What happens then? If software production becomes cheaper, what's the impact on the developer profession? What can you actually do with that gained time?

This isn't a silly hypothesis. The profession has changed radically since the days of physically wiring computers to program them. We've constantly improved productivity. And our successors probably won't work the way we do.

An Opportunity for Product Builders

I'm an outlier, so my answer doesn't apply to most people.

I work with one co-founder on a recently launched product. I have no productivity quotas, no salary pressure, no one to report to.

I control my own time. If I finish a task in an hour instead of a week, I can just stop working and do something else. I'm not obligated to pad my hours or hit some end-of-day checkpoint.

Of course, I still have pressure—the product needs to be good and adopted. I track new users monthly, revenue growth, and customer feedback via email. But for my situation, extra time is genuinely useful.

I can spend more time responding to emails thoughtfully. I can do deeper analysis of my market and user feedback.

In short, I see it as an opportunity.

Before, as a "technical founder," I spent all my time coding and lived heads-down, with no bandwidth to think strategically about the product long-term. Gaining time lets me rebalance.

I love coding. But coding was eating up brain cycles I needed for strategy.

That's no longer the case.

I can spend more time on the "why" instead of just the "how."

Time to Improve, Not Just Expand

Time has always been scarce in software and startups. When I gain time, I spend it on other product work: improving user documentation, strengthening test infrastructure to prevent future problems.

I tackle bugs I see in the logs, or UI quirks I'd noticed but pushed off indefinitely.

You know the feeling—that infinite Jira backlog filled with small improvement tickets. Those famous "we'll do it later" items that exist mostly to make us feel better, or to satisfy the support person who asked about them.

"Look, it's on our TODO list. Yeah, it'll take 15 years to get to, but it's there…"

That doesn't exist for me anymore. Small issues like that pile up by the dozens, and the product steadily improves.

Using the financial analogy of technical debt: once code costs less, you pay down the debt continuously, which reduces the interest burden.

Time to Learn

Since I spend less time coding, I've had much more time to think deeply about problems. And I've invested in education.

Before, time pressure forced shortcuts. Recently, I've documented and written about content moderation on platforms, dug into SSL certificate systems, explored proof-of-work captcha mechanisms, studied purchasing power parity.

And here's the surprising part: I've just stepped away from the keyboard.

Often in my typical day, I spend time away from the screen. I've improved my broth technique for ramen. I've done home repairs and started building furniture.

Paradoxically, that time helps me build better products.

Ever notice you solve complex problems in the shower?

Letting your mind wander is creative fuel.

It took me a while to accept it, but giving your brain rest—letting it incubate ideas and wander while you do something else—is excellent for problem-solving.

Of course, I know my situation is specific. I can't imagine starting a woodworking session in the middle of an open office surrounded by developers. But for me, gaining time on code means a holistic rebalancing of my days and, paradoxically, better-quality output.

Because it was never just about coding—it was also about thinking long-term, which is easier when you have time for it.

Clearly, though, it's different in a more traditional context. So I did some research on what others are saying.

Productivity and Burnout: The Real Cost

One of the first insights comes from a Harvard Business Review study. Increased productivity doesn't lead to reduced working hours—it leads to intensification.

Work becomes more intense for several reasons:

AI removes cognitive breaks. Since AI makes it faster to start a task, you lose the natural pause that exists at the beginning of each project when you're figuring out the approach.

AI blurs job boundaries. You feel capable of doing frontend, design, ops, backend, mobile. Your scope explodes for a single person.

Frequent gratification drives endless continuation. If you complete 10 tickets a day and each is quick, why not one more? One quick prompt before closing the laptop?

But this intensification comes at a real cost: fatigue, burnout, mistakes (because tired people miss things).

I found an article that compares AI to a vampire draining our energy.

The idea is simple: since AI handles all the simple, repetitive tasks that used to serve as cognitive breaks, we're left essentially doing high-level work and critical decisions.

But humans can't make critical decisions nonstop for 8 hours a day. It's exhausting.

That's why I personally either step away from my screen for part of the day or do more recreational activities at the computer: writing an article (which explains why I write more now), or learning something new. The article recommends finding a new balance.

I'm not sure how sincere the article is, but this seems to be GitHub's approach. They used the time gain not to drastically increase output but for other kinds of work: collaboration, reflection.

Doing More ≠ Doing Better

There's a hard limit to how many new features users can absorb daily anyway.

Just because you can ship 10x more features doesn't mean it benefits users.

This is Tesler's Law, also known as the Law of Conservation of Complexity. Every system has an irreducible level of complexity. If you reduce it in one place—say, developers moving faster—it appears elsewhere: users now have to adapt to software that evolves too quickly.

You also risk "feature fatigue," where software becomes bloated and overwhelming. Being forced to make choices is often healthy.

Essentially, speeding up benefits no one, and it's preferable that productivity gains show up as better-thought features or increased work on "invisible" quality.

When Productivity Creates Boredom

There's another scenario worth mentioning. Many people work at organizations where going faster changes absolutely nothing, because the company is fighting its own inertia more than any product challenge.

I worked at a large corporation once. I remember a project in 2003 where coding really wasn't the issue.

I'd come from a more dynamic job. I was used to a certain pace. Here, I was given a program to write. I finished it in 2 days. I went back to my manager. He said we'd discuss it again in 3 weeks. In a year, I shipped almost nothing. It was probably the worst year of my career.

Mornings brought people asking who wanted to attend meetings about various topics. I couldn't understand why everyone kept going.

But then I got it. It was to fill the day.

If I'd spent 1 hour instead of 2 days on my work, I'd just have been bored longer.

I knew burnout existed. But there I almost experienced burnout's opposite: complete stagnation. Eventually, I educated myself on the side in areas I cared about. I made that time count.

But I won't lie—I was incredibly relieved when that project ended.

The point: in some places, coding faster changes nothing. Coffee breaks just get longer.

Freelancers: From Time to Value

Now there's a population I have real questions about.

Let's say code costs collapse. What happens to people billing by the hour?

You could imagine a chunk of them won't exactly broadcast that they finished a job faster, since that means losing money.

Can that hold long-term, especially for a freelancer working on-site at the client, visible to everyone? In big companies, maybe. But it'll never work in an organization whose developers are also using the same tools to move faster.

That's where I wonder if fixed-price or outcome-based billing might become more attractive than hourly rates.

Usually, I advise against results-based contracts, especially for younger freelancers, because it's hard to contract properly, set boundaries, and accurately estimate work beforehand.

But if AI made development faster and more predictable, fixed-price work could regain appeal.

It wouldn't be about billing time. It would be about billing value.

I'd have no problem charging a fixed amount for valuable work, even if it took only 1-2 days.

I've worked 25 years to deliver that result in 2 days. Clients pay for your experience and your ability to use tools. Speed is irrelevant.

In a worst-case scenario, I might lower prices slightly, but the risk I take on also gets priced into a fixed contract.

That said, I'm not sure this logic holds forever. Competitors as good as me might take on more clients to offset losses, driving per-contract prices down.

I came across an article on this. It concluded that expert freelancers will survive, but demand will shrink. Especially since their clients will also start coding if the cost drops low enough.

But one takeaway stuck with me: AI won't replace the freelancer. The freelancer using AI will replace the one who doesn't. That's probably the most important lesson.

Conclusion

Again, the question wasn't whether AI makes us faster. The real question I wanted to explore was: what do you do with the time you gain?

The answer depends on your context.

If you're at an organization paralyzed by inertia, moving faster changes nothing—you'll just get bored sooner. If you're product-focused with the freedom to manage your own time, it's an incredible opportunity to step back and think strategically. If you're a freelancer, maybe it's time to renegotiate.

But here's the critical constraint: productivity only matters if it creates value. Shipping 10x more features might actually hurt your users. Gaining time is great, but it's only valuable if you know what to do with it.

Bottom line: there's no one-size-fits-all answer. But you might just gain the time needed to figure out what your answer is.