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

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

And then I get up and introduce myself.

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

Basically, I'm terrible at design.

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

2011, the army of clones

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

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

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

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

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

From atomic design to design systems

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

::gallery ::

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

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

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

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

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

Tailwind and design tokens

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

And it's rather simple to express globally:

.button { border-radius: 4px; }

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

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

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

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

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

For example:

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

etc...

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

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

My pre-2024 workflow, Tailwind and its component libraries

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

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

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

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

And then came AI

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

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

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

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

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

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

First, what is Claude Design?

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

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

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

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

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

In short my workflows are as follows:

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

And more recently, I'm testing:

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

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

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

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

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

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

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

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

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

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

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

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

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

Paid acquisition

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

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

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

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

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

Conversion tracking

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

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

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

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

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

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

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

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

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

Conversion metrics

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

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

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

It becomes interesting when CAC is less than LTV.

Ok, this sentence is cryptic.

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

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

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

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

Stripe tells me my LTV is 181 euros.

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

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

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

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

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

Reddit Ads

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

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

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

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

I set up two campaigns to test two approaches:

One campaign emphasizes the price difference with Substack.

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

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

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

We note:

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

Because yes, I made some big mistakes…

Campaign setup

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

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

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

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

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

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

Audience restriction has other benefits, two for my case:

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

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

So I reduced the audience to North America and Europe.

Landings and conversion

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

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

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

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

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

The bottom line

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

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

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

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

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

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

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

So will I try again? Yes certainly.

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

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

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

And I'll try other angles for future landings.

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

You might say it's pretty straightforward.

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

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

Two-phase commit transactions

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

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

But there are several problems.

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

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

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

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

$0.99 \times 0.99 = 0.9801$

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

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

The transactional outbox pattern

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

The concept is "simple":

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

The code becomes

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

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

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

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

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

And you need the publication service code

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

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

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

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

And... you're not wrong.

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

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

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

Here strategies are multiple:

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

etc...

And error handling?

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

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

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

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

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

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

Challenging your own developer beliefs with AI

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

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

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

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

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

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

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

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

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

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

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

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

::gallery ::

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

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

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

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

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

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

The Rise in CVEs

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

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

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

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

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

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

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

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

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

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

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

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

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

With AI, It's the Death of Craft

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

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

Wait, here we have two different subjects:

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

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

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

AI Slop and Software Maintenance

Do you know Dave Farley?

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

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

(okay grandpa but continue your story)

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

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

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

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

Building an Agentic Software Factory

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

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

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

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

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

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

Anyway, you need the other tools.

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

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

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

Craft hasn't disappeared. It has changed.

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

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

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

The Writizzy Example

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

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

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

Well today I'd say that it shows.

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

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

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

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

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

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

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

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

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

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

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

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

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

What is Writizzy?

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

Code-wise, we have three big pieces:

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

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

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

Context Engineering: Constraining the AI

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

The Claude.md file

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

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

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

The Rules (.claude/rules)

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

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

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

Example of a question I recently asked him:

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

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

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

The "Analyst" command

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

Specs before code

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

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

With AI, the spec has two major interests:

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

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

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

The art of managing your context window

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

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

Skills vs MCP: The efficiency battle

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

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

I have skills for different things:

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

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

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

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

So I prefer Skills, except for:

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

What about design?

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

Balance sheet: How to stick to the budget?

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

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

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

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

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

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

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

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

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

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

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

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

SEO is Failing

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

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

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

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

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

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

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

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

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

Insights from the First Run

Claude-SEO tests many things, especially technical SEO.

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

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

HTML

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

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

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

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

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

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

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

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

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

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

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

An Instructive Second Run and a Few Bugs

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

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

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

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

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

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

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

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

The Verdict?

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

I highly recommend testing it on your own site.

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

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

And there, it’s a mystery.

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

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

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

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

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

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

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

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

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

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

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

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

And apparently, a solution is currently being studied to counterbalance this slow digital colonization: Open Source.

Okay, let’s explore this path and try to understand where it might lead us.

264 Billion Euros and 1 Million Jobs

264 billion euros and 1 million jobs, that’s what Europe lets slip away every year to major American Tech companies (Cloud, AI, etc.).

This figure hides massive blind spots. Digital technology means direct AND indirect jobs, risks of espionage, and proven cases of public opinion manipulation.

It’s also a constant weight on our diplomatic relations, because it’s hard to resist our digital dealer when they impose conditions, for instance, demanding we abandon inclusion policies within our own companies.

In this context, Europe wants to rely on the European Open Digital Ecosystem.

So, is Open Source the solution?

Open Source and Geopolitics?

If money has no smell, does Open Source? Not necessarily.

An open license tells us nothing about a project's governance, meaning, who decides and who captures the revenue.

A huge number of major open-source projects are simply funded by large American corporations (e.g., Kubernetes, React, VS Code). GitLab, for instance, sees a vast majority of its contributions coming from salaried engineers.

Another part of these projects is managed by foundations that may also be based in the US (Apache, Linux, Mozilla).

In the event of a conflict, even if Open Source is "open," Europe could find itself penalized.

We could be excluded from major distribution platforms, like GitHub, which has restricted usage in Iran in the past.

A project could unilaterally decide to stop supporting local standards or legislation (such as privacy regulations).

A state could influence contributors to insert backdoors.

But it’s open source, you might say. We could just create our own fork and maintain it in Europe, right?

It’s not that simple.

That would imply finding, mobilizing, and funding armies of contributors in Europe. Contributors who would spend a portion of their time "just" catching up with the original code and verifying that no backdoors were introduced to target us.

In short, it requires resources and people willing to maintain projects built elsewhere.

Then there’s the concept of the ecosystem. Take Huawei, for example: they forked Android but couldn't access the Play Store or Google Play Services, which severely limited its appeal.

You might argue that we also have foundations in Europe. Eclipse moved to Europe in 2020, making it the largest European open-source foundation.

True, but a foundation lives off membership fees, and the main contributors to Eclipse are American (IBM, Oracle, Microsoft, Intel, Amazon, Google). Not to mention that the Eclipse Foundation isn't the most advanced on current topics like AI or Cloud.

A Structural Fragility in Open Source

This isn't just a hunch; it all circles back to the question of resources.

Until now, we’ve mostly discussed massive projects, but the vast majority of projects rest on fragile foundations.

