DEV Community: hugo lassiege

A Slowdown in AI Development?

hugo lassiege — Tue, 15 Sep 2026 14:14:11 +0000

Coup de théâtre, several AI actors are calling for a slowdown in the development of frontier models and the implementation of regulation. AI progress would be too rapid and could pose serious problems in the future.

But could this be hiding something? Could it be yet another marketing move to continue fueling the hype in the sector? Or could it be a kind of desperate attempt to lock down the market and escape a complicated financial situation?

Dario's Letter

It all started with Dario Amodei's letter published a few days ago: "we must pace the frontier".
(Dario Amodei is the current CEO of Anthropic which publishes Claude)

In this letter, Dario calls for regulating/slowing down/securing AI development. He highlights recent incidents around the Hugging Face cyber attack and the escalation linked to the acceleration of development with models that self-improve.

He therefore proposes several measures:

the establishment of audit and control bodies
the implementation of security and development standards for models
international coordination to regulate at a global scale

Following this, Sam Altman (OpenAI) and Elon Musk (xAI) both validated the request on social networks, which in itself is already a huge surprise, as the three aren't exactly the type to spend vacations together.

But we should probably read between the lines.

A Pre-IPO Period and a Shaky Model

A quick reminder of the context: OpenAI and Anthropic are planning an IPO soon. Both companies are far from profitable and spend billions on model training or inference costs. To win or maintain market share, the two giants are cutting prices and subsidizing token costs at a loss. But with massive and constant investments and rising competition, especially from Chinese models, the business model seems very shaky and could well cool down stock market investors.

We're witnessing a real arms race in an industry that's largely overheated, where the first one to slow down loses. But above all, the level of investments already made makes it impossible to slow down. It would be complicated for investors to accept that model performance suddenly stagnates. Investment plans include datacenter construction, electronic component purchases, electrical capacity, etc. Announcing a slowdown today would be a big blow for many players, but also a negative signal to send before an IPO.

Except that accelerating to crash into a wall with a business model that doesn't hold up is not an attractive scenario either.

So perhaps this letter would be a way to create an exit.

Permanent Fear Marketing

Dario's letter is part of a marketing strategy that has already proven its worth. Remember the precedents:

In 2023, an open letter was already published to slow down, already signed by Elon Musk
Also in 2023, the statement on extinction risk signed by Sam Altman and Dario Amodei
In 2024, statements from OpenAI researchers on safety and governance risks
In 2026, statements from Jacob Coxon (Anthropic)

I could make a very long list and even go back to Musk's first statement in 2014.

It's quite clear that some people on this list can be sincere about these statements, but I find it hard not to see a certain form of marketing strategy.

Highlighting that a technology is an existential risk to humanity, especially if it falls into the wrong hands or if it's designed without safeguards, allows two things:

to highlight that we're working on an extremely powerful technology that deserves investment or purchase
to call for regulating new players by locking down the market

Dario's letter, which many experts have debated for 1 week, is nothing more than an extension of this marketing. But we're starting to see some novelties.

A Call for Regulation to Slow Down Competition?

In the text, the CEO of Anthropic explicitly targets the prohibition of actors doing distillation:

Crack down on unauthorized ++distillation++ by companies in authoritarian countries. Distillation of frontier models allows lagging companies to narrow the gap using a fraction of the cost it would take to develop their own AI independently.

We also find:

a call to limit the sale of the most powerful chips to China (but more broadly to non-US competitors)
various hints in the text aimed at slowing down/blocking open weight models (reinforcement of audit methods, incompatibility with the notion of certification checkpoints)

So in your opinion, who would be penalized by AI regulation as requested by Amodei?

Chinese actors who massively use distillation to offer competing models at a fraction of the price
Open source and research that rely on open weight models and which anyway won't have the means to implement audit mechanisms, not to mention that certification bodies won't necessarily be so independent
Mistral, which could no longer exploit open weight models in these infrastructures and would also have to implement certification mechanisms that are probably very costly and controlled by the US
New entrants for whom the entry ticket will be too high
Hosting providers that sell computing power on open weight models