Open source is underfunded. Countless projects are simply too small to be visible, even though they likely power 99% of modern digital software (source: myself, but I doubt I'm far off).

Between maintainer burnout and the lack of resources to keep up with current demands, it’s easy to connect this fragility to cyber risks. Log4Shell, Heartbleed, and XZ are perfect examples of vulnerabilities and cyberattacks targeting open source.

Relying on such fragile actors without funding them is hypocrisy.

But this conclusion is widely shared, and Europe is planning to put money on the table to fund open source as an alternative to major US software.

We’re talking about funding programs in the billions of euros and policies favoring open-source solutions.

Digital Commons

Of course, we return to the problem mentioned earlier: open source does not mean neutrality. Therefore, Europe is setting criteria and, above all, defining the concept of a Digital Common:

A digital common is not just software (code); it is a triad of inseparable elements:

• A digital resource: Software, a database, a technical standard.
• A community: Developers, contributors, companies, and users who maintain the resource.
• Governance: A set of rules defining who can contribute, how decisions are made, and how to prevent the resource from being captured by a single actor ("vendor lock-in").

An open-source project "dictated" by a single American multinational is not a digital common, because the community has no real decision-making power.

And "digital commons" created in Europe do exist: OpenStreetMap, VLC, and even Linux and the Web.

Toward a Fragmented Open Source?

The primary fear in a digital cold war is seeing a fragmentation of open source: license wars, targeted exclusion of contributors by country, and a decline in international collaboration. It’s already becoming difficult to get visas for international events, and refusing certain foreign travel is becoming both a political and ecological act.

While this outlook is somewhat grim, it is relatively inevitable. In a closing world, open source will not live in an isolated bubble. And this will force us to create our own digital identity.

A European Digital Identity

It’s true: open source alone is not the solution because it is a fragile, underfunded, and inherently non-neutral ecosystem.

A large portion of US Open Source is funded by big US companies, often serving as a digital Trojan horse to capture revenue.

But how many companies in the US actually run on "Free Software"?

Relatively few.

This is less true in Europe. The International Criminal Court (ICC) runs on OpenDesk. Several French administrations have just announced their migration to "La suite numérique".

We could see a European digital identity taking shape, based on standards like interoperability (open formats), reversibility (the ability to easily retrieve one’s data), and the digital commons I mentioned earlier.

We could see industrial consortiums joining forces to create digital standards, such as Eclipse SDV (for Software Defined Vehicles).

We could imagine conditions in public tenders that de facto eliminate US products—for example, an extraterritorial immunity clause to protect us by default against laws like the Cloud Act.

Finally, we can imagine Europe becoming a hub for digital ethics, attracting global talent who want to contribute to projects serving the general interest rather than the stock price of a giant.

In short, open source is not a magic wand for Europe to stop being a digital colony. We will have to go further. This will require courageous public procurement, massive funding of digital commons, and strict legal protection against extraterritorial laws. European digital identity will not be a gift from Tech giants, but an infrastructure we must build ourselves.

And while this figure alone doesn't mean much, know this: it represents roughly 10 times the annual volume of pre-COVID layoffs.

So, can we really say that humans are being progressively replaced by AI as so many claim?

In France, INSEE speaks of a contraction in the job market directly linked to the rise of AI.

But correlation doesn't imply causation, so we're entitled to wonder if there's something else hiding behind all the hype.

So I wanted to dig deeper and explore the root causes to understand this wave. And it turns out AI might not be our biggest concern.

Large waves of departures blamed on AI

If you read the latest news, there's plenty to worry about:

• Oracle just laid off 30,000 people (20% of its workforce)
• Block cut 40% of its headcount

And I could've cited Meta, Amazon, Klarna, ASML, Ericsson, Salesforce—the list goes on.

In most cases, AI is cited as one of the reasons. And this narrative has a major advantage because on paper, these companies say: we're automating, we're gaining productivity, and we're cutting fixed costs. Which tends to reassure shareholders.

Block's stock price, for example, recovered a bit in February following the announcements.

Same with Oracle's stock price (announcement made March 30th).

Now doubts linger, and as one article put it: "Isn't this just layoffs with better marketing—AI washing?"

Block is really compensating for past management mistakes

Block is the new name for Square, a payments company you might know from its little payment terminal that's now fairly ubiquitous:

But Block isn't just a payment terminal—it's also companies in crypto because its founder, Jack Dorsey, is a big believer in cryptocurrencies.

Jack Dorsey is also the former founder of Twitter, which he sold to Elon Musk a few years ago.

And Jack tends to think big. Twitter had 8,000 employees when he sold it—a company that now runs with 2,800 people.

At Block, the company tripled its headcount post-COVID. We're talking about a 12,000-employee company that had just 4,000 pre-2020.

Sure, you can understand it by looking at the COVID effect on Block's stock.

Except the return to reality in 2022 hit hard. The company stagnated, and with an explosion in the payroll, things couldn't end well.

So we started seeing performance improvement plans emerge.

Because if you look at the economic fundamentals, as this article does, you realize that Block is far less profitable than its competitors, with gross margins that are half theirs.

Today, AI is mostly a "pretty" way to hide management mistakes and reassure investors.

Oracle isn't cutting jobs for productivity gains

Oracle's case is a bit different. Officially, it's not about cuts driven by productivity gains, but a reorientation of investments toward infrastructure to support AI.

In their case too, the stock price is rather concerning, but it's not the main driver of changes.

As one article puts it, it's primarily about investment:

The job cuts at Oracle come as it has invested heavily in AI, spending both on its own infrastructure and on partnerships with other companies like OpenAI. It plans to spend at least $50bn on infrastructure this year, and it has also raised $50bn in debt in order to "meet demand" for even more AI infrastructure. Oracle is also part of the Stargate initiative, alongside OpenAI, SoftBank and MGX, an AI investment fund backed by US President Donald Trump.

Here, it's really about reorienting capital from a traditional activity that's flagging to one that's supposed to replace it in a few years.

In reality, I won't criticize it. It's a strategy, a bet. A huge bet, but one that falls into the same category as what Kodak should've done when digital arrived. And Oracle doesn't want to be the next Kodak.

The market is anticipating unrealized gains

And that's really the issue—nobody wants to be the next Kodak.

When a leader (like Block, Google, or Meta) lays off 10% of its workforce and its stock goes up the next day, every other company is tempted to do the same.

Laying people off because you mismanaged your company would be an admission of failure. But laying people off because you're "transforming through AI" is a vision of the future.

And this FOMO—fear of missing out—explains a lot of the current departure plans. Gartner calls it "RIFs before reality", the anticipation of unrealized gains:

The employment deal is being rewritten in real time. CEOs are making bold moves based on AI's promise rather than its proven impact. Layoffs linked to AI dominated headlines last year, but Gartner data shows fewer than 1% were due to actual productivity gains.

This anticipation drives investment reorientations. Oracle's case is representative here. Not everyone is investing in infrastructure, but many are reinvesting in engineering to automate other business functions and, most importantly, to be ready for the future.

AI is no longer just a growth story; it's a cost-reduction tool, and firms are restructuring accordingly. What we're witnessing is a shift from headcount-driven expansion to automation-led productivity, a transition that will define the tech sector in the coming years. —Alan Cohen, analyst at RationalFX

Now, this isn't new, and I notice a certain hypocrisy among some developers who are discovering today that their profession has always been about automating others' jobs. It's a shame to discover it when it touches us personally.

Anyway, what's certain is that companies are anticipating cuts without yet having proof of the gains to come. It's not just a few layoffs—we're seeing signs, notably raised by levels.fyi's founder: we're witnessing a simplification of career paths.

A layoff plan is temporary. But when you start eliminating rungs in career ladders, it signals you're anticipating a durable, global reduction in headcount.

And yet, once again, the gains aren't that obvious so far.

Productivity gains aren't widely demonstrated yet

We all have our opinion on this.

I consider myself more productive with AI. But not everyone agrees.

But in any case, these are just opinions.

There are studies on the topic of productivity, but there's no consensus.

You can find studies showing we're less productive, but you can also find others saying the opposite.

The causes are multiple. The first is what's called the productivity paradox:

You can see the computer age everywhere but in the productivity statistics

Yes, back then we wondered if computers really made us more productive. It was far from certain.

This paradox is explained two ways.

First, companies spend more time configuring tools, training people, and reorganizing workflows than actually producing more.

Second, a new technology requires a learning period that can be quite long to master. And that's what we're seeing today—AI usage is totally new. Many are just faster at doing what they did badly before.

And it's not like we know how to measure developer productivity anyway. I'll remind you that this question still hasn't found a universal answer since we started asking it.

Now, I've also heard plenty of CTOs and IT directors privately say they have the means to prove it. But they don't want to. Because proving it would mean making decisions they don't want to make.

And I can tell you that in this period, I'm glad I'm no longer a CTO.

Deeper economic reasons

Still, as we've seen, productivity gains or not, can we really say all current layoffs are AI-related? Probably not.

A recently cited study shows that 59% of HR leaders admit that AI was used as a "cover" to justify budget cuts that were actually driven by:

• Over-hiring post-COVID
• Investor pressure to increase margins
• Internal strategy mistakes

But I think that would be overly reductive.

It's mostly the nth demonstration that we've entered a new era post-COVID. Between rising inflation, ongoing trade wars, endless debates about tariffs, skyrocketing energy costs, various conflicts that paralyze parts of international commerce—we're really in a recession.

AI is a facade to hide the rest. When Trump gets excited about his Stargate project (building datacenters), it's storytelling to hide the mess, even if it's true that AI is probably one of the drivers of the military sector in coming years and the US losing ground on it is probably making them nervous.

Yes, because the worst part is that even on AI, it's not certain the people leading the dance will be American.

Recent Chinese models like Ernie, DeepSeek, Qwen, and Kimi are largely on par with Gemini or ChatGPT, without necessarily costing the same. Kimi and DeepSeek reportedly cost 10% of their American counterparts during training phases.

Which, incidentally, is encouraging but mostly logical—technology improves, and we've never seen tech stay this inefficient over time. The computer that sent a rocket to the moon was less powerful than our smartphone despite consuming far more energy.

And for all these reasons, US companies are in full downsizing mode. Players in AI need to become more competitive. They're investing heavily while cutting payroll at the same time.

Other tech companies are following suit, further constrained by hyper-unfavorable economic conditions and in a context where saying you're laying off to increase productivity is more sellable than admitting reality.

A new era?

And us in the middle of all this? Well...

I'll be honest—I really wondered how to conclude this piece. I always try to end on a positive note, but the exercise is difficult here. I'll try anyway.

Is this the end of an era? Probably the era of unreasonable hyper-growth, which isn't so bad. This forced downsizing might help us get back to basics instead of just chasing vanity metrics (like headcount).

It's also a global economic shift and a US bloc that seems to be faltering. I want to see some positivity in thinking that Europe has cards to play. We're less affected than the US by the recent massive waves of layoffs. Probably because we have less insane payrolls than the US and more solid social models.

While American giants painfully refocus, it's our moment in Europe to catch up. These new technologies, more accessible and efficient, let us move faster with fewer resources. Maybe it's finally time to create real European tech alternatives—more sober and pragmatic.

On that note, you can go back to normal activities.

It got me thinking. I have an answer from my own experience, which I'll share with you. But I'm well aware my situation is peculiar. So I decided to dig deeper, and I realized something: the real question isn't whether you're getting faster. It's: what does that actually change for you?

Do you work less? More? Differently?

What's the impact in a large corporation? What about freelancers?

Essentially: ++if++ someone gains time, what's it actually worth to them?

Is That Time Gain Even Real?

First, let me be thorough and put things in perspective. A recent study from METR (Model Evaluation & Threat Research) shows that this time gain might not be as straightforward as we think.

The study found that experienced developers working on legacy codebases were actually 20% slower with AI, largely due to code review cycles.

Take it with a grain of salt—the sample size was only 16 people. And context matters: we're talking about expert developers working on large, complex codebases.

I won't dwell on this study because I can find others saying the opposite. But I thought it was intellectually honest to mention it, to balance the narrative and add some perspective.

The point isn't to assume that AI definitely makes us faster. I don't want to get into that debate. Instead, let's strip away the AI label entirely and just consider a hypothesis:

What if someone could produce code 20-30% faster? Or even 10x faster? What happens then? If software production becomes cheaper, what's the impact on the developer profession? What can you actually do with that gained time?

This isn't a silly hypothesis. The profession has changed radically since the days of physically wiring computers to program them. We've constantly improved productivity. And our successors probably won't work the way we do.

An Opportunity for Product Builders

I'm an outlier, so my answer doesn't apply to most people.

I work with one co-founder on a recently launched product. I have no productivity quotas, no salary pressure, no one to report to.

I control my own time. If I finish a task in an hour instead of a week, I can just stop working and do something else. I'm not obligated to pad my hours or hit some end-of-day checkpoint.

Of course, I still have pressure—the product needs to be good and adopted. I track new users monthly, revenue growth, and customer feedback via email. But for my situation, extra time is genuinely useful.

I can spend more time responding to emails thoughtfully. I can do deeper analysis of my market and user feedback.

In short, I see it as an opportunity.

Before, as a "technical founder," I spent all my time coding and lived heads-down, with no bandwidth to think strategically about the product long-term. Gaining time lets me rebalance.

I love coding. But coding was eating up brain cycles I needed for strategy.

That's no longer the case.

I can spend more time on the "why" instead of just the "how."

Time to Improve, Not Just Expand

Time has always been scarce in software and startups. When I gain time, I spend it on other product work: improving user documentation, strengthening test infrastructure to prevent future problems.

I tackle bugs I see in the logs, or UI quirks I'd noticed but pushed off indefinitely.

You know the feeling—that infinite Jira backlog filled with small improvement tickets. Those famous "we'll do it later" items that exist mostly to make us feel better, or to satisfy the support person who asked about them.

"Look, it's on our TODO list. Yeah, it'll take 15 years to get to, but it's there…"

That doesn't exist for me anymore. Small issues like that pile up by the dozens, and the product steadily improves.

Using the financial analogy of technical debt: once code costs less, you pay down the debt continuously, which reduces the interest burden.

Time to Learn

Since I spend less time coding, I've had much more time to think deeply about problems. And I've invested in education.

Before, time pressure forced shortcuts. Recently, I've documented and written about content moderation on platforms, dug into SSL certificate systems, explored proof-of-work captcha mechanisms, studied purchasing power parity.

And here's the surprising part: I've just stepped away from the keyboard.

Often in my typical day, I spend time away from the screen. I've improved my broth technique for ramen. I've done home repairs and started building furniture.

Paradoxically, that time helps me build better products.

Ever notice you solve complex problems in the shower?

Letting your mind wander is creative fuel.

It took me a while to accept it, but giving your brain rest—letting it incubate ideas and wander while you do something else—is excellent for problem-solving.

Of course, I know my situation is specific. I can't imagine starting a woodworking session in the middle of an open office surrounded by developers. But for me, gaining time on code means a holistic rebalancing of my days and, paradoxically, better-quality output.

Because it was never just about coding—it was also about thinking long-term, which is easier when you have time for it.

Clearly, though, it's different in a more traditional context. So I did some research on what others are saying.

Productivity and Burnout: The Real Cost

One of the first insights comes from a Harvard Business Review study. Increased productivity doesn't lead to reduced working hours—it leads to intensification.

Work becomes more intense for several reasons:

AI removes cognitive breaks. Since AI makes it faster to start a task, you lose the natural pause that exists at the beginning of each project when you're figuring out the approach.

AI blurs job boundaries. You feel capable of doing frontend, design, ops, backend, mobile. Your scope explodes for a single person.

Frequent gratification drives endless continuation. If you complete 10 tickets a day and each is quick, why not one more? One quick prompt before closing the laptop?

But this intensification comes at a real cost: fatigue, burnout, mistakes (because tired people miss things).

I found an article that compares AI to a vampire draining our energy.

The idea is simple: since AI handles all the simple, repetitive tasks that used to serve as cognitive breaks, we're left essentially doing high-level work and critical decisions.

But humans can't make critical decisions nonstop for 8 hours a day. It's exhausting.

That's why I personally either step away from my screen for part of the day or do more recreational activities at the computer: writing an article (which explains why I write more now), or learning something new. The article recommends finding a new balance.

I'm not sure how sincere the article is, but this seems to be GitHub's approach. They used the time gain not to drastically increase output but for other kinds of work: collaboration, reflection.

Doing More ≠ Doing Better

There's a hard limit to how many new features users can absorb daily anyway.

Just because you can ship 10x more features doesn't mean it benefits users.

This is Tesler's Law, also known as the Law of Conservation of Complexity. Every system has an irreducible level of complexity. If you reduce it in one place—say, developers moving faster—it appears elsewhere: users now have to adapt to software that evolves too quickly.

You also risk "feature fatigue," where software becomes bloated and overwhelming. Being forced to make choices is often healthy.

Essentially, speeding up benefits no one, and it's preferable that productivity gains show up as better-thought features or increased work on "invisible" quality.

When Productivity Creates Boredom

There's another scenario worth mentioning. Many people work at organizations where going faster changes absolutely nothing, because the company is fighting its own inertia more than any product challenge.

I worked at a large corporation once. I remember a project in 2003 where coding really wasn't the issue.

I'd come from a more dynamic job. I was used to a certain pace. Here, I was given a program to write. I finished it in 2 days. I went back to my manager. He said we'd discuss it again in 3 weeks. In a year, I shipped almost nothing. It was probably the worst year of my career.

Mornings brought people asking who wanted to attend meetings about various topics. I couldn't understand why everyone kept going.

But then I got it. It was to fill the day.

If I'd spent 1 hour instead of 2 days on my work, I'd just have been bored longer.

I knew burnout existed. But there I almost experienced burnout's opposite: complete stagnation. Eventually, I educated myself on the side in areas I cared about. I made that time count.

But I won't lie—I was incredibly relieved when that project ended.

The point: in some places, coding faster changes nothing. Coffee breaks just get longer.

Freelancers: From Time to Value

Now there's a population I have real questions about.

Let's say code costs collapse. What happens to people billing by the hour?

You could imagine a chunk of them won't exactly broadcast that they finished a job faster, since that means losing money.

Can that hold long-term, especially for a freelancer working on-site at the client, visible to everyone? In big companies, maybe. But it'll never work in an organization whose developers are also using the same tools to move faster.

That's where I wonder if fixed-price or outcome-based billing might become more attractive than hourly rates.

Usually, I advise against results-based contracts, especially for younger freelancers, because it's hard to contract properly, set boundaries, and accurately estimate work beforehand.

But if AI made development faster and more predictable, fixed-price work could regain appeal.

It wouldn't be about billing time. It would be about billing value.

I'd have no problem charging a fixed amount for valuable work, even if it took only 1-2 days.

I've worked 25 years to deliver that result in 2 days. Clients pay for your experience and your ability to use tools. Speed is irrelevant.

In a worst-case scenario, I might lower prices slightly, but the risk I take on also gets priced into a fixed contract.

That said, I'm not sure this logic holds forever. Competitors as good as me might take on more clients to offset losses, driving per-contract prices down.

I came across an article on this. It concluded that expert freelancers will survive, but demand will shrink. Especially since their clients will also start coding if the cost drops low enough.

But one takeaway stuck with me: AI won't replace the freelancer. The freelancer using AI will replace the one who doesn't. That's probably the most important lesson.

Conclusion

Again, the question wasn't whether AI makes us faster. The real question I wanted to explore was: what do you do with the time you gain?

The answer depends on your context.

If you're at an organization paralyzed by inertia, moving faster changes nothing—you'll just get bored sooner. If you're product-focused with the freedom to manage your own time, it's an incredible opportunity to step back and think strategically. If you're a freelancer, maybe it's time to renegotiate.

But here's the critical constraint: productivity only matters if it creates value. Shipping 10x more features might actually hurt your users. Gaining time is great, but it's only valuable if you know what to do with it.

Bottom line: there's no one-size-fits-all answer. But you might just gain the time needed to figure out what your answer is.

It’s conceptually similar to Hugo—it generates a static site (just a bunch of HTML files) that you can host for free on Cloudflare, GitHub Pages, or Bunny.net.

Before that, I had tried everything: WordPress, Joomla, Medium. I wanted to regain flexibility and customize my blog exactly how I wanted. But let’s be honest: I’m a developer, and I mainly wanted a new technical playground.

Fast forward to 2026, and I have to admit: using a static blog has become a major friction point for my writing. So, I decided to migrate again, this time to a managed platform: Writizzy, another product I’m building.

This move is a great opportunity to talk about several things:

• Dogfooding: Why you absolutely must use your own products.
• The harsh reality of Open Source: Why it’s harder than it looks.
• Product Satisfaction: The joy of building something people actually use.
• The future of my projects: Bloggrify, Writizzy, and Hakanai.io.

Bloggrify: When my blog was a technical playground

Bloggrify started as a love letter to the Nuxt ecosystem, specifically nuxt-content. Back when I migrated from WordPress, my criteria were simple:

• A simple templating language (Markdown).
• Extensibility (RSS feeds, sitemaps, etc.).
• Low cost.
• Low carbon footprint (static sites are incredibly efficient).

In 2022, it wasn't a "product" yet—just my personal blog code made public. It only became a full-fledged open-source project in 2024, with a dedicated site and a proper README to encourage contributions.

I wanted the product to be "opinionated." Nuxt-content does 90% of the heavy lifting, but it’s a generic tool. For a real blog, you still need to build the RSS feed, sitemap, robots.txt, comments, table of contents, share buttons, newsletter integration, analytics, and SEO.

That’s what Bloggrify is: a "starter pack" that comes with everything pre-configured. Think of it as Docus, but for blogs instead of documentation.

The Reality Check: GitHub Stars vs. Actual Users

I’m a numbers person. When I launch a project, I want to see usage. It might sound trivial, but considering the effort it takes to manage NPM releases (which is honestly a nightmare), handle versioning, and maintain themes, you expect a minimum return on investment.

Bloggrify reached 164 stars on GitHub and sits somewhere in the middle of the pack on Jamstack.org. That’s... okay, I guess.

But in reality, I have almost zero feedback on its actual usage. A few rare GitHub issues, one contributor who was active for a few weeks before vanishing, and then silence. I only know of one blog that used it before switching back to Hugo.

The experience has been bittersweet. Building in the dark is demotivating. However, it did lead me to launch two other side-products:

• broadcast.hakanai.io: A newsletter system for static blogs based on RSS feeds.
• pulse.hakanai.io: A specialized analytics tool for bloggers (not just generic web traffic).

Transitioning to SaaS

I launched Broadcast and Pulse in 2024 and 2025. They’re living a quiet life, but they aren't "exploding." My target audience is static bloggers—mostly developers. And as we know, developers are the hardest group to convince to pay for a service!

Still, I’m satisfied. These products taught me how to build a SaaS, handle subscriptions, and find my ideal tech stack. My own newsletters were sent via Broadcast (reaching about 150 subscribers), and I used Pulse to track which articles were actually being read.

The reality? These two tools generate about €100 in Monthly Recurring Revenue (MRR). Not enough to retire on, but a great learning experience.

And that brings us to Writizzy.

Enter Writizzy

With Bloggrify, I realized my writing workflow had become painful. Between maintaining the framework, jumping between spell-checkers, writing in Markdown, spinning up a local server to check for broken links, and waiting for build/deployment times... I was losing hours.

For my last article, someone pointed out a few typos. It took me 20 minutes between editing the file and seeing the fix live. Add to that the friction of managing images in an IDE and the recent Nuxt 4 / Nuxt-content updates which, while I love them, have made the dev experience slightly slower for simple blogging.

To be honest, I wasn't aware of that. I put up with these inconveniences and was still very happy to have “flexibility” in what I could do with my blog. I wasn't fully aware of this "friction" until I built Writizzy.

Writizzy is the synthesis of my blogging experience. It’s a mix of Substack, Ghost, and Medium, but built as a European alternative with four core pillars:

1. Sustainability: Focusing on reversibility and interoperability.
2. Discoverability.
3. Economic accessibility: Implementing Purchasing Power Parity (PPP).
4. Transparency.

I moved my English blog to Writizzy first (this one), with no intention of moving the french one. But I soon noticed I was writing much faster on the English site. The workflow was just... better. Copy-pasting images directly into the editor, instant previews, no server to launch. It was a joy.

The Future of My Projects

I hesitated for a long time before migrating eventuallycoding.com. I knew that by doing so, I was taking the risk of killing Bloggrify. If even I don't use it anymore, the project enters a danger zone. When you don’t use your own product daily—when you’re no longer obsessed with the problem it solves—it’s almost impossible to stay attached to it.

This is a symptom I see in so many "disposable" projects across the internet: built by people who flutter from one idea to the next without any real skin in the game. So yes, moving away from Bloggrify is a risk.

But I’ve come to terms with it. Today, I have almost zero evidence that Bloggrify is being used. Meanwhile, Writizzy already has 314 blogs and 11 paying users (€135 MRR) in just four months. Why stubbornly cling to Bloggrify? Ultimately, I believe I’m solving the same problem with Writizzy, but in a much better way.

I receive feedback emails and feature requests every single week. I get constant positive reinforcement from people actually using it. The product isn’t perfect, but it improves every day. It improves because real users are pushing me to refine the site, fix what’s broken, and add the features that absolutely need to be there.

And it also improves because I use it constantly. This is the massive benefit of dogfooding. Every day, I am confronted with my own software, so I know exactly what needs to change.

So yes, Bloggrify is moving to maintenance mode. I’m taking this opportunity to turn all templates into Open Source. Two of them were "premium," but it wouldn't make sense to keep them that way today. I tell myself I’ll still evolve it from time to time, but honestly, I wonder if I’m just lying to myself.

As for Hakanai.io, I’m definitely continuing. The problem it solves still fascinates me. I get great feedback, especially on Broadcast. Pulse, however, suffers from being misunderstood. It’s a "blog analytics" product, and people don't really grasp what that entails—SEO advice, outlier detection, evergreen content tracking. I’m not great at marketing, so it mostly flies under the radar except for the readers of this blog who took the time to test it. But I’m motivated to keep them alive.

As for Writizzy, there is no doubt. The product is incredibly exciting to build. The stakes are high: building a platform for expression that exists outside the US-centric giants. The traction is there, and the numbers follow (+45% MoM user growth).

Welcome to this blog, now officially on Writizzy. As a reader, you can already test several things:

• The comments section.
• The newsletter subscription (if you haven’t already).

The Discover feed to read other articles from Writizzy bloggers. We’ve handpicked a few to start with, and this feed will become even more customizable in the future.

Welcome home.

I don't remember the details anymore, but with hindsight and probably lots of exaggeration, I'd say it was like Gather but 15 years ahead of its time.

The application seemed to work well and the company was lining up meetings with major corporations that seemed super interested in rolling it out across their enterprise. We're talking about big banks, major energy suppliers, really serious companies.

Except it dragged on. A month. A quarter. A year. Then two. And eventually the company died waiting for an actual signature and, incidentally, some cash.

My friend unfortunately ran into the infamous B2BigB syndrome, this curse (a French one?) that tends to kill a lot of companies every year.

So if you're starting a company today or thinking about it, I invite you to think twice before prioritizing this segment, and that's what we're going to talk about today.

B2BigB

First, I need to define this acronym. In the business world, we tend to segment companies based on the customers they target:

• B2C (Business to Consumer), that's the general public.
• B2B (Business to Business), that's selling to companies.

For example, Netflix is B2C and Jira is B2B.

Among all this you have plenty of nuances. Microsoft sells in both B2C and B2B, for example. You have C2C platforms (exchanges between individuals).

But let's keep it simple and just talk about B2C and B2B.

Except "B" is broad. Between a 5-person company and a 40,000-person conglomerate, the way you sell to the two is very different. And in this category, there's a category of death: large corporations.

It's hard to really say when a large corporation begins, but you recognize them easily. A large corporation starts when a decision requires a ton of meetings, a quarter, a steering committee and board approval or a purchasing department sign-off.

In practice, you can even have 500-person companies that behave this way, even if it's more common starting at 1,000. But in any case, it gets worse with size. A quarter can become a year, or even 2, or even 5 (and I swear I've seen sales cycles that long).

Anyway, that's what I call the BigB (the big B's).

The big advantage of BigB's is, in theory, the ability to buy expensive because we're talking about deployment across an entire large corporation, so volumes that make most startups' eyes light up.

Except that, it's often a mirage. The moment you start looking at costs and margins, not to mention all the associated risks.

Gigantic Costs, Thin Margins

Working with a large corporation is often synonymous with complexity, and that complexity is financed by specialists.

You have to respond to costly processes (a 200-page security questionnaire, legal questionnaires, framework contracts, ISO certification this and that) that often requires a lot of specialists (lawyers, security experts, finance people, etc.). And that's just to get through the first step of the sales cycle.

To sell to a large corporation, you need to be prepared to spend a fortune.

By the way, it's worth noting that this doesn't prevent these large corporations from regularly appearing on the monthly data breach list. Because no, churning out Excel questionnaires is not synonymous with security quality.

After that, you're quickly going to fall into the spiral of quarterly meetings with a bunch of people you'll only see once in your life, some of whom will take advantage of their temporary power to take out their frustrations and pet peeves on you. And since you'll be in a weak position, well...

This time is time not spent on the product. Of course it's normal to spend time on sales, but we're talking about quarterly meetings to prepare, with McKinsey-style PowerPoints (you sometimes even see scale-ups calling in consulting firms to fill out these documents) that will require weeks of preparation.

Again, to sell to a large corporation, you need to already be prepared to spend a fortune and wait ages.

But let's imagine you've finally got the green light to deploy in a large corporation. The contract is signed. Now it's up to you to figure out adoption.

Actually, this is the beginning of a second nightmare.

A year has passed since the beginning of the sales cycle. All your previous contacts are gone. They might have been contractors who left the company. Or executives who got transferred to other branches of the group. And now you have to find the people capable of helping you deploy your software because without a doubt your revenue depends on how much the software is actually used. No deployment, no money.

So you're going to need a dedicated team of salespeople capable of navigating complex bureaucracy to find the right contacts, and maybe even a dedicated implementation team. Your costs are going to explode and you still won't have made anything at this stage.

With a bit of luck, and because you were smart enough to get a payment at signature, you'll eventually issue your first invoice. That will be paid 8 months later, end of month. The first 3 months having caused countless incidents because a purchase order needed to be signed and you had to go through 3 different departments for that. Bad luck, your cash flow is starting to choke.

You reach the end of the first year and then the purchasing department will come see you to renegotiate the contract, knowing full well that, in theory, they're your biggest client so it would be natural to do them a favor.

In short, 2 years later, you've spent a fortune, your cash flow is negative, and your margin has melted like snow during a World Cup ski race in Saudi Arabia.

OK, let's say I'm exaggerating and that despite everything, this contract allowed you to instead cross a threshold, to have an impressive signature to put forward and life continues for your startup/scaleup.

Actually, you don't know it yet, but you've invited a Trojan horse into your company.

The Loss of Innovation

Working with a large corporation means accepting the complexity inherent to that business. If it took you 2 years to sign a contract with them, imagine that everything else takes the same time.

Your product has to evolve to fit their way of working. You'll be asked for 12-level approval workflows, software integrations with ERPs, broken enterprise SSO, integrations with legacy systems from the 90s. And every company has its own internal jargon that you'll be asked to force into your software. You'll invoice in units of work, have a "purchasing" role in your RBAC schemas (authorization systems), in short, in reality, you're going to develop an extension of your first client's IT infrastructure with all its constraints, its complexity, its slow onboarding, and its costs.

And when you have a client representing 80% of your revenue (and even from 20% onwards it really starts to matter), you can hardly say no. So your roadmap is regularly hijacked by salespeople dedicated to this client, and globally a product that drifts away from the mass market.

And that's normal, hey, I'm not throwing stones at that team. If you've dedicated people to a client, it's normal they try to influence how you build the product and even if the requests are absurd. Because that team doesn't have the perspective needed to judge.

And when the roadmap is regularly sidetracked, it's also a huge amount of customization debt that will end up slowing the entire product. This big client may have allowed you to double your headcount. But 3/4 of the company will end up working for them, and will develop their own software culture, less UX sense, less sensitivity to product performance (no point working on acquisition or conversion, for example).

All enterprise software has terrible UX, because first, that's not what drives sales, and second, because after burning money in the sales process, certification and onboarding, you have to make savings somewhere, often on the product which is no longer really central to the relationship with this client. They'll try to reassure you by saying no, it's important, but actually, the product at that point has become a cost center that needs to be optimized to not lose more margin. Margin eaten by the consulting firm that helped you determine your deployment strategy and pricing...

But even when you "improve" your product for this client, you're going to continuously degrade it for all the others you thought you'd attract next by showcasing this win on your beautiful landing page. Because again, you're going to impose their complexity on all the other companies that could have been interested in your services.

I'm obviously painting a dark picture. And there are companies that specialized FROM DAY 1 in large corporations, that tailored their commercial offering taking into account all the associated costs. Deployments are priced at 100k, contracts impose minimum usage, everything was framed from the start because the strategy was always to expand exclusively here.

But for all the companies that think "just" doing a BigB to get a validation badge, but who actually target the entire SMB market and are looking for volume. It's rarely a good plan.

The Alternatives