In short, it would be a tough blow for open source, Europe and its sovereignty, and companies, resulting in the creation of an oligopoly capable of fixing prices much more easily.

Significant Opposition

One might think that with such strong benefits, the entire American industry would be behind this project. Well, surprisingly, not so much.

While we can blame Amodei, Altman and Musk for hiding their ambitions to create an oligopoly and lock down the market, the fact remains that the stated objective is to regulate AI risks, by imposing global regulation, certainly, but wrapped in nice gift paper.

But this is not at all the approach of the "accelerationists", notably represented by Peter Thiel and Alex Karp (Palantir) who instead want total market deregulation and whose absolute priority is to beat China.

Unsurprisingly, we'll find this same discourse with Trump (we can remind that JD Vance was introduced to Trump by Thiel), who gave us declarations as outlandish as usual and whose content I'll let you appreciate:

The only control or “guardrails” that AI needs is a STRONG AND SMART (High IQ!) PRESIDENT, and the U.S.A. has that, in spades! The Trump Administration has stopped AI “people” from doing bad, or potentially bad, “things,“ like Dario (Anthropic!), who is now pretending to be a “perfect little angel” - and we will continue to do so! We already have tremendous CRIMINAL and REGULATORY power over these companies! There is a SICK conspiracy going on against AI and Data Centers, and the only one that is happy about it is China. WHOEVER WINS AI, WINS! We are leading China, and all others, and will continue to do so. Conspiracy Theorists, Treasonists, Traitors, and Leakers, BEWARE! Thank you for your attention to this matter! President DONALD J. TRUMP

Good thing he's there, the show is always guaranteed…

But we also find this opposition in Jensen Huang (CEO Nvidia) who, let's remember, just bought Hugging Face for 13 billion dollars and just invested in Mistral. The company sells chips and computing capacity to everyone and sees open source as an opportunity, at least business-wise anyway, so the slowdown requested by Amodei is far from his priority.

And Europe?

The simple fact that Trump is opposed to the slowdown project buries this project at least for the duration of his term in the US. It's hard to imagine a slowdown by 2028, at least not for these reasons. And even in the future, it seems uncertain to me to imagine that the US would accept seeing China overtake them without reacting.

On the European side, the discussion risks having lasting repercussions instead. It gives grist for the mill for EU regulators who would be happy to implement more stringent standards, and for some governments who would like to take control. Not to mention some politicians who are a bit lost when it comes to the issues and could play against their camp without even understanding it.

These hesitations risk putting us (in Europe) in a bad position if we were to add barriers to the open source world, to open weight models or our local champions.

In short, this call for slowdown seems to me mainly a maneuver to ensure some stability in a market that has gotten out of hand. If the authors were really sincere about the concerns of model alignment, if they were worried about AI escape risks, they already have the means to work on the problem.
The real existential risk today is more about their future IPOs, rising competition and a European market that could choose another path with open weight models.
It seems unlikely in any case that China would subscribe to this call, nor would the Trump administration, and I hope Europe won't give in to the temptation to strengthen legislation at the cost of our future sovereignty.

Migrating from Github to a European alternative

hugo lassiege — Wed, 09 Sep 2026 15:55:52 +0000

Among the important basic building blocks for building software that are monopolized by the US, I present to you: Github (Microsoft).

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:

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):

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…

The Default Transparency Trap on Bluesky and the ATProto Protocol

hugo lassiege — Mon, 31 Aug 2026 09:44:28 +0000

You might know Bluesky? It's one of several Twitter clones born in 2019.

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.

What if the AI bubble burst?

hugo lassiege — Fri, 28 Aug 2026 12:35:31 +0000

If there's a trendy topic in tech right now, it's AI. And it's normal, given the amounts invested on one hand, the societal transformations on the other, not to mention all the issues and risks related to employment and ecology.

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.

My software stack to build products

hugo lassiege — Tue, 25 Aug 2026 07:31:43 +0000

I would like to list here the software that I use or recommend to create products.
I have an approach that deliberately aims to support the European market, so I prioritize, in order:

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…