At the beginning I said: "this curse (a French one?)". Why do I say it's a great French curse? Actually it's probably a magnifying glass effect and I'd certainly see the same thing in every country.

But every year, I see companies that die after quarters of waiting for that famous contract with a large corporation (just yesterday I was talking to someone who told me the exact same story). So I think there's something a bit different about us. We like to be different.

Partly, I get the sense it's related to the size of our SMB market which is less important than in Germany (the German Mittelstand seems bigger). We go faster from SMB to large corporations.

Obviously, then, in terms of credibility, it's easier to sell a product once you have the logo of a large corporation than a bunch of logos of unknown companies.

What's certain is that culturally, there's the CAC 40 and everything else. The CAC 40 has been basically the same companies for 30 or 40 years. By contrast, look at the S&P 500, in 1990 it was Exxon, GE, Philip Morris, IBM. They've all given way to Apple, Nvidia, Amazon, Google.

In France, the large corporations in the CAC are structurally stable and dominant, which makes them all the more attractive as clients for startups. They have budgets, longevity, legitimacy. But these same large corporations aren't springboards to a global market — they're markets closed in on themselves.

And conversely the SMB market can work. If I look at Pennylane, Qonto, Indy, Payfit, Spendesk, Livestorm, it's precisely by targeting this market that they've managed to go far.

By contrast, I have real questions about the strategy of a company like Mistral which seems to position itself only on large corporations (on-premise deployment, Azure partnerships, etc.) and seems to be neglecting the mass market.

I hope it won't be the future DailyMotion, which favored big media and telecom operators while missing the opportunity to become the B2C media platform that YouTube managed to become.

You'll have gathered, if you're starting a company today, I'd tend to advise you to not see "B2B" as a single big playground. I'd tend to tell you to avoid B2BigB which is often destructive for startups and often ends up leading to a dead end.

It's still possible, but you need to be armed for it. And if that's your choice, I'll only say one thing. Good luck :)

Targeting large corporations (and the public sector) obviously gives you access to larger markets. But I'd tend to recommend tackling that step later, when the company is already solid.

When DJI (Chinese drones) attacked the professional market, they already had a huge foothold in the B2C market. They came with an expertise and know-how that allowed them to be sovereign over their decisions.

Now if you're tempted anyway, the recipe for having a chance is above all a question of seniority of leadership: you need to know how to say no firmly, you need to stop chasing every rabbit that passes by when you see a so-called "low hanging fruit", the expression that has replaced "quick win" as one of my most hated expressions.

There's no such thing as effortless gain. Everything has a cost, even when it's hidden.

And you need a good financial and reputational foundation to impose these conditions, hence the advice to already have a good base on the other segments. It's easier to say no when a client represents 2% than when they represent 20%.

One strategy I've seen work several times is to create software with great UX, get adopted by the teams, then go see the purchasing departments of the companies in question and put the usage figures under their nose: "See, you already have 300 people using it, wouldn't you like to set up a framework contract and better understand usage at your company?"

That's interesting because you've created a product whose adoption happened from the teams, you didn't modify your roadmap, and you're in a strong position with procurement to improve your presence without being pressured on everything else. In short, make a good product, track usage, wait until you have enough footprint, and then go negotiate.

Anthropic (Claude Code) by first targeting individual developers (indie hackers, side projects) and small teams was pushed to constantly improve its product which became number 1 in its category (at the time of writing, this passage might age poorly :)). Today, they're selling enterprise licenses.

Good companies are able to do volume and then move up the chain, small companies then large companies. I've rarely (never?) seen the reverse. When you do large corporations, you don't know how to come back to the rest of the segments.

I think I've asked myself this question three or four times over the past 25 years, but this is the first time the reasons pushing me to do it are this compelling, and the tools available are this mature.

So why not give it a shot?

But first, let's talk about the reasons. Why switch?

You probably haven't missed it, but the geopolitical situation is tense, and our tech dependence on the US is becoming genuinely dangerous. Windows is the ultimate Trojan horse, providing access to thousands (billions?) of PCs—both personal and professional—and it's getting harder to ignore.

Between the backdoor suspicions in 1999 with the _NSAKEY affair, renewed suspicions in 2017 with DoublePulsar, and the confirmed story about Bitlocker encryption keys being handed to the NSA, it would be incredibly naive to think we're safe.

Beyond that, the Windows 11 migration has forced countless companies to replace hardware that was still working perfectly fine.

Honestly, the first reason was enough. But since we're being thorough...

Now, how do I actually do this?

My Constraints

I want to switch, sure, but not at any cost—so let me give you some context.

Like anyone who works in tech, I regularly get asked to "take a quick look" at someone's printer that stopped working, a phone that won't boot, or some finicky word processor.

Here's a scoop: I don't know how to do that. It's not my job. I know, it's wild—I spend all day on a computer, but that doesn't mean I can fix it or anything that looks like an assembly of electronic components. Worse, I hate doing it.

Fine, maybe I'm exaggerating. With enough effort and online documentation, I can sort of solve some problems. But again, I hate it.

The truth is, I don't want to spend time tinkering with everyday tools, any more than I want to take apart my fridge or my car.

Okay, the car example is probably bad—I genuinely know nothing about cars. And sure, when I was younger, I found it fun to mess with my autoexec.bat and config.sys to get games running in high memory. But those days are over. Gaming should be a hobby, not a technical challenge.

So you get it: I want to switch to something simple that doesn't require me to become an expert in obscure command lines just to make things work.

Second useful clarification: I've been using Unix/Linux professionally since 1997. I'd already installed Mandrake in '99 as a dual boot, and I've had work machines running Ubuntu and Debian. So I'm not starting from zero, and I know that for professional use, I'd have no trouble adapting to Linux.

But for personal use, I need to do video editing (I use Filmora) and I like playing video games—so that's going to factor in.

And apparently, Linux can now do all of that.

Apparently...

Testing Without Breaking Everything (Almost)

The idea wasn't to buy a new computer—that would be pretty dumb since my current PC is still great. I bought it in 2018; it has 32GB of RAM, an AMD Ryzen 7 processor, a GeForce GTX 1060, and runs games like Overwatch 2 or Baldur's Gate 3 without any issues.

The idea also wasn't to reinstall over Windows and risk being PC-less for days or weeks.

So I bought a new 1TB SSD to enable dual boot and test different OSes. Dual boot isn't a long-term solution since I want to get rid of Windows, and switching between systems is a pain anyway. But it's perfect for testing. Plus, going from 1TB to 2TB was becoming necessary because video editing eats up disk space fast.

Of course, since I have clumsy fingers and my eyesight is declining with age, I managed the impressive feat of stripping the screw thread that holds the NVMe drive to the motherboard. I really thought I'd be giving up much sooner than planned. But after a quick chat with Gemini, I discovered that PCI-to-NVMe adapters exist, letting you plug SSD drives into a PCI slot.

So, another purchase, a few days, and €20 less later, I was finally able to plug in that damn drive.

Choosing a Distribution

The first step is picking a Linux distribution, downloading an ISO (~4GB), flashing a USB drive with BalenaEtcher, and running the installation.

Remember these steps—they'll come up several times...

My first choice was Bazzite, which is gaming-oriented, but I quickly soured on it when I saw that the co-founders were airing their dirty laundry on the internet—never a great sign. We only allow that kind of drama for Linus Torvalds.

So I installed Pop!_OS next, which is supposed to be user-friendly and gaming-compatible.

Pretty quickly, the disappointments piled up. My video editing software, Filmora, isn't available on Linux. Neither is Proton Drive.

For Proton, there seems to be a version in development, so I can wait.

As for Filmora, it means I'll have to learn DaVinci Resolve. It's frustrating because I have my workflow down in Filmora, but I wouldn't be losing out by learning DaVinci—it's an excellent editing tool. Frustrating, but doable.

However, I also ran into a lot of issues with slowdowns and system freezes. I became very familiar with xkill (to force-close windows), especially while installing Lutris to run Overwatch.

Yes, I'm using Overwatch as my benchmark for testing whether this migration is feasible. It's THE game I play the most. Don't judge me.

After a long stretch of frustration with Lutris that never worked, I eventually switched to Steam because Gemini told me Overwatch is now playable on Steam. Installing Steam had to be done via command line since the default installer didn't work (sigh). I then launched the Overwatch download (60GB...) and went to do something else. The computer went to sleep and wouldn't wake up afterward... Apparently, computers can have trouble waking up too. So I had to reboot—and lost the game download...

Thrilled (not) and fresh as a daisy (also not), I disabled automatic sleep mode and restarted the download. After several hours, I finally launched the game and... it didn't work. The game started, it seemed smooth, but my character kept staring at the ground as if my mouse wasn't being recognized.

We're talking hours of struggling, lots of terminal commands when I explicitly didn't want an OS that forces me to do that. I'll admit the urge to give up was really strong.

And then someone told me: "Maybe you should try a less exotic distro."

Okay. Fair point. Can't give up that easily.

And besides, at this point, I should mention something. One of my motivations was to get away from US tech. But choosing a Linux distro—sure, it's open source, but there are companies behind these distributions. Both Bazzite and Pop!_OS are US-based, so I wasn't really meeting my goal anyway.

So the next day I went with Linux Mint (Ireland). Re-downloaded an ISO, re-flashed a USB drive, re-ran the installation. Joy.

Verdict: Mint seemed more stable—no freezes, no sleep/wake issues—but the interface felt dated, like Windows from the 2000s. Someone quickly suggested I try Zorin OS (also Ireland). No problem, I'm getting good at flashing USB drives by now.

So I re-downloaded an ISO, re-flashed a USB drive, re-ran the installation.

And I have to admit, the result is pretty nice. The OS is pleasant to use, the interface stays close to Windows, so the learning curve is gentle. But this time I knew the main test was getting Overwatch to work to fully validate the migration.