Hosting

Actor	Country	Usage
Scaleway	French	S3 storage
Hetzner	German	Dedicated machine to run Coolify.
Coolify	Hungary	PAAS I'm thinking of switching to Scaleway which is more suited to infrastructure as code
Github	US	Git hosting Currently testing an alternative. Stay tuned :)

Payment

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

Actor	Country	Comments
Stripe	US	Sorry… For now I haven't been able to get around it

Alternatives that I couldn't test:


creem.io	Estonia	Missing metered billing and connect part
Mollie	Netherlands	All pricing management and metered billing has to be done manually
Paddle	UK	no Stripe Connect equivalent

Analytics

Actor	Country	Usage
Openpanel	Sweden	Web and product analytics

DNS - CDN

Actor	Country	Usage
Bunny.net	Slovenia	DNS, CDN, WAF, Optimization, Edge

Support

Actor	Country	Usage
Fernand	France	Help desk

alternative often cited: Crisp (France)

Monitoring - logging - observability

Actor	Country	Usage
Phare.io	Estonia	uptime
Sentry	US	error tracking (currently switching to bugsink)

Alternatives currently being evaluated to replace Sentry:


BugSink	Self hosted (Europe)	error tracking
OpenObserve	Self hosted (US)	Observability

Feedbacks

Actor	Country	Usage
Fider	Open source (country ?)	Feedback, changelog, roadmap

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

Emails

Actor	Country	Usage
Scaleway TEM	France	Transactional emails
AWS	US	Marketing 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

Actor	Country
Writizzy	France

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

Social networks: what if we had the solution to escape US Big tech?

hugo lassiege — Wed, 19 Aug 2026 14:08:38 +0000

When you look at topics around privacy or sovereignty, one problem regularly stands out: social networks.

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

We must not pit ecology against sovereignty

hugo lassiege — Sat, 08 Aug 2026 09:08:57 +0000

In France and across Europe, data center projects are facing growing opposition. From local protests and legal proceedings, to anti-digital, anti-AI, anti-data center political rhetoric.

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:

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.

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:

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?).
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)
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:

Fund sovereignty: Provide the computing power needed to develop our own champions, secure our data and run strategic industrial and scientific AI.
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.

The Price of Digital Sovereignty

hugo lassiege — Thu, 06 Aug 2026 14:25:05 +0000

I create a service in Europe and one of my principles is to try as much as possible to build it on a 100% European stack, or at least non-US. My servers run on Hetzner, my CDN is Bunny.net, I use Scaleway for several services, Hostinger for part of DNS… On paper, it's coherent.

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.

CTO from startup to scaleup

hugo lassiege — Mon, 03 Aug 2026 10:14:35 +0000

I've been thinking about writing a post on the role of a CTO in a startup for a while. However, I always told myself it wasn't interesting, that I should talk about it when the company was much bigger, when we were a unicorn, etc...

And so I kept delaying this post for months, then years...

However, over the years, I realized that the journey could already help others.

I have benefited and still benefit from the feedback and experiences of many other tech leaders and entrepreneurs who are at more advanced stages.

But while I read and am very inspired by successful entrepreneurs or product leaders like Jean Baptiste Rudelle, Reid Hoffman, Marissa Mayer, Marty Cagan, I also know that when you start a company, these people can't help you. Their daily life has nothing to do with mine.

Moreover, while there are of course hundreds of thousands of tech leaders who are CTOs of consulting companies, development directors, etc., with engineering teams larger than the entire size of Malt, I think the job of CTO in a growing startup context has some specificities.

And that's how I decided to talk about the CTO role, from startup creation to its transition to scale-up.

To set the context, I am CTO and co-founder of Malt, a marketplace allowing freelancers to work with companies of all sizes, from SMEs to large CAC40 groups and now in several European countries with offices in France, Spain, and Germany.

The company has almost doubled in size every year (except 2020...), going from 3 people in 2013 to 200 in 2021. The product team currently has 50 people.