So I installed Steam directly through the built-in app store. Launched the Overwatch download (still 60GB, hasn't changed) and waited.

After several hours, finally, I could start the game and... another failure. The game was completely choppy, pixelated everywhere, the menus barely responded. Time for xkill again...

But this time, I wasn't giving up.

So I called in reinforcements: Gemini.

First, we tried modifying the game's launch options to force Proton, but no luck. I'm acting like I know what Proton is—I really don't. I discovered Proton, Wine, and Lutris all on the same day, and I'm definitely not going to explain what each one does or why Proton over Wine. No idea, and I don't really care.

After several terminal commands, we concluded that the game wasn't using my Nvidia card even though it was correctly installed, because Flatpak was blocking it. Was this diagnosis correct? No clue. But I installed Flatseal to manage Steam's permissions.

Did it work? Not at all. Gemini then suggested reinstalling Steam not via Flathub, but using the native version directly (with a .deb file).

At this point, I wasn't going to balk at yet another installation—and I was pretty lost anyway. I didn't even know what Flathub was until last week.

So I reinstalled Steam, re-downloaded the game (yes, again), reinstalled Proton, changed the Proton version twice because the experimental version was incompatible with my setup, changed the launch options three times under Gemini's guidance, and after several hours, the game launched!

Well, almost. It started compiling Vulkan shaders.

Apparently, this precompiles them to avoid doing it during gameplay. I have very limited knowledge of what a shader is, and I don't know why this is necessary on Linux, but hey, for 10 more minutes, what's the difference at this point...

I quickly jumped into a practice match, tested a few characters, and had a weird feeling. The game wasn't smooth, and when I displayed the FPS counter, I saw I was capped at 60 FPS with occasional dips to 50. And trust me, you feel 60 FPS. There are little glitches here and there, a lack of fluidity. It's playable. You can live with it. But it's not at all pleasant, especially when you've experienced the game at 175 FPS before, on the same machine.

And you know what Gemini suggested? Try Lutris.

So I installed Lutris, re-downloaded Battle.net like I did on Pop!_OS, suffered through the same slowdowns and stuttering—which helped me realize it wasn't Pop!_OS's fault, but rather Lutris's—launched Battle.net only to hit the exact same error I'd had on Pop!_OS, and reached the same conclusion: Lutris is hell.

Gemini then said, "If Lutris isn't cooperating, I recommend Bottles. It's an ultra-modern app available in the Zorin store that's become the go-to for installing Battle.net."

But at that point, I'll be honest. I gave up...

Alright, time for a recap.

Takeaways

Well, I wouldn't call it a failure, but it didn't work, as they say.

Overall, the Linux experience for professional software development is excellent—but I already knew that; that's clearly not the barrier. Zorin OS does a great job for a Windows user like me; you find your way around quickly.

For other professions? Hard to say. The risk is always having one or two apps that aren't available on Linux. The OS itself is now truly capable, but if software vendors don't publish their apps for Linux, it'll always be a barrier. This is the case for CAD software (AutoCAD, Revit, SolidWorks), the Adobe suite for creatives, and several pro tools for video editors (Adobe Premiere, After Effects).

And that makes the option questionable for broader adoption. Again, Linux isn't the problem here—the software vendors are. If they don't see Linux as a mainstream platform, it'll never become mainstream.

And speaking of the mainstream, some of them are gamers—and I can't honestly say Linux is ready for them. I know some of you are going to push back on this. I have plenty of friends who've guaranteed they can game on Linux, and I believe them. But it would be hypocritical of me to write that it's as easy as on Windows.

Obviously, I'm exaggerating. For someone who just does basic office work at home, with a pre-configured computer, it should be fine. And it's true that all my peripherals were detected without any issues—printer, RØDE microphone, dual monitors, etc. So yes, I'm being a bit unfair.

But as soon as gaming comes into the picture, I struggle to say it's okay. I spent hours typing obscure commands into a terminal. I tweaked launch options in Steam and Nvidia settings I'd never seen in my life, and in the end, it still doesn't work.

You can absolutely tell me I'm not skilled, that the problem is between the chair and the keyboard. I readily admit all of that. I didn't even know most of the software I dealt with these past few days (Flatpak, Wine, Proton, etc.). But I shouldn't need to be skilled to play games on a PC. And clearly, I'm not the only one this happens to—I spent hours searching Reddit and saw plenty of people with similar issues.

I wanted to migrate. I spent hours on this. I read dozens of forum posts. Don't tell me I'm being disingenuous. I'm not patient, that's true, but I tried.

And the worst part is that I'm frustrated. Because I really wanted to switch. I'm willing to learn DaVinci to replace Filmora. I'm willing to change my work habits, relearn a new OS. But damn, I want to be able to play games :)

So for now, I'm keeping the dual boot, but it's not a solution. I'm still somewhere between stage 3 (denial) and stage 4 (anger) of grief, hoping I don't reach acceptance and resignation too quickly...

I'll keep looking for solutions online, but clearly, this is becoming expert-level work, and it wasn't supposed to be. Things aren't looking good for this 2026 goal.

Since 2020, we've moved from autocomplete to industrialization:

• 2021 with Github Copilot: individual use, essentially focused on advanced autocomplete.
• then browser-based use for more complex tasks, requiring multiple back-and-forths and copy-pasting
• 2025 with Claude Code, Windsurf and Cursor: use on the developer's workstation through code assistants

Gradually moving from a few lines produced by autocomplete to applications coded over 90% by AI assistants, dev teams must face the obligation to industrialize this practice at the risk of major disappointments.

And more than that, as soon as the developer's job changes, it's actually the entire development team that must evolve with it.

It's no longer just a simple tooling issue, but an industrialization issue at the team scale, just as automated testing frameworks changed how software was created in the early 2000s.

(We obviously tested before the 2000s, but how we thought about automating these tests through xUnit frameworks, the advent of software factories (CI/CD), etc., is more recent)

In this article, we'll explore how dev teams have adapted through testimonials from several tech companies that participated in the writing by addressing:

• Context Driven Engineering, the new paradigm
• Spec/Plan/Act: the reference workflow
• The AI Rules ecosystem
• Governance and industrialization
• Human challenges

Context driven engineering

While the term vibe coding became popular in early 2025, we now more readily speak of Context driven engineering or agentic engineering. The idea is no longer to give a prompt, but to provide complete context including the intention AND constraints (coding guidelines, etc.).

Context Driven Engineering aims to reduce the non-deterministic part of the process and ensure the quality of what is produced.

With Context Driven Engineering, while specs haven't always been well regarded, they become a first-class citizen again and become mandatory before code.

Separate your process into two PRs:

• The PR with the plan.
• The PR with the implementation. The main reason is that it mimics the classical research-design-implement loop. The first part (the plan) is the RFC. Your reviewers know where they can focus their attention at this stage: the architecture, the technical choices, and naturally their tradeoffs. It's easier to use an eraser on the drawing board, than a sledgehammer at the construction site

Source: Charles-Axel Dein (ex CTO Octopize and ex VP Engineering at Gens de confiance)

We find this same logic here at Clever Cloud:

Here is the paradox: when code becomes cheap, design becomes more valuable. Not less. You can now afford to spend time on architecture, discuss tradeoffs, commit to an approach before writing a single line of code. Specs are coming back, and the judgment to write good ones still requires years of building systems.

Source: Pierre Zemb (Staff Engineer at Clever Cloud)

or at Google

One common mistake is diving straight into code generation with a vague prompt. In my workflow, and in many others', the first step is brainstorming a detailed specification with the AI, then outlining a step-by-step plan, before writing any actual code.

Source: Addy Osmani (Director on Google Cloud AI)

In short, we now find this method everywhere:

• spec
• plan
• act

Spec/Plan/Act

Spec: The specification brings together use cases: the intentions expressed by the development team. It can be called RFC (request for change), ADR (architecture decision record), or PRD (Product requirement document) depending on contexts and companies.

This is the basic document to start development with an AI. The spec is usually reviewed by product experts, devs or not.

AI use is not uncommon at this stage either (see later in the article).

But context is not limited to that. To limit unfortunate AI initiatives, you also need to provide it with constraints, development standards, tools to use, docs to follow. We'll see this point later.

Plan: The implementation plan lists all the steps to implement the specification. This list must be exhaustive, each step must be achievable by an agent autonomously with the necessary and sufficient context. This is usually reviewed by seniors (architect, staff, tech lead, etc., depending on companies).

Act: This is the implementation step and can be distributed to agentic sessions.

In many teams, this session can be done according to two methods:

• copilot/pair programming mode with validation of each modification one by one
• agent mode, where the developer gives the intention then verifies the result (we'll see how later)

We of course find variations, such as at Ilek which details the Act part more:

We are in the first phase of industrialization which is adoption. The goal is that by the end of the quarter all devs rely on this framework and that the use of prompts/agents is a reflex. So we're aiming for 100% adoption by the end of March. Our workflow starts from the need and breaks down into several steps that aim to challenge devs in the thinking phases until validation of the produced code. Here's the list of steps we follow:

1- elaborate (challenges the need and questions edge cases, technical choices, architecture, etc.)

2- plan (proposes a technical breakdown, this plan is provided as output in a Markdown file)

3- implement (Agents will carry out the plan steps)

4- assert (an agent will validate that the final result meets expectations, lint, test, guideline)

5- review (agents will do a technical and functional review)

6- learn (context update)

7- push (MR creation on gitlab) This whole process is done locally and piloted by a developer.

Cédric Gérard (Ilek)

While this 3-phase method seems to be consensus, we see quite a few experiments to frame and strengthen these practices, particularly with two tools that come up regularly in discussions: Bmad and SpeckKit.

Having tested both, we can quite easily end up with somewhat verbose over-documentation and a slowdown in the dev cycle.

I have the intuition that we need to avoid digitally reproducing human processes that were already shaky. Do we really need all the roles proposed by BMAD for example? I felt like I was doing SaFe in solo mode and it wasn't a good experience :)

What is certain is that if the spec becomes queen again, the spec necessary for an AI must be simple, unambiguous. Verbosity can harm the effectiveness of code assistants.

The AI Rules ecosystem

While agentic mode seems to be taking over copilot mode, this comes with additional constraints to ensure quality. We absolutely want to ensure:

• that the implementation respects the spec
• that the produced code respects the team's standards
• that the code uses the right versions of the project's libraries

To ensure the quality produced, teams provide the necessary context to inform the code assistant of the constraints to respect. Paradoxically, despite vibe coding's bad reputation and its use previously reserved for prototypes, Context Driven Engineering puts the usual good engineering practices (test harness, linters, etc.) back in the spotlight. Without them, it becomes impossible to ensure code and architecture quality.

In addition to all the classic good practices, most agent systems come with their own concepts: the general context file (agents.md), skills, MCP servers, agents.

agents.md

A code assistant will read several files in addition to the spec you provide it. Each code assistant offers its own file: Claude.md for Claude, .cursorrules for Cursor, windsurfrules for Windsurf, etc.

There is an attempt at harmonization via agents.md but the idea is always broadly the same: a sort of README for AI. This README can be used hierarchically, we can indeed have a file at the root, then a file per directory where it's relevant.

| agents.md
| 
` application 1
  | 
  ` agents.md

This file contains instructions to follow systematically, example:

- the interface is in English mandatorily
- in the nuxt backend (`server/api/`), we ALWAYS use the generated OpenAPI client (`~~/server/utils/openapi`), never direct `$fetch`

and can reference other files.

If you have to work in kotlin, always load the rules/kotlin.md file

Having multiple files allows each agent to work with reduced context, which improves the efficiency of the agent in question (not to mention savings on costs).

Skills, agents, MCP servers

Depending on the tools used, we find several notions that each have different uses.

A skill explains to an AI agent how to perform a type of operation.

For example, we can give it the commands to use to call certain code generation or static verification tools.

An agent can be involved to take charge of a specific task. We can for example have an agent dedicated to external documentation with instructions regarding the tone to adopt, the desired organization, etc.

MCP servers allow enriching the AI agent's toolbox. This can be direct access to documentation (for example the Nuxt doc), or even tools to consult test account info like Stripe's MCP.

It's still too early to say, but we could see the appearance of a notion of technical debt linked to the stacking of these tools and it's likely that we'll see refactoring and testing techniques emerge in the future.

Governance and industrialization

With the appearance of these new tools comes a question: how to standardize practice and benefit from everyone's good practices?

As Benjamin Levêque (Brevo) says:

The idea is: instead of everyone struggling with their own prompts in their corner, we pool our discoveries so everyone benefits.

Corporate Marketplaces

One of the first answers for pooling relies on the notion of corporate marketplace:

At Brevo, we just launched an internal marketplace with skills and agents. It allows us to standardize code generated via AI (with Claude Code), while respecting standards defined by "experts" in each domain (language, tech, etc.). The 3 components in claude code: We transform our successes into Skills (reusable instructions), Subagents (specialized AIs) and Patterns (our best architectures). Don't reinvent the wheel: We move from "feeling-based" use to a systematic method.

Benjamin Levêque and Maxence Bourquin (Brevo)

At Manomano we also initiated a repository to transpose our guidelines and ADRs into a machine-friendly format. We then create agents and skills that we install in claude code / opencode. We have an internal machine bootstrap tool, we added this repo to it which means all the company's tech people are equipped. It's then up to each person to reference the rules or skills that are relevant depending on the services. We have integration-type skills (using our internal IaC to add X or Y), others that are practices (doing code review: how to do react at Manomano) and commands that cover more orchestrations (tech refinement, feature implementation with review). We also observe that it's difficult to standardize MCP installations for everyone, which is a shame when we see the impact of some on the quality of what we can produce (Serena was mentioned and I'll add sequential-thinking). We're at the point where we're wondering how to guarantee an iso env for all devs, or how to make it consistent for everyone

Vincent AUBRUN (Manomano)

At Malt, we also started pooling commands / skills / AGENTS.MD / CLAUDE.MD. Classically, the goal of initial versions is to share a certain amount of knowledge that allows the agent not to start from scratch. Proposals (via MR typically) are reviewed within guilds (backend / frontend / ai). Note that at the engineering scale we're still searching a lot. It's particularly complicated to know if a shared element is really useful to the greatest number.

Guillaume Darmont (Malt)

Note that there are public marketplaces, we can mention:

• the Claude marketplace
• a marketplace by vercel

Be careful however, it's mandatory to review everything you install…

Among deployment methods, many have favored custom tools, but François Descamps from Axa cites us another solution:

For sharing primitives, we're exploring APM (agent package manager) by Daniel Meppiel. I really like how it works, it's quite easy to use and is used for the dependency management part like NPM.

CI/CD Integration

Despite all the instructions provided, it regularly happens that some are ignored. It also happens that instructions are ambiguous and misinterpreted. This is where teams necessarily implement tools to frame AIs:

• linting
• test harness
• code reviews

While the human eye remains mandatory for all participants questioned, these tools themselves can partially rely on AIs.
AIs can indeed write tests. The human then verifies the relevance of the proposed tests.
Several teams have also created agents specialized in review with very specific scopes: security, performance, etc.
Others use automated tools, some directly connected to CI (or to Github).

(I'm not citing them but you can easily find them).

Related to this notion of CI/CD, a question that often comes up:

It's also very difficult to know if an "improvement", i.e. modification in the CLAUDE.MD file for example, really is one. Will the quality of responses really be better after the modification?

Guillaume Darmont (Malt)

Can I evaluate a model? If I change my guidelines, does the AI still generate code that passes my security and performance criteria? Can we treat prompt/context like code (Unit testing of prompts).

To this Julien Tanay (Doctolib) tells us:

About the question "does this change on the skill make it better or worse", we're going to start looking at promptfoo and brainstrust (used in prod for product AI with us) to do eval in CI.(...) For example with promptfoo, you'll verify, in a PR, that for the 10 variants of a prompt "(...) setup my env" the env-setup skill is indeed triggered, and that the output is correct. You can verify the skill call programmatically, and the output either via "human as a judge", or rather "LLM as a judge" in the context of a CI

All discussions seem to indicate that the subject is still in research, but that there are already work tracks.

Costs

We had a main KPI which was to obtain 100% adoption for these tools in one quarter (...) At the beginning our main KPI was adoption, not cost.

Julien Tanay (Staff engineer at Doctolib)

Cost indeed often comes second. The classic pattern is adoption, then optimization.

To control costs, there's on one hand session optimization, which involves

• keeping session windows short, having broken down work into small independent steps.
• using the /compact command to keep only the necessary context (or flushing this context into a file to start a new session)

For example we find these tips proposed by Alexandre Balmes on Linkedin.

This cost control can be centralized with enterprise licenses.
This switch between individual key and enterprise key is sometimes part of the adoption procedure:

We have a progressive strategy on costs. We provide an api key for newcomers, to track their usage and pay as close to consumption as possible. Beyond a threshold we switch them to Anthropic enterprise licenses as we estimate it's more interesting for daily usage.

Vincent Aubrun (ManoMano)

On the monthly cost per developer, the various discussions allow us to identify 3 categories:

The vast majority oscillates between category 1 and 2.

Documentation, positive side effect of AI

When we talk about governance, documentation having become the new programming language, it becomes a first-class citizen again.

We find it in markdown specs present on the project, ADRs/RFCs, etc. These docs are now maintained at the same time as code is produced.

So we declared that markdown was the source of truth. Confluence in shambles :)

Julien Tanay (Doctolib)

It's no longer a simple micro event in the product dev cycle, managed because it must be and put away in the closet. The most mature teams now evolve the doc to evolve the code, which avoids the famous syndrome of piles of obsolete company documents lying around on a shared drive.

This has many advantages, it can be used by specialized agents for writing user doc (end user doc), or be used in a RAG to serve as a knowledge base, for customer support, onboarding newcomers, etc.

The integration of this framework impacts the way we manage incidents. It offers the possibility to debug our services with specialized agents that can rely on logs for example. It's possible to query the code and the memory bank which acts as living documentation.

Cédric Gérard (Ilek)

Intellectual Property

One of the major subjects that comes up is obviously intellectual property. It's no longer about making simple copy-pastes in a browser with chosen context, but giving access to the entire codebase.

This is one of the great motivations for switching to enterprise licenses which contain contractual clauses like "zero data training", or even "zero data retention".

In 2026 we should also see the appearance of the AI act and ISO 42001 certification to audit how data is collected and processed.

In enterprise usage we also note setups via partnerships like the one between Google and Anthropic:

On our side, we don't need to allocate an amount in advance, nor buy licenses, because we use Anthropic models deployed on Vertex AI from one of our GCP projects. Then you just need to point Claude Code to Vertex AI. This configuration also addresses intellectual property issues.

On all these points, another track seems to be using local models. We can mention Mistral (via Pixtral or Codestral) which offers to run these models on private servers to guarantee that no data crosses the company firewall.

I imagine this would also be possible with Ollama.

However I only met one company working on this track during my discussions. But we can anticipate that the rise of local models will rather be a 2026 or 2027 topic.

Human impacts

Recruitment

While AI is now solidly established in many teams, its impacts now go beyond the framework of development alone.

We notably find reflections around recruitment at Alan

Picture this: You're hiring a software engineer in 2025, and during the technical interview, you ask them to solve a coding problem without using any AI tools. It's like asking a carpenter to build a house without power tools, or a designer to create graphics without Photoshop. You're essentially testing them on skills they'll never use in their actual job. This realization hit us hard at Alan. As we watched our engineering teams increasingly rely on AI tools for daily tasks — with over 90% of engineers using AI-powered coding assistants — we faced an uncomfortable truth: our technical interview was completely disconnected from how modern engineers actually work.

Emma Goldblum (Engineering at Alan)

Junior training

One of the big subjects concerns junior training who can quickly be in danger with AI use. They are indeed less productive now, and don't always have the necessary experience to properly challenge the produced code, or properly write specifications. A large part of the tasks previously assigned to juniors is now monopolized by AIs (boiler plate code, form validation, repetitive tasks, etc.).

However, all teams recognize the necessity to onboard juniors to avoid creating an experience gap in the future.

Despite this awareness, I haven't seen specific initiatives on the subject that would aim to adapt junior training.

Welcoming newcomers

Finally, welcoming newcomers is disrupted by AI, particularly because it's now possible to accompany them to discover the product

Some teams have an onboarding skill that helps to setup the env, takes a tour of the codebase, makes an example PR... People are creative*

Julien Tanay (Doctolib)

As a side effect, this point is deemed facilitated by the changes induced by AI, particularly helped by the fact that documentation is updated more regularly and that all guidelines are very explicit.

Support towards a career change

One of the little-discussed elements remains supporting developers facing a mutation of their profession.

We're moving the value of developers from code production to business mastery. This requires taking a lot of perspective. Code writing, practices like TDD are elements that participate in the pleasure we take in work. AI comes to disrupt that and some may not be able to thrive in this evolution of our profession

Cédric Gérard (Ilek)

The question is not whether the developer profession is coming to an end, but rather to what extent it's evolving and what are the new skills to acquire.

We can compare these evolutions to what happened in the past during transitions between punch cards and interactive programming, or with the arrival of higher-level languages. With AI, development teams gain a level of abstraction, but keep the same challenges: identifying the right problems to solve, finding what are the adequate technological solutions, thinking in terms of security, performance, reliability and tradeoffs between all that.

Despite everything, this evolution is not necessarily well experienced by everyone and it becomes necessary in teams to support people to consider development from a different angle to find the interest of the profession again.

Cédric Gérard also warns us against other risks:

There's a risk on the quality of productions that decreases. AI not being perfect, you have to be very attentive to the generated code. However reviewing code is not like producing code. Review is tedious and we can very quickly let ourselves go. To this is added a risk of skill loss. Reading is not writing and we can expect to develop an evaluation capacity, but losing little by little in creativity

Conclusion

2025 saw the rise of agentic programming, 2026 will undoubtedly be a year of learning in companies around the industrialization of these tools.

There are points I'm pleased about, it's the return in force of systems thinking. "Context Driven Engineering" forces us to become good architects and good product designers again. If you don't know how to explain what you want to do (the spec) and how you plan to do it (the plan), AI won't save you; it will just produce technical debt at industrial speed.

Another unexpected side effect could be the end of ego coding, the progressive disappearance of emotional attachment to produced code that sometimes created complicated discussions, for example during code reviews. Hoping this makes us more critical and less reluctant to throw away unused code and features.

In any case, the difference between an average team and an elite team has never been so much about "old" skills. Knowing how to challenge an architecture, set good development constraints, have good CI/CD, anticipate security flaws, and maintain living documentation will be all the more critical than before. And from experience this is not so acquired everywhere.

Now, there are questions, we'll have to learn to pilot a new ecosystem of agents while keeping control. Between sovereignty issues, questions around local models, the ability to test reproducibility and prompt quality, exploding costs and the mutation of the junior role, we're still in full learning phase.

And indeed, we constantly had to find the right balance between building software or buying it off the shelf. Open source existed, of course—I could mention MySQL or Apache—but there wasn't nearly as much complete open source software as there is today.

Over time, the rise of open source changed the game.

Today, for instance, I can run an application on a self-hosted open source PaaS (Coolify), use Metabase for data analysis, OpenPanel for web analytics, Listmonk for newsletters, and so on. I can choose to host and run many software solutions that were previously only available as proprietary products.

So it wasn't just Build or Buy anymore, but Build, Buy, or Run. Running your own software brings its own set of constraints and trade-offs.

But since last year, we're witnessing another shift, and the problem has become Build, Buy, Run, or Vibe (BBRV).

(Vibe refers to vibe coding, though today we're moving beyond simple vibe coding toward a true industrialization of AI usage.)

The Illusion of Code Quantity as a MOAT

A moat is a durable defensive advantage. When building software, we often try to create a moat—a competitive advantage. For a long time, that moat could simply be that rebuilding a piece of software would take too long, even if it wasn't critical to the business.

Take feature flag management software (Unleash or LaunchDarkly), for example. It's not inherently complex, but it's rarely core to a company's business. So in the classic Build or Buy dilemma, Buy was often the preferred choice. What would be the value of rebuilding it?

But now, many "simple" software products can be reproduced with AI-powered coding assistants.

Put differently, I now have to weigh taking an off-the-shelf product that might cost me €100 to €1,000 per month against having an engineer spend a day reproducing only the features I need—plus the cost of running it myself.

This is a massive challenge that every software creator, especially SaaS builders, needs to account for.

The ability to produce code is no longer a competitive advantage.

If code becomes a commodity, does that mean all SaaS products are doomed? Obviously not, but let me illustrate this point.

I recently came across two initiatives to recreate LinkedIn, both built with AI:

• https://nolto.social/ — very promising, based on ActivityPub, self-hostable, open source, and started with Lovable.dev (an AI coding assistant)
• https://ponos-job.eu/ — simpler, also open source, also built with AI

Both products look solid and demonstrate that one or two people can now build very complete software.

To borrow an analogy I've seen several times online: if software production used to be like slowly and meticulously laying bricks one by one, today we can code entire walls at once. What limits a developer is their domain knowledge. But the more well-known and documented a piece of software is, the easier it is to reverse-engineer that knowledge when you have a good head on your shoulders and functional domain expertise.

But here, the barrier to replacing LinkedIn isn't the code itself.

With AI, we've shifted from a scarcity economy of production (coding was hard and expensive) to a scarcity economy of trust and distribution. LinkedIn will keep that advantage over these two initiatives—for now.

And there are other barriers that remain effective:

• Exclusive access to specific data (e.g., Palantir).
• Network effects: LinkedIn, WhatsApp, or X only have value because everyone else is there.
• Regulatory certifications: Accreditations that grant access to protected markets (Banking, GovTech, Defense).
• Ecosystem lock-in: Deep integration into existing workflows (Jira, Salesforce, Okta).
• Captive data: When your data is "held hostage" by a system's complexity, making switching costs prohibitive.
• Service guarantees: Some companies pay for a "throat to choke"—they don't want to be responsible for the "Run."
• Physical infrastructure: Cloudflare or AWS own datacenters. Hardware cannot be replicated by an LLM.

Several of these items are also directly tied to distribution capabilities. For example, I can create a Slack or Teams clone, but I don't have the distribution power (sales force and ecosystem integration) of Microsoft or Salesforce to spread it everywhere.

Those who have the data (whether they buy it or accumulate it) keep the advantage because they can also solve more use cases. And it's no surprise that access to this data is protected. Conversely, those who only manipulate and display data are in danger.

Beyond this, I believe we're witnessing a new generation of companies: AI Natives.

From Cloud Natives to AI Natives

I experienced the Cloud Native era when I founded Malt in 2012.

It meant we owned nothing—no servers, no offices. Everything was decentralized and distributed. It was a purely online company. Every building block of the business was an off-the-shelf SaaS.

With this extreme dematerialization, Cloud Native companies became liquid—easy to modify and evolve. Resource management became a rental model. I rented a service and could switch "easily" (modulo integration costs, of course) without having to manage internal teams, server reallocations, etc.

IT became a kind of giant Lego set.

And for someone who had experienced non-Cloud Native companies—who had gone to the server room to code directly on a failing machine, or suffered through air conditioning failures that brought down the entire infrastructure—the difference is striking. I went from an era where requesting a CI server could literally take three months, with endless network access forms, to a single click on an interface.

Being Cloud Native also naturally became a simple way to embrace modern security concepts, like Zero Trust architecture, which is by definition unavoidable in this context. You can't trust the network because your internal network is the Internet.

This became an advantage during the COVID crisis. I didn't experience, like some companies, having to rotate login times in the morning because the internal network and corporate VPN weren't sized for so much external access. I didn't have to go back to the office to pick up mail or revalidate my PC on the internal network.

And I can tell you I've seen people join the company from traditional businesses who never managed to understand this culture—always questioning the number of services we used, unable to grasp the true nature of what we were.

I know it's still hard, even today, to make people realize that the Cloud was literally one of the major drivers of tech in the 2010s. Many see the cloud as a simple marketing gimmick—just moving your servers to someone else's premises, basic outsourcing. In 2026, there are still many companies that aren't Cloud Native. And that's normal. You don't switch from one world to another overnight, if it's even possible.

When I say it was a driver, you have to understand that it created flexibility and therefore speed—speed that was decisive for all post-2008 companies (in France: Blablacar, Doctolib, Malt, Back Market, etc.). This technological shift also created many opportunities to rebuild existing services, but as online building blocks (the famous SaaS products).

But today we're seeing AI Native companies emerge. Companies for which code production has become a commodity. Production capacity has dramatically increased.

If Cloud Native "simplified" infrastructure, AI is "simplifying" implementation.

(*And yes, I know "simplify" is probably the wrong word because running things in the cloud or producing quality code with AI isn't that simple.)

• 2010: We killed infrastructure complexity (hardware).
• 2024+: We're killing implementation complexity (software).

Consequence: The "AI Native" developer becomes an architect of intent rather than a code craftsman.

The Culture Shock

Just like with the Cloud, AI will create many opportunities. I'm willing to bet we'll see more and more initiatives (like the LinkedIn ones mentioned above) where existing software gets completely recreated by companies with 10x or even 100x fewer people—not to mention the many open source projects that will emerge to replace "commodity" software, like the feature flag management I mentioned earlier.

So that's the first shock. Expect to see many fast-moving competitors emerge in the coming years against well-established software.

But there's a corollary to this, because just as in 2026 we still have many companies that aren't Cloud Native and never will be, many companies won't become AI Native without friction.

Yes, some software will maintain its lead, but an AI Native company will be able to compete on price (with lower production costs) or make higher margins, meaning more investment.

As I said earlier, I can't see many "non-AI Native" companies becoming AI Native, because the social impacts within the company would be massive. It's a question of culture—culture being how you systematically respond to a given problem. An AI Native company isn't trying to reduce costs by 20%; it's trying to operate with a fundamentally different cost structure (10x or 100x fewer staff for the same output).

In short, it's not "just" AI companies that will represent the new generation of post-2020 startups, but probably also a whole bunch of very lean small businesses with few people that will hit many well-established businesses head-on.

And if there's one profile that should come out on top, it's the Product Engineer: the person who can understand the problems to solve and put themselves in the user's shoes.

And you, in your current roadmaps, what portion of your software has already become a "commodity" that AI could rebuild in a weekend? What's the real moat you'll have left tomorrow?

This debate is far from trivial, and spoiler: there are no good guys in this story.

DNS Blocking and Disagreements

You may have missed this, but Italy just slapped a record fine of 1% of Cloudflare's global revenue for failing to block pirate sites.

Cloudflare refused to comply.

To understand what's at stake, we need to talk about DNS. A DNS is essentially the internet's address book, a massive index that links domain names to IP addresses. Think of it like a phone directory connecting your name to your physical address.

DNS blocking is often criticized because it raises several issues.

First, there's performance. A DNS needs to be as efficient as possible, or it risks slowing down the entire internet. It's one of the lowest network layers, and you can't afford to add too much application logic. For instance, checking whether an address is on a blocklist, especially when you want to do it based on the visitor's country of origin.

And that's the thing: the visitor's origin matters. If Italy decides to ban a site, that decision shouldn't automatically apply in Australia or Japan. So in theory, to do this properly, the DNS response would need to vary based on the visitor's country.

Cloudflare handles 200 billion daily requests. If you start adding all sorts of rules at the DNS level, you could potentially slow down global traffic. At least, that's Cloudflare's argument.

Except this performance excuse is undermined by a simple fact: Cloudflare already does this. Their "family" DNS (1.1.1.3) filters adult content and malware. So technically, they have the know-how.

Beyond performance concerns, DNS blocking can be criticized for its lack of precision. If a user on a shared platform like YouTube got banned, the entire domain would be blocked. You can't just ban a single channel.

And finally, if we start implementing these kinds of rules at the DNS level, it's the first step toward network fragmentation. It starts looking like China's Great Firewall.

This Isn't Just an Italian Problem

DNS blocking isn't unique to Italy.

In France, Canal+ has made the same demands to Google, Cloudflare, and Cisco to fight sports streaming piracy. The same conflict exists in Belgium.

Conversely, Germany ruled DNS blocking disproportionate and rejected such requests. Though that was only the Cologne court, and nothing says it couldn't change in the future.

Alternatives to DNS Blocking

So what are the alternatives if you actually want to block content? Are there options beyond going through DNS servers?

Domain registrars: You can ask a registrar to suspend a domain. A registrar is the entity that assigns domain names, and they're localized. French .fr domains are assigned by a French legal entity, German .de by a German one. A judge can easily impose a decision on a French registrar. But it's harder to enforce on other registrars. And remember: .com, .org, etc. are managed in the US. In practice, you'll rarely, if ever, find pirate sites on a .fr or .it domain. That would make them far too easy to target.

ISPs: In France, there's censorship at the Internet Service Provider level, since each ISP has its own DNS resolvers. It's less impactful than going after Cloudflare because an ISP is inherently national. There's less extraterritoriality involved. But it's also easier to circumvent, though you need to be a power user to change your DNS.

Search engine delisting: Every search engine can remove URLs for a given territory. A judge can request that a site be delisted. It's effective, though it doesn't prevent someone from typing the URL directly.

IP blocking: It's radical and can be done at the ISP level or at the country level through international exchange points. But it's generally a bad idea—it lacks any precision. That's how Italy managed to block Google Drive a few months ago.

Cutting off revenue: The ultimate solution is going directly through Visa or Mastercard. This was done in the Wikileaks, Megaupload, and even Pornhub cases in 2020. But in practice, it's mostly an American prerogative since Visa and Mastercard are US companies, and it remains very exceptional.

Reporting to the host: This works well for sites with a localized host. I mentioned YouTube earlier—you can report content that violates the platform's terms of service. You can also contact a hosting provider like OVH. But again, you may be limited by the jurisdiction the host falls under.

The takeaway is that no perfect solution exists, and it's often a mix of approaches used depending on what compromises can be made.

Network Neutrality?

When it comes to DNS, the real debate goes beyond mere technicalities.

Do we accept "breaking" pieces of "neutral" infrastructure for marginal gains against piracy, or do we consider it a red line?

Germany has largely said no. Italy and France say yes.

I struggle to have a clear-cut, absolute opinion, but I feel we're putting our finger in a dangerous mechanism.

Today, piracy serves as the pretext. Tomorrow, it might be political opposition sites, as in Russia or Turkey, or whistleblower sites like Wikileaks in the past.

Who gets to define what's acceptable? In theory, the answer is simple: the law and the courts.

And that's precisely where things go wrong in France and Italy. It's not the judiciary that decides, but an administrative authority. Italy's Piracy Shield requires blocking within 30 minutes with no judicial oversight. In France, it's the same: ARCOM can request ISPs to cut access without any court ruling.

This lack of oversight and appeal, this rush—we're talking 30 minutes to decide on a nationwide block—is exactly the kind of mechanism that can enable a total blackout like we've seen recently in Iran.

But no need to go to Iran or Turkey: consider the TikTok ban in New Caledonia in 2024 during the protests. It was an administrative decision later deemed illegal by France's Council of State. But it took a year to reverse.

Matthew Prince's Response

Let's shift perspective and take time to read Matthew Prince's response, CEO and co-founder of Cloudflare, on Twitter.

The beginning is what we've already covered: a recap of the facts, with Italian (and broadly European) views opposed to Cloudflare's technical stance of not wanting to deal with this.

But the thread doesn't stop there. And this is where things go off the rails.

First, Cloudflare lists its immediate actions: no longer providing security for the upcoming Milan Olympics (debatable—it was provided for free, and when you get fined 1% of your global revenue, you're entitled to be upset), cutting free access for all Italian users (a bit disproportionate), removing all servers from Italy (you can feel the anger), and not opening an office there (this one made me laugh—"we had planned to, but now we won't"—that's not a real threat).

What's really worth noting is that we're talking about retaliation measures. This is a US company threatening a European state.

But it's the next paragraph that really gets me:

I appreciate @JDVance taking a leadership role in recognizing this type of regulation is a fundamental unfair trade issue that also threatens democratic values. And in this case @ElonMusk is right: #FreeSpeech is critical and under attack from an out-of-touch cabal of very disturbed European policy makers.

And there, the debate shifts nature entirely. We're no longer discussing technical or legal questions. When Cloudflare's CEO invokes JD Vance and Elon Musk to talk about free speech, we've entered different territory.

Free Speech, Selectively Applied

We need to dwell on the irony around free speech, because it's the go-to argument often used by the Trump administration.

Let me remind you that Musk freely uses censorship on his own platform and accepted without hesitation to censor opposition to Erdoğan in Turkey in 2025 because it served his own agenda.

I could also point out that the current administration of Vance and Musk—since he was part of it—banned over 350 words from all official communications, including "woman," "climate change," and "disability."

Free speech in the US also means firing several public figures, particularly in media, for disagreeing with the current government.

So free speech is applied rather selectively. It's hypocrisy.

And when you dig a little deeper, Cloudflare itself has engaged in censorship—in 2017 and 2019, of its own volition, with no external pressure—in the Daily Stormer and 8chan cases. So the principle isn't "we never censor"—it's "we censor when we decide to."

You can dress up just about any topic in newspeak. But above all, free speech here is a commercial negotiation argument dressed up as a democratic principle.

And this raises a question we can no longer ignore: our dependence on US infrastructure is also a dependence on their political agendas.

There Are No Good Guys

In short, in this story, we can absolutely question the legitimacy of the method—blocking by administrative authority without judicial decision.

We can express reservations about the possible and probable abuses of these tools.

And yet, we can also acknowledge that it's not healthy to have such strong dependencies on American companies that can directly threaten European states to not comply with local law, whether well-crafted or not, AND while having their own agenda on what's acceptable.

There are no good guys or bad guys here. We have things to watch regarding the widespread use of digital control by our own states in Europe. But we also must not fall into the trap of letting other countries decide for us.

Let's not fool ourselves. No, technology is not neutral as Matthew Prince claims. And we can clearly see that those who control the pipes would also like to decide what flows through them. And that would be even worse than leaving the decision to an administrative authority, despite all the criticism I have for it.

For my part, I took the initiative, imagining that Cloudflare could have the same conflicts with France. So I deleted all my sites managed on Cloudflare and now use Bunny.net for the same services.

Under the hood I use Nuxt, but I don't use nuxt-content to have more flexibility, so I use the Nuxt-Mdc module directly. This module allows you to extend markdown to include custom components, such as image galleries, embedded YouTube players, and more.

However, Writizzy offers themes, and we want to easily customize components for each theme.

In this article, I'll show you how to use Nuxt-Mdc for this fairly common use case.

Nuxt-mdc

The nuxt-mdc module is used by nuxt content, but it can also be used directly to parse markdown content and render it as HTML. It's a core building block of Nuxt-Content, but fortunately it works as a standalone module.

Among Nuxt-mdc's features, you can use MDC components.

An MDC component is essentially a markdown syntax that calls a Vue component for rendering.

For example, with this markup:

::card
The content of the card
::

We're telling Nuxt-mdc to use the Card component to render the block above.

This is also what Nuxt-mdc uses to render all Prose components, which are custom components for headings, links, blockquotes, etc., created after markdown parsing. Internally, each standard Markdown element is transformed into MDC components. For example:

## a title is transformed into

::h2
a title
::

(This is a simplification. In reality, it's more of a substitution at the renderer level. The renderer reads the AST tree containing an h2 node and decides to use the h2 component to render it. But this is a good way to think about it.)

This feature allows Nuxt-Mdc users to customize the rendering of each MDC component, including Prose components.

To override a Prose component or create a custom component, you just need to place them in the app/components/mdc directory of your Nuxt application.

But what if you want these components to change based on the selected theme? That's exactly the question I faced with Writizzy.

A theming system for components

In Writizzy, I'm developing a theming system. You can choose your blog's appearance from the themes listed here. I partially reused what I had already built for Bloggrify (an open source project for creating static blogs).

But with Writizzy, I was quite unsatisfied with this solution, especially for custom components. Obviously, the appearance of custom components should change based on the theme.

It turns out there's an undocumented feature in Nuxt-Mdc that does exactly this.

By default, the documentation recommends using the MDC component to display markdown, for example:

<script setup lang="ts">

const md = `
::alert
Hello MDC
::
`
</script>
<template>
  <MDC :value="md" tag="article" />
</template>

However, MDC uses **MDCRenderer **behind the scenes. And looking at MDCRenderer's source code, we notice an interesting prop: components

This prop allows you to pass the list of components to use.

By default, MDCRenderer will look in this list first, then fall back to components/mdc, so you can override only the components you want to modify:

<script setup lang='ts'>

const mdcComponents = {
  callout: TerminalCallout,
  blockquote: TerminalBlockquote,
  pre: TerminalCode
}
</script>
<template>
  <MDCRenderer 
    :body="ast.body" 
    :data="ast.data"
    :components="mdcComponents"
  />
</template>

And that's it!

Now you can customize each component based on the theme.

This approach works well for Writizzy, and I plan to apply it to Bloggrify as well. If you're using Nuxt-MDC with a theming system, I think this is the cleanest solution—even though it deserves to be officially documented.

I've opened an issue to clarify its status. In the meantime, it's working in production on Writizzy without any issues.

Of course, we've been talking about AI to the point of exhaustion for 4 years now. I've done a few posts and videos on the subject, but the evolution between early 2025 and early 2026 is now striking.

With this evolution comes a major question: what's the impact on our profession? How do we reinvent it?

Let me offer a press review to explore this question.

The Age of Agents?

In this article, Simon Willison, co-creator of Django and Lanyrd, highlights the major shift of 2025: the year of agents.

With the arrival of flows in Windsurf in late 2024 and Claude Code in February 2025, everything changed. For many of us, we went from simple copy-paste between the web browser and our IDE to complete delegation of code production.

2025 was also:

• The popularization of the term "vibe coding," which continues to divide between misunderstanding and contempt
• The normalization of $200/month subscriptions
• Conversational image generation models like Nano Banana (previously, you didn't iterate — you had to find the right prompt on the first try)
• The beginning of local code models, which I really hope to see develop further

Go read Simon's article — it's much more comprehensive. But the key takeaway is that with these agents, the very nature of our profession has changed, and it's probably not going to stop anytime soon.

A Profession in Transformation

For those — and there are many — who continue not to use AI, or who only use basic autocomplete in their IDE, the wake-up call may be brutal. The profession is undergoing radical change.

I'd recommend reading this article on the topic: "The Inevitable Evolution of the Developer Role" by Smaine Milianni 🇫🇷

Smaine emphasizes the evolution of the role:

• from execution to direction
• from local optimizations to system-level thinking
• from writing instructions to defining intent

And of course it's uncomfortable, because it seemingly diminishes the prestige traditionally associated with writing code.

When an LLM can generate boilerplate, implement well-scoped features, refactor safely, review code tirelessly… Then the act of typing code stops being the core differentiator, and that's uncomfortable for many of us.

I say "seemingly," because while the job is changing, expertise and experience remain important differentiators. In the current workflow, I'm still the one giving directives, correcting the architecture, defining the requirements, the problems to solve, and the expected behaviors.

But as yoandev points out 🇫🇷 (translated from French):

AI demands even greater architectural rigor. Why? Because AI is an amplifier. It magnifies what already exists. If I give it a spaghetti codebase, it will produce more spaghetti, faster. If I give it a clean architecture with clear responsibilities, it becomes a frighteningly efficient surgical assistant. The principle is simple: Garbage In, Garbage Out.

Now, we need to understand that these new practices only emerged in 2025 — the term "vibe coding" itself appeared in a tweet in February! So today, one of the key questions is: "how are we going to industrialize these new practices and make them more compatible with reliable software production?"

The Time for Industrialization

To simplify, my job is now to design and then write what I want to see appear in my application. It's a job of writing, then verification. I need to check that the architecture is correct, that security and performance have been considered, that the model is coherent.

An advanced feature takes me between 2 and 6 hours depending on complexity and my available credits (no, I don't pay $200/month). Some features would have taken me 1 to 2 weeks of work before.

For Chris Loy, software is becoming a commodity:

Traditionally, software has been expensive to produce, with expense driven largely by the labour costs of a highly skilled and specialised workforce. This workforce has also constituted a bottleneck for the possible scale of production, making software a valuable commodity to produce effectively. Industrialisation of production, in any field, seeks to address both of these limitations at once, by using automation of processes to reduce the reliance on human labour, both lowering costs and also allowing greater scale and elasticity of production. Such changes relegate the human role to oversight, quality control, and optimisation of the industrial process.

But we're only at the beginning, and many are wondering how to make what's produced by code assistants more reliable, which involves:

• Optimizing the number of tokens needed to reduce costs
• Making the documentary sources used by AI more reliable
• Ensuring overall coherence through the use of guidelines
• Guaranteeing conformity between implementation and spec

In short: industrializing.

A few approaches have already emerged, such as:

• BMAD, which offers a complete set of conversational agents to simulate a full team.
• SpecKit, similar in spirit but much simpler.

Having tried both, I didn't find what I was looking for. Sure, BMAD lets you simulate a complete team. But it reminded me of the pitfalls of large corporations. I quadrupled my design time, blew through my credit quota, and the produced specification was far too verbose and complex. I felt like I was doing SAFe with myself. And that's not an experience I'd recommend...

SpecKit is much simpler, but still too verbose for my taste. For a simple feature, it created half a dozen files — PRDs, functional specs, technical specs, etc. That's probably what you want in a large industrial group. It's unsuitable in just about every other context. Too much documentation kills documentation.

It would be a shame to reinvent a profession only to immediately recreate robotized bullshit jobs...

Now, since we're talking about transformation, is this the end of developers or a renewal?

End or Renewal?

This question has come up so many times over the years that it's become a caricature. Until now, the conclusion has always been the same: no.

Because we've had the famous rebound effect — by simplifying usage, we've had more demand for developers.

I tend to moderate this conclusion, which has become too automatic today, and I'm afraid we're settling into a sort of Pavlovian reflex. Yes, the answer has systematically been no, but I invite you to reflect on this article that reminds us of the parallel between developers and weavers of 1811 during the famous Luddite revolt 🇫🇷 (translated from French):

Here's what we often forget: during the first industrial revolution in England, real wages stagnated for 40 years while productivity exploded. Forty years. Two generations of workers saw their standard of living decline while factory owners got richer.

Yes, there can be a rebound effect, but it can take a long time and not necessarily benefit everyone:

The World Economic Forum notes that every industrial revolution has created more jobs than it has destroyed. **But **(and this is a big but) the people who lose their jobs aren't necessarily the ones who find new ones.

Historical research shows that during the second industrial revolution, young workers adapted by switching careers to growing sectors. Older workers, on the other hand, were stuck in devalued jobs or shifted to unskilled positions.

What's certain is that there now seems to be an inevitability to these changes, as Salvatore Sanfilippo, the creator of Redis, reminds us:

But, in general, it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun. (...) you can't control it by refusing what is happening right now. Skipping AI is not going to help you or your career.

Even for Linus Torvalds, the question is no longer up for debate:

Is this much better than I could do by hand? Sure is.

We find the same observation from Jaana Dogan (Principal Engineer at Google):

I'm not joking and this isn't funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned, etc. I gave Claude Code a description of the problem, it generated what we built last year in an hour.

You can find this quote in a Pragmatic Engineer article on the same topic: When AI writes almost all code, what happens to software engineering?.

I could also quote Quentin Adam (CEO of Clever Cloud) 🇫🇷:

As developers, we should be careful not to turn healthy skepticism into outright rejection of innovation. History shows that many of the biggest leaps in our field came from tools or ideas that were initially dismissed as "dangerous", "lazy", or "not real engineering".

To end on a more optimistic note, I loved this article by Mattias Geniar: Web development is fun again:

There's mental space for creativity in building software again.

I relate quite a lot to this article. Building an application is hard, but I love building products. Now, I can go much further, and faster. I can focus on what really matters instead of redoing the same boilerplate over and over for 20 years. For me, it's an accelerator, and it completely changes the way I create software. I spend more time thinking, designing, considering the problems to solve — and less time struggling with implementation details. I produce better software, and yes, it's fun.

What Now?

It's hard to say what 2026 will bring when you see how fast everything accelerated in 2025 — especially since we can't really ignore what's happening in the real world and the potential impacts it could have on us. It seems unlikely that we'll voluntarily go back on AI usage, but external events could disrupt things in Europe — for example, if the US cut off our access to certain services, or used them for large-scale industrial espionage.

So perhaps this will be the year of optimization research — making it easier, cheaper, and less energy-intensive to run these agents on local machines. It may also be the year of industrializing LLM usage in companies, but with a clear separation between AI-native companies and the rest. I'll write a more detailed article on this specific topic in the future.

In any case, stay tuned. The profession is changing — fast.

how do you fund an open source project?

Okay, the question isn’t new, and you might be wondering what it has to do with the GitHub discussion above.

Let’s talk about it.

The request was simple: add an llms.txt file, so the documentation could be more easily consumed by LLMs.

The response was just as simple: no, for economic reasons.

But what’s the connection between the two?

Less traffic = less money

The reasoning is actually very simple, and it was explained by Adam Wathan (creator of Tailwind):

Traffic to our docs is down about 40% from early 2023 despite Tailwind being more popular than ever. The docs are the only way people find out about our commercial products, and without customers we can't afford to maintain the framework.

Today, documentation is the main marketing channel for Tailwind’s commercial products (sponsorships, Tailwind Plus, etc.).

Yet since 2023, traffic to the docs has dropped significantly, even though Tailwind has never been more popular.

So the equation is simple:

• less traffic
• fewer conversions
• nearly 80% less revenue
• and very concretely, 75% of the team laid off

In this context, making documentation easier for LLMs to consume means accelerating the loss of the only real revenue source.

From a purely economic standpoint, the decision makes sense.

It’s not anti-AI — it’s simply an economic reality, as Adam points out:

Right now there's just no correlation between making Tailwind easier to use and making development of the framework more sustainable. I need to fix that before making Tailwind easier to use benefits anyone, because if I can't fix that this project is going to become unmaintained abandonware when there is no one left employed to work on it. I appreciate the sentiment and agree in spirit, it's just more complicated than that in reality right now.

Slowing down LLM integration: solution or defensive strategy?

The real question isn’t “is it justified?”, but rather:

Is it viable in the medium term?

In my opinion, probably not. Usage has changed: developers no longer systematically read docs. They ask ChatGPT, Copilot, Cursor, or Claude.

Documentation is consumed indirectly.

Denying this reality comes with several risks:

• approximate implementations generated by LLMs
• more “AI-native” competitors being favored
• a gradual loss of relevance, despite apparent adoption

In other words, protecting traffic today may cost relevance tomorrow.

A problem larger than Tailwind

This debate goes far beyond Tailwind.

I use Nuxt a lot, I really like this framework, and it seems to me that they faced similar issues with Nuxt UI or Nuxt Studio.

I’m using Nuxt as an example, but the problem is clearly general.

Since the acquisition by Vercel, these projects eventually became fully open source, and something tells me that adoption of Nuxt UI has exploded.

In fact — and especially with AI — the traditional build vs buy dilemma is being completely reshaped. It’s easier to prototype quickly, so the perceived value of tools goes down, and monetization becomes more difficult.

I’m not saying that Nuxt, Tailwind Plus, or Nuxt UI are easily reproducible with AI. There is also the vision of their creators, which makes these tools unique. And it’s precisely because they are open source that feedback loops are stronger and these tools keep improving.

But many developers might be tempted not to buy the paid layer of an open source project, under the assumption that it’s now much more accessible to build something themselves.

In short, selling add-ons on top of open source projects is hard — and that’s not exactly breaking news, we already knew that.

In this context, Nuxt’s acquisition by Vercel can be seen as a way to get some breathing room and secure development. But it’s also an externalization of the problem, with an obvious cost: loss of control and a risk of under-investment in the long term.

It’s not a structural solution. It’s a compromise.

Coming back to the main topic, one hypothesis is becoming increasingly clear:

documentation will no longer be a human marketing channel.

It will be read by machines, summarized, transformed, and injected into prompts.

Refusing this evolution is a risk in itself.

But accepting it without an economic model is another.

What possible paths forward?

I’ve been thinking about it, and I see several interesting directions.

The question is no longer how do we bring developers to the website?, but rather how do we show up where they actually code?

Let’s start with one option — the one that appeals to me the least:

Docs consumable via API with a paywall

We could imagine exposing llms.txt through a paid or semi-paid API:

• with rate limiting
• potentially restricted to customers or sponsors

It’s technically feasible, but I can’t really imagine developers paying a subscription for every existing llms.txt file.

Now, a second direction seems more interesting to me: what if we moved marketing closer to users?

EDIT: Someone just pointed out to me the existence of a new protocol currently being tested by Cloudflare in beta: pay-per-crawl.

On paper, this could be interesting. The idea is to trigger an exchange between the crawler and Cloudflare in order to charge an AI a fee for crawling a given page.

If this were to become a standard, and if the per-request cost were very low (for example, $0.00001 per call), and **if **AI agents were able to integrate this into their own pricing models for end users, then this could potentially work and provide a new source of funding for open source projects.

That’s a lot of “ifs”, but why not.

Official MCP / AI server

Imagine Tailwind offering its official MCP resource, but with instructions for AI agents to mention paid products at the right moment.

This could take the form of a banner displayed occasionally in the console to encourage visiting the site or to highlight paid products.

It could also warn users when they’re reimplementing something that already exists in the paid offering, for example in Tailwind Plus.

The idea isn’t to create intrusive ads, but to show the right message, at the right time.

EDIT : Alternatively, you can create a paid MCP server that is very useful for use with your product. That’s the approach of DaisyUI. This MCP server includes various tools that go beyond simply knowing the documentation, with best practices, migration tools, and templates.

Conclusion

I believe the real shift to make is this: stop looking for monetization only in the browser, and instead in the tools developers actually work in.

Today, that’s the prompt.

And something tells me this problem is also generalizable to search engines, which are increasingly being bypassed as well — but that’s another story. What’s certain is that I wouldn’t be surprised to see product placement inside LLMs in the future.

In short, the problem isn’t AI. The problem is that the open source economic model was built for a world that no longer exists — and if usage has moved from the browser to the prompt, monetization will have to follow.

A few days later, Washington threatened European judges who might rule against far-right parties aligned with US interests. This follows a national security memo explicitly aimed at destabilizing European politics.

Read that again. Yes, really.

For years, Europe's tech dependency on the US has been discussed as a strategic vulnerability. In 2026, it's becoming an active political weapon.

This has been building for a while

I've been writing about this topic throughout 2025:

• Why I left Twitter and why you should consider it too (January 2025)
• The myth of neutrality: Why tech is political (March 2025)
• Europe vs USA: Tech at a crossroads (March 2025)
• Calculate your US tech dependency score (April 2025)
• Building an app independent from US tech in 2025 (December 2025)

And the conversation has accelerated.

The calls for action are getting louder

The Chaos Computer Club—Europe's largest and oldest hacker collective, founded in 1981—recently called for a monthly "Digital Independence Day" to migrate away from US platforms. Their statement emphasizes the extraterritorial legal risks that come with using American tech infrastructure.

Bert Hubert, founder of PowerDNS and a respected voice in European tech circles, published a pointed piece arguing that governments can no longer build their digital infrastructure on US clouds. His argument: the legal, political, and operational risks have become unacceptable.

In France, a petition to the National Assembly is demanding that the government stop using X for official communications.

People are actually migrating

The subreddit r/BuyFromEU now draws 401k weekly visitors looking for European alternatives to US products and services.

Practical migration guides are multiplying:

• Migrating to Proton, European VPNs, and privacy-first tools
• Moving from Google Workspace to Infomaniak
• Switching from GitHub to Codeberg

And here's a telling data point: according to Médiamétrie (France's official audience measurement body), X has dropped out of the top 50 most-visited websites in France—now ranking behind the postal service and a discount grocery chain.

What's next

This isn't about anti-Americanism. It's about reducing single points of failure—technical, legal, and political. The question is no longer whether Europe should reduce its tech dependency, but how fast it can actually move.

As for me, given what I write here, I probably won't pass the new US visa screening that now includes social media background checks. Not that I was planning to go anyway.