Over the next 18 months, we plan to double the size of the product team to about a hundred people and accelerate our expansion in Europe, making us enter the status of scale-ups.

Let's start from the beginning.

CTO, self-leader, in a team of 1 (2013-2014)

Do you really need a CTO to start a startup?

Malt started with a meeting in 2012. At that time, we were 3: Jean Baptiste Lemée, Vincent Huguet, and myself. The association would therefore count 2 "CTOs" and one CEO.

I often have discussions about the best teams to start a startup. Can you start alone? And if not, what is the best team composition? How should roles be distributed, etc...

It would be a much too long article if I tried to answer all these topics, but I'll focus on the CTO role.

I won't beat around the bush: from my point of view, the CTO role is crucial for a company that wants to build a product.

I don't know any startup that has passed the 3/5 year mark without a CTO.

I've heard from investors that it's even a serious red flag in a startup file to come without a technical co-founder.

You can of course start an idea without a CTO. You can make first versions, and even do a first funding round, with a product made by an agency, or made with no-code tools.

But at some point, the CTO is necessary for the company to develop. The CTO will bring the vision and technological governance necessary for the future.

On the other hand, and this is what I'll try to describe in this post, the typical portrait of the CTO at this stage is not the same as the CTO in a company of 500+ people.

CTO is above all being the first developer

As co-CTO in the first months, I was mainly boss of myself. I was above all a developer and my main activity with Jean-Baptiste was to code the Malt website.

Product definition was done among the 3 founders.

It was a mix of dev, choices between buy or build (the famous buy or build) but with scrappy solutions. There's no bigger challenge than speed at this moment.

Of course, I didn't want to build a shaky house of cards, but you have to be pragmatic and ensure very good execution speed.

Full stack CTO

At this stage, you're involved in many subjects you don't know: SEO, data analysis, data engineering (poor man's version), data science (even poorer version), system administration, QA, PM, UX Designer, front-end, back-end, etc... You define the product and write it right away.

But it doesn't stop at the product, it's also IT support, customer support, finance, etc...

Of course, I wasn't good at everything. And today they still tease me about screenshots of my old UX work. Anyway, the CTO is the person on whom you can then stick all the "Historical" baggage, with a capital H, and you have to live with it :)

By taking on the entrepreneur hat, you have to remember a phrase: "If you're not ashamed of your product, it means you released it too late." (Reid Hoffman, co-founder of LinkedIn).

The typical profile

The typical profile at this phase is a person who gets their hands dirty and moves fast. It's also a person who likes to learn new things and is okay with being constantly out of their comfort zone.

By nature, a good engineer is rational, rigorous, methodical. But be careful, dogmatism is an enemy at this stage. You have to accept a dose of creative naivety and the very many compromises with what you could have done in much larger teams. At this stage, you shouldn't seek to be a person who will structure a team. You shouldn't spend time on process optimization or organization.

Compensation

Salary-wise, the CTO at this phase shouldn't expect top tier salary ^^ You'd earn better elsewhere.

This is the major difficulty in finding a CTO when you're not one yourself. If I exclude young CTOs, any experienced person would be better paid elsewhere than being CTO of your startup. Personally, I earned much better as a freelancer at that time (>50%) and working less.

Associating the CTO with equity is important to engage them for the long term. The CTO who joins at startup expects 30/45% of shares. I won't dwell on the criteria of how to determine this, but there are sources on the internet to help you.

For my part, being an associate was necessary, but I never told myself that it would compensate for what I was losing. Of course, when you start, you want the company to work, but to be 100% sure that the company will one day be a complete success, we know how much it's a bet and that very few people make it.

On my side, I accepted earning less because I found it very enriching. I always loved creating my own product, making it grow, learning new trades, and being my own boss. The freedom I had and the impact I brought motivated me in this adventure beyond the financial aspect.

CTO, squad leader in a startup from 1 to 20: (2014-2016)

(product team from 1 to 10)

There you are, the first hires in the product team. Your CPTO (Chief Product and Technology Officer) role grows. Product definition is still done among founders and you're still mostly hands-on more than 90% of the time, but you have another responsibility: creating a team.

This is a phase that is actually pivotal in more ways than one, but I didn't know it yet.

Learning to "fire yourself"

This will be one of your mantras later, how to constantly fire yourself?

Now, you need to hire colleagues to do certain jobs and do them better than you. No more PM, UX, Front-end roles, etc...

I have the impression that some CTOs get stuck at this stage because they can't hire better than themselves. Is it related to a feeling of insecurity? A way to want to keep control? No idea. But it will be very hard for the future...

The CTO, still a developer

At that time I was 90% developer. 2015 corresponds to my peak activity in terms of commits on Github (see below). The product team was about ten people at the end of this period.

In a team of this size, autonomy is great, the methods used are very light, and the "time to market" (the ability to quickly go from idea to users) must remain very short. There are no estimates, no sprints, scrum master, QA, OKRs, and so on. Decisions were quick with few people to convince each time. Change management was "simple" (and yet we sometimes tripped up anyway).

A recruiting career that starts

Recruiting is 90% of the company's success and that's why I spent a phenomenal amount of time on it.

In total, I must have seen almost 1,000 CVs. I conducted 300 first video interviews, between 100 and 150 physical interviews (also counting for other roles in the company even if I wasn't the main recruiter in those cases).

Recruiting also means making choices about team organization, the culture you're going to create, the fundamental values you're going to instill. This translates into seniority, autonomy, adaptability, entrepreneurial spirit of the people sought.

I made a pivotal choice at the time, I chose during recruitment to only take seniors, completely autonomous people. I didn't want to do management and manage juniors or coach intermediates. The organization remained light, communication simple, autonomy great.

This philosophy allowed me to continue developing on Malt for quite a while, but beyond that, it seems to me that it's a success factor and part of our growth.

Your CPO/CTO/founder role requires more time.

Beyond your role in the product team, your role in the company also takes on a bit more importance. You have more interactions with more people outside your skills, trades appear like support, sales function, marketing, and you have a business enabler role (sorry I couldn't find a satisfactory French translation). You carry the "voice of technology and product", it's up to you to identify when it can serve the company's needs, when it can bring answers to your customers, but also when you need to know how to make choices (and say no).

I specify of course that this role was not done solo. As since creation, it's the trio of founders who play the role of full-stack entrepreneur at all levels.

CTO, guild leader in a company from 20 to 50 (2017-2018)

(product team from 10 to 30)

More complex interactions

In 2017-2018, I spent a large part of my time recruiting. And by doing this, I passed the fateful threshold of 10 people in the product team.

This threshold of 10 starts to change how a team functions. Interactions are more numerous, communication becomes more complex, and small groups start to form to remain effective.

Brooks' law perfectly illustrates this growing complexity in group interactions past a certain threshold:

It was at this moment that I was delighted with the team already in place, on which I could rely. The fact of having recruited many seniors limited the need for human management. Some leaders naturally emerged and the team was able to continue functioning without heavy management for another moment.

My model was that of the previous company I had co-founded, Lateral-Thoughts: sociocracy and governance by circle.

The CTO role at this stage is very team-centered, very present at all levels, the CTO is there to compensate for the absence of formal structure.

And this is not abnormal, it was still too early to bring more structure, and at the same time, we had to start working on subjects like alignment and long-term vision.

Without being a pure people manager, I had to greatly improve the recruitment process and work on subjects like career path or salary grids. However, I didn't set up a formal process to see each person in the team. I was counting at that time on the fact that discussion should happen naturally and that everyone was big enough and close enough to me to talk to me about subjects that bothered them. Spoiler, it worked, partially. At this stage, it was still possible, we saw each other a lot and communication was very open. However, during the next phase, this principle no longer worked, especially in the context of the COVID crisis.

A developer role that decreases

As CTO, I'd say my share of time spent developing must have decreased. I'd naively say around 60%.

The organizer role took more place. I was the person in charge of greasing the wheels.

It was still a schizophrenic role: developer, coach, manager, scrum master.

If pure development decreased, it remained important and key on orientations and technological choices. The activity changed in nature, but I'd say this developer role remained major for the company's success. At this stage, I was still able to bring significant changes to the application in a few days.

To illustrate with numbers, here's a graph representing my Github activity from 2012 until today, which well illustrates the decrease in activity in 2017-2018 (and the 2015 peak):

A permanent ambiguity

As mentioned above, as CTO (and founder), you constantly change hats, several times in the same meeting.

You're still a "full stack CTO" but in the meantime, you've recruited, and these permanent hat changes can bring some confusion for company members who arrive.

It can be hard for people to tell when the founder is speaking on a subject as a "participant", for example in a brainstorming session, and when the CTO is speaking as a technical leader, to express a direction to take or as CPO to establish product strategy.

I had many discussions with Malt members to clarify my positions, assume this CTO role that was until then mainly a label I didn't claim, improve my communication. And I greatly thank all the people who at that time pushed me, made me think and grow.

It was necessary just before the next phase because I would have to make stronger choices about what I wanted to do or not.

CTO, tribe leader in a startup from 50 to 200 (2018-2021)

(product team from 30 to 50)

The 2018-2021 period is special in more ways than one. Between 2018 and 2020, the company doubled in size each year. 2020 was marked by COVID with different management to implement and turnover that took off. In the same period, the company progressed several notches at all levels.

A team that needs to start being structured

I mentioned it above, the complexity of communication when you increase the number of people involved grows exponentially, and it was during this period that we had to pass many milestones.

As CTO, it was time to add structure so as not to degrade execution speed. If too strong structuring could have slowed down Malt at the beginning, it became necessary to then scale.

This is the moment to realize that a product team requires impeccable coordination and animation. In a tech startup like Malt, at this stage of development, the size of the product team should take a ratio between 25 and 50% of total staff (ratio that decreases with growth thereafter). It's therefore one of the largest teams. Each squad/feature team/impact team/tribe, call them what you want, corresponds to collaborations of several different trades. They're not just mercenaries working each on their side. Each person, each decision influences another person in the group in the short or medium term. Moreover, almost all people in the company rely on the product or tools made by this team.

Technical or business debt is collective. But if we also see it positively, each improvement, each good practice substantially improves the entire team and company.

In short, it's a complex mechanism and, fortunately, there are many companies that share their best practices. As CTO, you'll need to keep constant watch on these subjects, the same way you were used to doing on more technical subjects. I also propose a list of resources at the bottom of this post.

Time for choices

I mentioned it at the very beginning, the CTO's goal is to "fire yourself" with startup growth. And the transition to 100 in the company accelerated the movement.

At this stage, it was time for choices. As CTO, I could no longer develop, organize, establish strategy, recruit, coach, etc... Or do everything badly.

In the rest of this paragraph, I'll mention the personal choices I made. Each CTO (and this is even more true for a founder) will make different choices. There's no right or wrong solution, you also have to work with your strengths, weaknesses, and interests.

First decision, I almost stopped all development. OK sometimes it comes back to me, but it's anecdotal. I always need to understand what's being done, but it's mainly out of curiosity. I should never be in the blocking path for development.

Then, I always considered myself an individual contributor, not a manager. So afterward, I brought in a VP of engineering to take care of management and processes.

We brought in a CPO on product strategy in 2018. However, this role disappeared in 2020, and I have a role that de facto became that of CPTO again, but with a team of super strong product leads to help me and with whom I'm delighted to work daily.

Thanks to these leads, I remain very involved at the governance level on subjects that are and will remain crucial for Malt's scaling.

They accompany me in all key areas: security, architecture, data, cloudops, product strategy, design, etc... I spend a lot of time with them on strategy and objective definition, problems to solve, but then they're autonomous on how to do it, and I help by putting oil in the gears when necessary.

And what's next? The transition to scale-up

As I indicated in the introduction, Malt is starting to enter the restricted world of scale-ups. The next objective to respond to Malt's growth and its expansion will be to continue investing in the product team. It could double in the next 18 months and reach about a hundred people.

Scaling this team will require enormous work. A large part of this work rests on the CPTO and the product leads team I mentioned previously.

The stakes are high: recruitment speed, quality of new arrivals' training, team autonomy, execution speed, product strategy, user research, OKRs, technology scaling.

The CPTO role will undoubtedly be very strategic. I'm going to work on OKR deployment at each level and on monitoring and coaching the product leads team to respond to these subjects. At least that's what I imagine, but the past has shown me that the most important thing will be adaptability.

This might be the subject of a new post in 18 months.

And if you want to be part of the adventure, we're constantly recruiting throughout France. Contact us.

Interesting resources as CPTO:

Inspired and Empowered by Marty Cagan, the two books I so regret not having read several years ago. You must read them :)
Turn the ship around by David Marquet, on leadership and how to create leader/leader relationships
The future of management by Gary Hamel, a must-read on innovation and managerial structures
Measure what matters by John Doerr on using OKRs
On m'avait dit que c'était impossible by Jean Baptiste Rudelle on entrepreneurial spirit (only available in French, sorry)
https://randsinrepose.com/welcome-to-rands-leadership-slack/ for tech leaders worldwide (14k members)

My Software Factory in the Age of AI

hugo lassiege — Wed, 29 Jul 2026 13:39:43 +0000

I'm creating this page to document my "software factory". It will be more of a reference page than an article and I will reference it on the resources page of the site.

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:

What does the agent know? (context, memory, code graph)
What can it do deterministically, without improvising? (skills, procedures)
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.

File	Content
`CLAUDE.md` (root)	Architecture, cross-cutting conventions, specs index
`.claude/rules/*.md`	Thematic rules (commit, backend, front, long-term constraints). Often refers to a more complete skill, loaded only when needed
`.agents/*.md`	Non-technical context (product positioning, personas, tone)

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:

Family	What they encode
Backend	Layer conventions (API, persistence, services, transactions), testing strategy, end-of-task checklist
Frontend	Architecture, typing, UI standards, getting up-to-date documentation (JS frameworks move faster than model training)
Data	Migrations, investigation queries
Product cycle	Spec writing, spec closing, implementing a theme mockup
Operations	Runbooks: handling a production error, moderating, auditing SEO
Writing	Commit convention, cleaning up AI writing quirks

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

Server type	What it unlocks
IDE (JetBrains)	Build, inspections, refactorings, indexed search. Much faster and more structured than command-line build
Code graph (GitNexus)	See below
Business services (payment, error monitoring)	Read the actual state of the system instead of guessing
Database	Direct investigation, dev and prod
Browser	Reproduce a client-side bug, QA

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.

Trigger	Effect for me
Before a shell call	Refuses native build command, redirects to IDE build (faster, structured errors) and explains the fallback
After file write	Runs the formatter/linter automatically on the touched file

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.

Stage	What it covers
Unit	Pure logic, fast, massive
Integration with disposable containers	Real database and broker, no mocks
Architecture	Structural boundaries (layer 4)
Front components	Rendering and composables in a framework environment
End-to-end	Critical journeys only

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:

Need	Mechanism
Enable/disable without redeploying (rollout, kill-switch, maintenance)	Feature flags (Unleash for me)
Restrict by customer contract / plan	Configuration table + gating service

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

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.
An error must be documented. Every error must be recorded in a skill or in memory.
Context is a budget. Wrappers, filters, sub-agents, summaries: everything that reduces noise keeps reasoning on the problem.
Measure impacts before and after editing. We want to avoid the effect "1 bug fixed, 10 produced".
Repetitive procedures don't improvise. One skill per procedure.
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.

Why I'm Not Making Writizzy Open Source

hugo lassiege — Tue, 28 Jul 2026 08:26:06 +0000

Why do open source today?

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.

My AI stack for developing products without breaking the bank

hugo lassiege — Wed, 15 Jul 2026 16:24:37 +0000

Can you really build applications today with AI AND only spend 20 euros a month?

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:

Frame the expected result. We first define the direction, user flows, etc.
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.