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.

• eventuallycoding.com (the french version of this blog)
• bloggrify.com (an open source project)
• all the demo sites for Bloggrify templates (minimalist.bloggrify.com, mistral.bloggrify.com, etc.)

While I do appreciate Netlify, there are European alternatives out there, so I wanted to give migration a shot.

Netlify and its alternatives

Before diving in, let's clarify what Netlify is and how its alternatives position themselves.

Netlify is a PaaS—a platform for running Jamstack applications.

Jamstack is an architectural approach built on JavaScript, where the application runs mostly client-side with API calls when needed. Netlify is actually the main private company behind the Jamstack community and has been pushing this approach across the industry.

In short, it's a platform that handles builds, deployments, and extensions (auth, database, CMS, etc.).

If we're looking at plug-and-play alternatives in the same space, we could list:

• Vercel (which has faced controversy over its CEO's support for Trump and Netanyahu)
• Cloudflare Pages
• Firebase

But all of these platforms are US-based.

There are other, more general-purpose solutions where you can find European options: Scalingo or Clever Cloud.

But there's one solution that often gets overlooked: Bunny.net.

Bunny.net

Originally, Bunny.net isn't a direct Netlify competitor. Bunny.net is primarily a CDN and compares more closely to Cloudflare. But like Cloudflare, they've evolved to offer advanced features that enable running simple Jamstack applications on their CDN.

Fair warning: it's less polished than Netlify or Cloudflare. You'll find fewer services and you need to assemble a "storage zone" and a "pull zone" yourself to set up your site. As we'll see, there are a few other limitations. But on the flip side, you get solid DDoS protection and consumption limits (to avoid those $100,000 Netlify bills...), image optimization services, resource optimization, bot protection—basically everything I need for static blogs.

Now let's get practical and see how I migrated Bloggrify.

Case study: Migrating Bloggrify

Bloggrify is an open source project, kind of like Docus but for blogs. And if you don't know Docus, that sentence probably made no sense :)

But no matter—the key point is that it's a static blog generator, and static means deployable on a CDN.

Pull zone and storage zone

First things first: we need to create a storage zone for the files:

Once the zone is created, you need to connect it to a "pull zone". This pull zone is what will actually serve your website.

Now go to the storage zone settings, navigate to FTP & API access, and grab the password needed to use the API.

Setting up automated deployment with bunny-deploy

One of my key requirements for migrating was not losing deployment automation. Fortunately, there's a GitHub Actions plugin for deploying to Bunny.

Add these steps to your workflow:

    - name: Generate static site
      run: npm run generate

    - name: Deploy to Bunny
      uses: R-J-dev/bunny-deploy@v2.1.1
      with:
        access-key: ${{ secrets.BUNNY_ACCESS_KEY }}
        directory-to-upload: ".output/public"  # Nuxt 3
        storage-endpoint: "[https://storage.bunnycdn.com](https://storage.bunnycdn.com)"
        storage-zone-name: "bloggrify"
        storage-zone-password: ${{ secrets.BUNNY_STORAGE_ZONE_PASSWORD }}
        enable-delete-action: true
        enable-purge-pull-zone: true
        pull-zone-id: "5063091"
        concurrency: 50
        replication-timeout: "15000"
        request-timeout: "5000" # optional, defaults to 5000
        retry-limit: "3" # optional, defaults to 3

Make sure to add BUNNY_ACCESS_KEY and BUNNY_STORAGE_ZONE_PASSWORD to your repository secrets beforehand.

Obviously, storage-zone-name should match the zone name you defined in Bunny—in my case, "bloggrify".

Configuring your custom domain

At this point, your site is probably live on a Bunny URL like bloggrify-mistral.b-cdn.net. However, you can add a custom hostname:

This will require you to configure your DNS by adding an ALIAS or CNAME record.

Avoiding outrageous bills

Bunny lets you cap consumption and protect against DDoS attacks. To do this, select your pull zone, go to Network limits, and create a "monthly bandwidth limit". I set mine to 1GB since Bloggrify doesn't get excessive traffic.

On top of that, you can go to Shield, choose the free plan, and enable DDoS protection. Adjust the sensitivity based on what feels right for your use case.

Nitro configuration

In the specific case of Nuxt—especially Docus—you might run into an issue. The generated site contains directories without an index.html file.

For example:

• introduction/configuration (containing page resources)
• introduction/configuration.html

But if you navigate to https://bloggrify.com/introduction/configuration, you'll get a 404 by default because nothing rewrites the URL to the HTML file. So you need to explicitly tell Nitro to change how it generates files:

export default defineNuxtConfig({
  nitro: {
    prerender: {
      autoSubfolderIndex: true
    }
  }
})

With this setting, you'll now get:

• introduction/configuration/index.html—and it works.

This workaround isn't needed on Netlify, which handles this gracefully, but Bunny needs a little help.

And... that's it.

Sure, the setup is a bit more involved than Netlify, but bloggrify.com is now running on Bunny and I'm gradually migrating my other sites. Mission accomplished—I might post a follow-up in a few months.

Now you might be thinking, "Aren't blogs kind of dead since YouTube, TikTok, Instagram came along?" I don't think so, but I'll get back to that.

However, blogs do have one major weakness compared to all those platforms: discoverability. What makes these platforms successful is... their content recommendation algorithms.

Yes, I know—that's also what we criticize them for. But without algorithms, nobody would ever discover Mike's video about his passion for ant-keeping. And that might be a shame.

The thing is, recommendation comes with platform responsibility for suggested content, which means moderation. And so far, no platform has nailed this. Between YouTube's puritanical overzealousness, X's normalization of conspiracy theories, and Shein selling questionable products, it's clear this problem is far from solved.

So what do we do? Is it doomed to fail?

In this post, I'll cover the health of blogs, why discoverability matters, different approaches to discovery, content recommendation platforms, and moderation. Fair warning: I don't have all the answers—I'm actively working through this myself. But that's exactly why I'd love to discuss it.

Blogs Are Doing Just Fine

Surprise: blogs are actually thriving. According to OptinMonster, there are over 600 million blogs worldwide. More than 409 million people read over 20 billion pages monthly on wordpress.com alone, with WordPress still powering 40% of all websites. Another source claims that 83% of internet users (4.4 billion people) regularly read blog posts.

So blogging is very much alive, though there's definitely been a shift toward video consumption.

Today, 82% of global internet traffic is video, and many people now turn to TikTok, Instagram, and similar platforms for quick answers—whether it's recipes, DIY tutorials, or even tech topics. That said, written content has clear advantages: it's easier to create and update. I do both—videos and blog posts. Writing is obviously much faster than producing a video, plus I can update an article after publishing, which I can't do with a video. That's a significant advantage for people who don't have the energy to film themselves, or simply don't want to show their face.

Yes, video will keep dominating entertainment and "brain off" moments, but blogs will remain more accessible and better suited for specialized, easily-updated content.

However—and this is where video platforms win—the big difference is content recommendation. And that's what makes the blog model fragile.

Discoverability: Just Vanity Metrics?

Discoverability is a broad topic, because the first question is: does it even matter when you're writing a blog?

For some, the answer is clearly yes—people who've built media outlets, paid newsletters, and monetize their traffic. Examples: Pragmatic Engineer, Ali Abdaal.

At the other end of the spectrum, it's purely personal—a journal where whatever happens, happens. Discoverability might even be actively discouraged, like n.survol.fr which publishes no sitemap and makes site exploration intentionally difficult.

And between these extremes lies a whole spectrum: people working on personal branding (so 2010s), others using blogs for influence, weekend hobbyist bloggers, etc.

I'm somewhere in that gray zone. I don't monetize my blog, which I've been running since 2001, but I'll admit I'd find it a bit sad if nobody read it. So I pay attention. Even though I use it as a kind of personal digital memory, my original motivation back in the early 2000s was sharing tutorials and experiences. And if absolutely nobody reads them, I'd probably put in less effort. That's precisely why I added YouTube videos a year ago—to scale up.

I understand this isn't everyone's goal, but personally, I'm trying to have an impact—at my own scale—on understanding tech topics and their influence on business and society. I'm not selling anything; I'm trying to contribute something.

Here's the thing: when I post a YouTube video, I average several thousand views, with my personal best at 35K so far. (For example: as I write this, I published a video this morning and it already has 3.6K views in under 7 hours.)

On the blog, views range from 50 to 12 000, with most posts hovering around 1K. And that's for an established blog with decent domain authority and reasonable SEO—these aren't even bad numbers.

Again, maybe some people are totally against tracking these "vanity metrics," but I won't pretend I'm not competitive, and I'd bet some blogs would be more active if they were more widely read.

When content isn't read, it's not necessarily because it's bad—it's because it's hard to find. Without active promotion, nobody reads a blog post. SEO for individual bloggers is a nearly lost battle against platforms and professional sites with better authority or marketing budgets.

That's why 90% of bloggers use social media to promote their posts.

And naturally, while building Writizzy, I'm wondering: what if we could do better? What if we could enable content discovery through a community of readers?

Algorithms: The Platform Solution

This is exactly where platforms come in. Instagram, YouTube, TikTok, X—they all work the same way. They create personalized content feeds, trying to maximize time spent on the platform by continuously serving content tailored to each user.

The idea is to leverage content produced by all users to determine the right audience for any new video.

When I publish on YouTube, I make zero promotional effort—YouTube handles it. It identifies the right audience, shows them the video, measures reactions (clicks, watch time, likes, comments, etc.), validates the audience, and repeats.

That's what we call an algorithm.

But these algorithms have plenty of flaws. They can be optimized to favor negative engagement (like X, which amplifies controversial content), or even favor certain political viewpoints (X again, implicated in several recent election interference cases). They're also criticized for creating filter bubbles that trap us in belief patterns—though I'd argue our own confirmation biases already do that on their own. They can also lock us into infinite scrolling, rewarded by small dopamine hits, while we passively accept ads scattered throughout.

Yes, algorithms have a bad reputation, but in practice, they're the main reason we stay on these platforms. They let us discover available content, and for creators, they're what prevents total anonymity.

If I'm convinced discoverability matters for blogs, one question emerges: how do we give control back to users?

Taking Back Control

Before going further, I should note that not all algorithms are opaque and complex. There are "lightweight" alternatives, like Hacker News, which ranks purely by vote count and freshness. Bearblog uses the same approach, displaying its formula at the bottom of the page:

# This page is ranked according to the following algorithm:
Score = log10(U) + (S / (B * 86,400))

Other solutions offer simple chronological sorting. That's Mastodon's approach—posts sorted purely by date. I find this too minimalist.

What really interests me is whether there's a virtuous approach. How do we preserve recommendation quality without imposing unilateral choices? This is exactly what this blog post addresses, making an important observation:

You can pay money and advertise to women of color between 40–60 in Seattle, but you can't choose to read perspectives from those women

The post highlights a solution, an MIT research project: Gobo (unfortunately inactive as I write this), which lets you aggregate data from platforms and apply your own filters. Similar projects include Youchoose and Tournesol, all sharing the same goal: empowering users.

While these initiatives remain niche, the most polished and widely-used implementation is probably Bluesky, which lets anyone choose algorithms that can be created by other users.

If I were to build a content recommendation system for Writizzy, this would be the approach that appeals to me most.

However, discussing this with Thomas (who also works on Writizzy), offering a content feed quickly raises two other problems:

• How do you start with only 140 users, of which maybe 10-15% are truly active? This is called the Cold Start problem.
• Moderation.

I'll skip the first topic—it's not what this post is about. But the second is serious.

Moderation

The moment you create a page aggregating content from multiple users, the risk of inappropriate content exists. It could be adult content, spam, scams, racist abuse, etc.

Writizzy already has responsibilities under the European DSA (Digital Services Act). I must provide a reporting mechanism and act on reports of illegal content. Note: as a host, I'm not required to proactively monitor—only to respond to reports. As long as blogs remain separate, it's still manageable. Impact is limited to the individual's blog.

But once a feed exists, impact multiplies—that's the whole point—but it also creates more pressure on moderation. And it's far from simple, because you have to judge whether content is illegal, and that judgment isn't always clear-cut. What's acceptable varies.

Where's the line between satire and insult? Between political criticism and defamation? How do you detect and handle fake news? What's the line between pornographic nudity and art (Courbet's L'Origine du monde, for instance)?

I've tried to catalog different moderation methods to see what might work for Writizzy:

Manual Moderation

Two main categories here: manual moderation by one or more super-admins, and mass outsourced moderation. Small-scale manual moderation is what you see on Mastodon, with the obvious bias of moderator subjectivity and resulting conflicts between instances with different political positions. I'm not infallible; I don't want to be responsible for moderating all published content. And it won't scale.

Then there's mass moderation, often outsourced to low-wage countries by major platforms like Meta, TikTok, or OpenAI. It's far from pleasant work, and abuses have been documented extensively. It's unsuitable for Writizzy—economically and ethically.

Community Moderation

This relies mainly on user reports. X's Community Notes fall into this category, as do Wikipedia's discussion threads. It's obviously the cheapest approach, but it can be gamed if groups coordinate to censor content. This system can be improved with reputation points awarded by the community. That's Reddit and Hacker News Karma, or Stack Overflow reputation scores. This mechanism could make sense for Writizzy. However, community moderation is reactive—meaning the damage is done; content has already been exposed before being flagged.

Automated Moderation

This can involve keyword detection, user profiling (new accounts, posting patterns, etc.), or nudity detection algorithms for images. It's the easiest method to implement. You can adjust tolerance levels. This is where AI could shine for understanding text, but it's far from foolproof—people use word substitutions, altered spelling, emojis representing concepts, or algorithms simply perform worse in certain languages.

My conclusion from this mini-study is fairly obvious: you'd need automated detection upfront, then a reporting system enhanced by Karma scores downstream, and finally manual super-admin intervention as a last resort.

Yet these systems exist and platforms are still criticized, because all moderation is imperfect. There's always the central question of interpretation: what's legal or not? And that interpretation varies by country and culture.

This brings us to another approach—Bluesky's again—where one of the fundamental principles is decentralization, including moderation via labelers.

Decentralized Moderation

Bluesky's moderation has two levels:

• Base moderation, handled by Bluesky itself. This first layer uses Ozone, an open-source moderation tool. It's configurable so users can set their own tolerance levels. This step catches universally unacceptable content (child abuse, incitement to violence, etc.) for which the platform can be held legally responsible.
• Optional moderation provided by independent labelers. These labelers can be built with an SDK and offered to users who choose them to customize their expected moderation.

Once again, it comes back to the same idea: giving users control. (Even if 90% will probably keep the default settings.)

Alternatives for Discoverability

What's certain is that this topic is complex, and I completely understand Thomas's reluctance to venture into it. So we discussed other approaches. Rather than aggregating content, we could start with content curation. It's much simpler—we could manually select content to highlight each week or month.

We could also consider smaller-scale recommendations:

• Related content suggestions at the bottom of articles
• Similar newsletter suggestions when users subscribe

Or we could focus on automating cross-posting: RSS and newsletters today, automatic distribution to ATProto, Bluesky, Nostr tomorrow?

There are other possibilities, and no decisions have been made yet.

What would you do? If discoverability matters to you, what would be your ideal solution? Do you use Medium's or dev.to's recommendations? Are you already cross-posting to federated networks?

Will the platform shut down in a year or two? What happens if it does? Do I lose my data?

And what if it evolves, but in the wrong direction? (I’m looking at you Twitter...)

Some quotes from users:

I don't really intend to use a platform. One of the reasons I built my own engine is stability.

Before using Substack, I was using Twitter's solution that did pretty much the same thing. They shut it down overnight, and I couldn't recover my content.

This is a legitimate concern: will the effort I put into maintaining a blog be wiped out tomorrow?

I need to answer this question. How do I preserve the effort of people who might use Writizzy? Here are some of my answers. But this isn't just about Writizzy. Whether you're choosing a platform or building one, here's a framework for thinking about longevity.

Plan for reversibility

The first priority, in my view, is to always remain in control of what you produce. You need to provide a simple way to export your data.

The import/export function must be easy to find, and the format must be usable.

On Writizzy, I chose a JSON format similar to Ghost's. All posts are included in markdown format. The newsletter subscriber list is also included.

There's no data lock-in, and it would be easy for any user to migrate to another platform if needed.

The second factor of reversibility is giving everyone the option to use their own domain name. For example, I use eventuallymaking.io. If Writizzy shuts down tomorrow, I could keep that domain and rebuild my blog from my data. The content isn't buried inside a platform (like Medium, for instance), so I retain full control over how I can retrieve and distribute it.

On the topic of reversibility, I could also mention interoperability: how to ensure content isn't exclusive to Writizzy, how to make it work elsewhere. Solutions like RSS feeds and newsletters already exist. But I'm also looking into ActivityPub, AtProto, and anything that could enable better content decentralization if viable solutions emerge.

Prevent enshittification

Yes, that's a strange title.

Most consumer products tend to age poorly—becoming too complex, too expensive. This is often the result of two pressures: shareholders seeking to maximize profits, and internal teams who need to constantly evolve the product to justify their existence.

Cory Doctorow popularized this term, but mainly in reference to the first cause—investor pressure. I tend to think the second is just as problematic.

Writizzy is built differently. And I believe most new companies being created in this post-AI, bootstrapped era will share this same discipline. I'll make sure to build only what's necessary and evolve the product only when needed. I won't take external investors and I don't plan to sell this project. And I don't plan to hire hundreds of people.

I think it's possible—and actually healthy—to build "slowly but surely" for this type of project.

Be economically viable

Longevity requires that the product isn't a financial black hole. The first answer was given in the previous section: I have no investors, I won't hire people to burn through a budget I don't have, and I know what it takes to build a product—I've done it several times. I know how to develop lean.

On Hakanai.io (another product I created), I'm not making thousands of euros, but the product brings in more than it costs. Writizzy is only a month and a half old, and that's already the case too. Because it's simple today to create products with limited resources.

Obviously, I might not be able to live off it, but I'm not counting on that for now—and neither is Thomas, who builds this product with me. I'll work toward making it happen, if only to prove I can, but I have the luxury of being patient.

Use durable technology

This is the hardest part to achieve, because no technology is truly durable. All languages, all frameworks require regular updates—for security patches, OS compatibility, and so on.

That said, there are some best practices to follow: avoid technical lock-in, don't rely heavily on a platform you couldn't do without (avoid big cloud vendors, Datadog, etc.). Always have alternatives, backup plans in case a tool becomes too expensive or dies.

Writizzy runs on a standard stack (Kotlin, Nuxt) with a PAAS tool that would be easy to swap (Coolify with Traefik), on a straightforward VPS at Hetzner.

You might ask: why not make it open source? It seems like the ultimate guarantee of longevity. I say "seems," because history has shown that open source projects can be co-opted by their creators (see WordPress and its various dramas).

The question isn't necessarily open source vs. not open source, but rather: what are the creators' intentions?

There are many examples of openwashing—projects that use the "open source" label as an acquisition channel or marketing argument, without it being a deep conviction.

In any case, open source comes with constraints. Today Writizzy is three separate applications, which isn't exactly the standard for what people like to deploy as open source. It's also designed as a platform, not a product meant for personal use only. Finally, there's the matter of commercial exploitation—I don't want others to profit from my work for free and resell what I've built.

I might revisit this topic in the future depending on how the product evolves. But for now, this option is off the table.

However, if Thomas and I decide to stop or if something happens to us, that would trigger a switch to open source—and I'm going to set up mechanisms to make that happen automatically.

Be your own first user (dogfooding)

Finally, I've been blogging for 20 years. I'm currently the most prolific user on Writizzy with over 80 articles already published (though I cheated—I migrated my old posts ^^). I'm building this tool because I use it. I think it's much easier to build a product you understand because you're a user yourself.

And that's also a factor for longevity.

I should mention that I'm generally not in favor of variable pay for engineering roles. At least not before staff engineering level and above, but that's not the point of this post so I won't elaborate.

Let's elaborate now.

TL;DR

Variable pay for tech roles isn't common practice, and it's generally perceived negatively by engineers — rightfully so, in my opinion. It becomes an obstacle during hiring.

Unless the variable is added on top of market rate.

In practice, it also creates ongoing tension between managers and employees when there are no objective and relevant criteria for awarding bonuses.

Perks like additional PTO based on tenure, conference budget, learning stipends, etc. are far more effective at building a lasting relationship.

The difficulty of finding relevant criteria also makes variable pay counterproductive — either because it misaligns individuals in what is naturally a collaborative activity, or because it incentivizes gaming the metrics meant for continuous improvement.

Using equity (stock options, RSUs) or profit-sharing mechanisms is, in my view, a much better way to align individuals with company success.

Variable pay is a hard sell during hiring

Let's start with the basics: why do companies offer variable pay?

For the company, it's mainly about motivating employees to go the extra mile in order to earn a higher salary.

For the employee, there's significant risk involved. Variable pay isn't guaranteed. It's typically excluded from income calculations when applying for a mortgage or renting an apartment. Banks look at your base salary, not your OTE.

And that's my first argument against variable pay.

In today's context — where variable pay is uncommon for tech roles, the market is tight, and salaries are high — you lose a lot of attractiveness if the variable component just compensates for a lower base.

A dev will systematically choose $180k fixed over $150k fixed + $30k variable(all other factors being equal). Why would they do otherwise?

Now, you might argue that variable pay can allow someone to significantly exceed market rate.

And yes, if the variable is added on top of market salary, it can become attractive.

For example: $180k fixed + $30k variable.

But let's be honest — this is rare. Most companies align with the market and then carve out a portion to make it variable.

Bottom line: it generally doesn't add to your attractiveness and makes the offer stage of hiring risky.

It's a constant source of tension with the manager

If it's harder to recruit with variable pay, it's also a source of tension between managers and employees since you need to regularly set and update objectives.

For sales roles, it's considered straightforward — variable pay is proportional to sales volume.

In tech roles, it gets complicated. The job is inherently team-based and creative. You can't easily measure individual success, and devs don't (thankfully) get paid per line of code.

At a previous company, I was often told that "bonuses were almost always given" and that "if you didn't get it, you should consider leaving because either the company was doing badly or it was a hidden message." Basically, withholding the variable was used as a roundabout way to push people out.

Personally, I much prefer clear messages. If something's wrong, I shouldn't have to guess — we discuss it and decide together. Using variable pay this way is cowardly management.

If you want to set up a system to encourage people to stay, there are many more effective options:

• Work environment (good equipment, quality office in a good location, or remote work)
• Mission and meaning of the work
• Continuous learning budget (conferences, traditional training, online courses, etc.)
• Equity that vests over time (you acquire portions progressively)
• Benefits that accrue with tenure (additional PTO, for example)

(non-exhaustive list)

Variable pay is counterproductive

But let's get back to how variable pay is calculated. To have variable pay, you need to tie it to an objective.

First scenario: individual objectives tied to a specific project.

This often leads to absurd situations. Projects get abandoned because they're no longer relevant, scope changes, the person is no longer working on it, etc.

And when I talk about counterproductive situations: in the past, as an individual contributor, I had the choice between continuing on a project (relatively small and less useful than expected) to get my bonus at the expense of the team, or abandoning it to focus on more relevant topics at the expense of my bonus.

In short, you create a conflict between (very) short-term and long-term interests.

(Have you never seen a situation where, after discussion, everyone agrees that a project is actually problematic for the company, but a few people whose bonus depends on it keep defending it?)

Second scenario: those who try to rely on quantitative metrics not tied to specific projects.

Sure, what could be more natural than looking for individual measurement tools?

In a company, you want a reliable, fair, objective, and consistent tool to measure performance. What better than quantitative data? The intention is good.

However, I could quote a famous law:

When a measure becomes a target, it ceases to be a good measure.

Goodhart's Law

As I mentioned in the post about measuring performance, these tools are meant for continuous improvement of a team. As soon as you start using them to calculate bonuses, things go sideways because the whole game becomes about gaming the numbers.

I have plenty of amusing anecdotes about this... And I could spend a long time explaining how you can game individual metrics at the expense of the collective.

In any case, a developer works within a team and a strategy. Their success depends on others.

Introducing an individual bonus misaligns people's objectives. It's demotivating and a constant source of conflict.

Team-based bonuses might seem to solve this, but as soon as you apply them only to the dev team, you shift the problem by misaligning them with the rest of the company (customer support, marketing, sales, etc.).

Note: I'm not saying you shouldn't track individual performance (I mentioned it in the post about tracking tools). But this tracking should be both quantitative and qualitative. And it should be aimed at continuous improvement.

If, as a manager, you conclude that someone isn't meeting their objectives and isn't adapting within a team, you need to act — that's your job. But that's a different question from whether someone should get their bonus or not...

Examples of metrics used for variable pay

Here are some metrics that are sometimes used to set up compensation schemes:

Individual bonus based on Scrum metrics

For me, one of the worst schemes. Scrum metrics are the easiest to game and don't reflect software quality. The likely result is lower ambition on sprints or artificial inflation of complexity to increase story points. Really avoid this.

Team bonus based on Scrum metrics

Less bad than the previous one — this scheme tries to account for the collective aspect. But Scrum isn't designed for this. Most metrics that come out of it aren't user-facing. As mentioned above, perverse effects quickly emerge, along with under-commitment to meet expectations.

Team bonus based on user-facing metrics

You could put user NPS in this category. The intention isn't bad, but the connection to dev work is sometimes hard to make. Is NPS really just a reflection of dev effort? Or also customer support, product-market fit, etc.? Too many externalities come into play, and it becomes a source of conflict between departments.

Team bonus based on Accelerate metrics

I'm more convinced by these metrics than Scrum ones because they specifically aim to measure software quality.

But again, you're measuring "internal" quality, not product-market fit. You can ship fast and have few defects on a product nobody wants. You can have a tech team with great metrics but zero business alignment.

It's "the least bad" option, but you're not really solving much...

Equity: alignment and motivation through collective success

To end on a positive note, if we're talking about compensation and alignment with company interests, I'm much more convinced by equity grants (stock options, ISOs, RSUs for startups and public companies) or profit-sharing mechanisms (for mature companies).

Here you lose individual or even team-level tracking for the dev team. But you align everyone with the company's success. We all succeed together or fail together because it's directly tied to the company's revenue (or valuation).

I'll admit, we're not talking about the same thing.

Profit sharing is a mechanism that can only be implemented in mature companies that are profitable (rarely startups). It's generally predictable and you receive it every year.

Variable pay is quasi-predictable — the risk exists but is limited to the year's income.

Equity, in my experience, is harder to explain to dev populations and it's risky — but the potential upside is incomparable.

A lot of the time, equity won't result in any gain. But if the startup succeeds, the gains can be really significant (here are some examples), far greater than a 10-20% variable component.

Equity has multiple advantages, including the fact that people who eventually leave will remain aligned with the company's success and therefore stay active promoters (and really, that's beneficial!).

You can have attribution schemes that depend on where someone is in the career ladder (with possible re-grants starting at staff engineer level if their impact increases, for example).

That's all from me. But I suspect the discussion will continue in the comments on a topic like this :)

The title might sound intimidating, but basically it lets an application handle tons of subdomains (over HTTPS) dynamically for its users. For example:

• https://hugo.writizzy.com
• https://thomas-sanlis.writizzy.com

That's a solid foundation, but users often want more: custom domains. The ability to use their own address, like:

• https://eventuallymaking.io
• https://thomas-sanlis.com

So let's dive into how to manage custom domains for a multi-tenant app with dynamic SSL certificates.

(I feel like I'm going for the world record in longest blog post title!)

Custom Domains

The first step for a custom domain is routing traffic from that (sub)domain to your application (Writizzy in my case).

It all comes down to DNS records on the user's side. Only they can configure their domain to point to your application's subdomain.
They have several options: CNAME, ALIAS, or A records.

1. CNAME (the simplest)

A CNAME is an alias for another domain. It basically says that www.eventuallymaking.io is an alias for hugo.writizzy.com. All traffic trying to resolve the www address gets automatically forwarded to your application domain.

Major limitation: You can't use a CNAME for a root domain (e.g., eventuallymaking.io without the www). Adding a CNAME on an apex domain would conflict with other records (A, MX, TXT, etc.).

2. ALIAS

Some DNS providers offer ALIAS records (or CNAME flattening). It's essentially a CNAME that can coexist with other records on a root domain. Great option if the user's provider supports it (OVH doesn't, for instance).

3. A Record

Here, the user directly enters Writizzy's server IP address.

Warning: This approach is risky. If you change servers (and therefore IPs), all your users' custom domains break until they update their config. To use this method safely, you need a floating IP that can be reassigned to your new server or web frontend.

Alright, that's a good start, but if we stop here, things won't work well—the site won't serve over HTTPS.

HTTPS on Custom Domains

In my previous post, I showed how Traefik could route all traffic hitting *.writizzy.com subdomains to the same application using these lines:

traefik.http.routers.https-custom.rule=HostRegexp(`^.+$`)
traefik.http.routers.https-custom.entryPoints=https
traefik.http.routers.https-custom.service=https-0-zgwokkcwwcwgcc4gck440o88
traefik.http.routers.https-custom.tls.certresolver=letsencrypt
traefik.http.routers.https-custom.tls=true
traefik.http.routers.https-custom.priority=1

Since the regex catches everything, you might think SSL would just follow along. Unfortunately, no. Traefik knows it needs to handle a wildcard certificate for *.writizzy.io, but it has no clue about the external domains it'll need to serve.

We need to help it by dynamically providing the list of custom domains.

Our constraints:

• Obviously, no application restart
• We want to drive it programmatically

Dynamic Traefik Configuration with File Providers

This is where Traefik's File Providers come in.

In Coolify, this feature is enabled by default via dynamic configurations. Under the hood, Traefik watches a specific directory:

- '--providers.file.directory=/traefik/dynamic/'
- '--providers.file.watch=true'

Drop a .yml file defining the rule for a new domain, and Traefik picks it up hot and triggers the HTTP challenge with Let's Encrypt to get the SSL certificate.

Example dynamic configuration:

http:
  routers:
    eventuallymaking-https:
      rule: "Host(`eventuallymaking.io`)"
      entryPoints:
        - https
      service: https-0-writizzy
      tls:
        certResolver: letsencrypt
      priority: 10
    eventuallymaking-http:
      rule: "Host(`eventuallymaking.io`)"
      entryPoints:
        - http
      middlewares:
        - redirect-to-https@docker
      service: https-0-writizzy
      priority: 10

So with this approach, we've solved our first constraint: no restart needed to configure a new custom domain.

Now let's tackle the second one and make it programmatic.

Automation via the Application

The idea is straightforward: the application creates these files directly in the directory Traefik watches.

1. Coolify configuration: Go to Configuration -> Persistent Storage and add a Directory mount to make the /traefik/dynamic/ directory visible to your application container.

1. Code (Kotlin in my case): The application generates a file based on the template above as soon as a user configures their domain.

Important note on timing: If you create the Traefik config before the user has pointed their domain to your IP, the SSL challenge will fail. Traefik will automatically retry (with backoff), but it can take a while. Ideally, validate the DNS pointing (via a background job) before generating the file.

Important note on security: The generated file contains user input (the domain name). It's crucial to sanitize and validate this data to prevent a malicious user from injecting arbitrary Traefik directives into your configuration.

Wrapping Up

This post wraps up what I hope has been a useful series for SaaS builders running multi-tenant apps on Coolify. We've covered:

1. Tenant management (Nuxt) and basic Traefik configuration
2. SSL management with dynamic subdomains
3. Custom domains with SSL (this post)

You might wonder if this solution scales with tens of thousands of sites all using custom domains—specifically whether Traefik can handle monitoring that many files in a directory.

I don't have the answer yet. Writizzy is nowhere near that scale for now. There might be other solutions, like using Caddy instead of Traefik in Coolify, but it's way too early to explore that.

I recently had the chance to discuss this with several CTOs during an informal meetup, and I wanted to share what came out of it.

AI is a hot topic for pretty much everyone because, whatever your opinion on it, you can't just sweep it under the rug. Clients talk about it, employees talk about it (positively or negatively), and some competitors are using it.

This led to several discussions:

• What's the concrete impact of AI for a dev agency in 2025?
• Is it a bubble? And what if it bursts?
• How do you get your teams to adopt AI? Is it an individual choice or a company mandate?
• How can AI be necessary yet nauseating at the same time?

I'll try to capture these discussions here. To preserve anonymity, all names are fictional.

Impact of AI for a Dev Agency in 2025

I spoke with the head of a dev agency (let's call him Chris) for whom AI has been a game-changer, with a real company-wide adoption policy.

I'll keep it brief to avoid distorting what I heard:

• AI has impacted every aspect of the business: contracts, development, support, etc.
• The agency does way more fixed-price projects and less time & materials. Billing by time spent no longer makes sense. They now prefer billing based on impact and value delivered.
• They can now commit to smaller fixed-price contracts because margins have increased and risk has decreased.
• They're starting to see bottlenecks on the client side. Devs are now faster than clients can express their needs.
• They're increasingly having 1 dev per client, which isn't great for service continuity. But with two devs, there's not enough work.
• The design phase has become more important, with solid documentation to capture requirements. That's what feeds the AI afterward (which also helps refine the docs).
• Consequence of the above: it's the first time since the company was founded that this much documentation has been produced, with good quality.
• He's had discussions with senior lead devs who've seen their job change and initially doubted whether they'd still enjoy their work. So far, these people have learned to love their new job.
• It's hard to hire juniors because working with AI to build applications requires the hindsight to know how to code things yourself, read code, spot flaws, etc. There's a real "AI wall" for newcomers.
• Overall, the agency is making better margins. But also because competitors haven't caught up yet. Chris thinks it'll rebalance once more competitors adopt the same working methods.
• He has no problem involving clients and doesn't hide the use of AI. It's still a tool, but it's their methods and expertise that make it deliver satisfying results.

How to Get Your Teams to Adopt AI

This topic is rich, and I'd already seen it come up on Slack.

The question could be framed like this:

Some devs don't use AI on the team despite demo sessions, coaching, etc. How do you convince them?

The discussion raised many points, but it boils down to two questions:

• Should you force people?
• What reasons do these devs give?

For the second question, the reasons can be summarized as:

• Environmental concerns
• Feeling like the job has lost its meaning
• Fear of losing skills

On the first point, nobody really wanted to go there. I didn't respond in the discussion either, maybe for fear of coming across as the resident cynic. But with hindsight, I'll use this post to share my thoughts. Sure, it might not please everyone, but I'm afraid it might come true.

Let's start with this hypothesis: If AI does in 5 minutes what an engineer would have done in several hours/days, the environmental equation strongly favors AI.

To support this, I'll use numbers I calculated in another blog post:

The average time to produce concept art varies between artists but is generally around 15 hours with Photoshop. That's 1500Wh — more than 300 times the cost with AI.

For equivalent tasks, AI is more environmentally friendly than a human worker. Obviously, one could argue that if we go faster, we'll produce more. The developer will work a full day regardless, so they'll consume more over the day.

Yes, a dev will consume more. If that's all they do, which is already optimistic.

But if headcount drops by 30 or 40%, the equation becomes positive again.

And I'm afraid nobody says this too loudly because the implications are heavy.

There will be two scenarios:

1. Dysfunctional companies where people take 3 weeks for simple tasks and spend part of their time hiding at the coffee machine or in useless meetings. If these people use AI, they'll just spend more time on the rest. And that'll save energy. Yes, it's a bit provocative, but I know these companies exist, and I'm not being cynical here. I told you I'd be blunt...
2. Companies that pursue productivity. These companies will keep their most effective people but will reduce headcount because demand won't keep up. It's hard to hear, I get it. But it's going to happen.

I'm afraid that people who hold back for environmental reasons will end up getting their way... by losing their jobs.

And I want to be clear: I don't wish this on anyone. I'm following a line of reasoning that seems important to address. You can hate the messenger. But it's the message that should interest you.

Then come the other two topics:

• Loss of meaning
• Loss of skills

From the various discussions I've had, everyone seemed to reach the same conclusions: yes, the job is changing. It's much more about design, with heavy emphasis on architecture and the ability to formalize it. Many people end up enjoying it. But not everyone does, and that's partly what creates the resisters.

Now we get to the thorny question:

Should you force people?

Opinions diverge quite a bit between those who think it should be a personal choice, like choosing your IDE.

The reflection is valid, but the "mandatory" aspect isn't justified in my view. Some tools are constraints: versioning, unit testing, etc. Others should be left to the dev's discretion: IDE, StackOverflow, Reddit, etc. AI, for me, falls into the second category.

And others who think it can no longer be optional, no more than refusing to use version control.

I understand your points, but I place AI at a different level than a simple tool. Today, if a dev uses VSCode, I don't force them to use IntelliJ (or anything else), but not using an IDE at all would seem pretty strange.

I didn't see any consensus emerge from the groups discussing this topic. But one phrase stands out for me as a conclusion:

Developers who don't want to use AI need to understand that their performance will be evaluated against people who do use it. If they're just as performant without it, fine. Otherwise, they're facing a problem they need to solve on their own, right?

From this discussion came a question: OK, but if we all switch to AI and the bubble bursts, what do we do?

Is It a Bubble? And What If It Bursts?

I find this question very relevant. What happens in 2 or 3 years if the AI bubble bursts like the dot-com bubble in 2000? Will we be able to go back to our old work habits?

On the "bubble" aspect, the consensus seems widely shared, and the current period feels a lot like 2000.

In 2000, simply renaming your company with a ".com" could make stock valuations explode, even if the company had nothing to do with the web. To raise money, you had to find a link — real or not — to the internet. Today it's the same with AI. More than half of investments involve AI. I get contacted every week by companies that will "revolutionize sector X or Y" with AI.

Every. Single. Week.

So yes, the consensus is shared: many companies riding the AI wave will crash. And potentially not just small ones. But there's a second consensus: AI won't die with the bubble, just as the web didn't die in 2000.

Given the massive adoption of code assistance tools, there's little chance they'll disappear, especially since open-source models already exist. And some imagine it'll be possible to maintain specialized code models for less than today's big generalist models. A profitable economic equation will emerge, at least for this niche.

Nobody's a fortune teller, as one participant pointed out, but I tend to think the probability of AI completely disappearing seems unlikely.

How Can AI Be Necessary Yet Nauseating?

I'm not even sure this chapter is necessary since it seems so obvious, but everyone seems equally intrigued and suffering from indigestion on AI topics. Sure, everyone uses it, but just like everyone uses a keyboard — that's not enough for it to be the ONLY topic of conversation.

Yet:

• It's hard to raise money without saying you're doing AI
• There are tons of company pitches constantly talking about AI, but when you dig a little, there's nothing credible if you're being serious
• It's annoying to see tech conferences with 95% of talks on AI, with some competition in hot air (beginner tutorials, far-fetched topics, etc.)

So yes, it's paradoxical: it's the topic of the moment, and at the same time, everyone's saturated.

Anyway, we talked about all this (not just this, don't worry) and I hope this little summary was interesting to you.

That's probably the wrong question.

Why would you want to be?

"Why" is the better question.

Being dependent on any single country means taking risks with your own freedom of expression and security.

Europe has always been influenced by the US, but that country has now become hostile. Recent events have shown us the real risks of this dependency:

• Multiple scandals involving social networks—X and Facebook—used to influence European elections
• Grok, Musk's AI, repeatedly generating hateful content
• Sanctions against the International Criminal Court investigating potential war crimes in Gaza

Overnight, ICC judges found themselves cut off from the global economic system—largely controlled by Visa, Mastercard, and American Express. Their accounts on all US platforms were shut down (Amazon, Airbnb, PayPal, you name it). Even non-American banks closed their accounts to avoid violating US rules.

At the same time, the entire ICC administration was cut off from their tools—emails, documentation, everything.

I could also mention the National Security Strategy published two days ago. This report explicitly states the intent to influence domestic politics in European countries.

Steve Bannon, Trump's advisor, created a foundation in Brussels with the goal of weakening the European Union by uniting far-right parties across Europe around a common goal: "maiming the European Union."

This isn't paranoia. It's a documented and official strategy. European tech dependency isn't just a theoretical risk—it's being actively exploited as a geopolitical lever.

Going 100% European seems hard to achieve, but everyone can take small steps to shift the balance by using more non-US solutions.

Back in April, I tried to list all the services I depended on calculating my tech dependency score.

Since then, I've made progress:

• Switched to Proton for email, document storage, VPN, and password management. Proton has grown 5x in users over the past 4 years.
• Left X, and soon Facebook (just waiting to post this article there before I do)
• Stopped using Airbnb entirely—Booking only

It's still far from perfect. It's really hard to quit Amazon, LinkedIn, and even harder when it comes to entertainment—Netflix, YouTube, Crunchyroll. The US dominates.

But technically, nothing prevents us from having a decentralized, non-US LinkedIn.

We're starting to see interesting things emerge, leveraging decentralized protocols like Mastodon's ActivityPub or Bluesky's AT Protocol:

• Instagram alternatives: Pixelfed (ActivityPub), Sprk.so, Flashes and Pinksky (AT Protocol)
• Reddit alternative: Lemmy (ActivityPub)
• TikTok alternative: Skylight (AT Protocol)
• YouTube alternative: PeerTube (ActivityPub)
• An initiative to create a European PDS for Bluesky, removing dependency on the sole US-based PDS

EDIT: There's a great directory of AT Protocol alternatives here: https://blueskydirectory.com/

It's far from perfect. A social network needs critical mass to become attractive. Some of these initiatives are nowhere near replacing their big sisters.

But technology is no longer a barrier.

And that alone is good news. Because the day we get cut off, we'll know how to manage without. But we shouldn't wait for that moment.

This is the responsibility of everyone who builds apps or decides which ones to buy for their companies.

I work in software development. I set myself a goal: avoid US tools as much as possible when building new projects.

Last month, I started a new app: Writizzy. The project itself is an attempt to offer an alternative to US platforms like Substack, Medium, or WordPress.

I managed to use mostly non-US alternatives:

• Hosting on Hetzner servers (Germany)
• Coolify as a self-hosted PaaS (Hungary)
• CDN and web storage on Bunny.net (Slovenia)—one of my favorites, easily replaces Cloudflare and goes way beyond just CDN
• DNS on Hostinger(Germany), gradually moving to Bunny.net
• Transactional emails on Brevo(France)
• Email accounts for me and Thomas (my cofounder) on Proton(Switzerland)
• S3 storage on Scaleway (France)

I still have some pain points:

• Stripe. Hard to replace with something equally simple and affordable. I should probably look at Paddle (UK), but payment infrastructure isn't something you switch easily.
• GitHub. I don't know any obvious alternatives. GitLab is also US-based. Bitbucket (Australia) might work, but it's felt half-dead for a while. This is less critical than payments—switching providers would be straightforward. I need to find something.
• Claude Code. I have zero non-US alternatives to suggest. I could try DeepSeek, but swapping US influence for Chinese influence has its own risks. And Mistral wasn't up to par last time I tried. This one is genuinely bad news.

Anyway, if you're starting an app today, you owe it to yourself to think about this. Don't start on the wrong foundations.

Also understand: by using these services, you help them improve. They'll have the revenue and feedback to get better.

I get that this is a real handicap for legacy applications. I know the effort required to transform an existing app, especially with no direct financial gain. But you need to consider this as a risk factor.

Imagine what happens tomorrow when Trump decides to sanction your company because... whatever… he doesn't need a good reason. All of US Big Tech funded Trump and served him hors d'oeuvres at his inauguration. They're expecting returns on investment, and that will come through industrial espionage and/or blockades. Any European company can be targeted at any moment.

In public administrations, there's a growing movement to move away from Microsoft tools. In Germany, France, Denmark, Italy, and Spain, we're seeing administrations migrate to Linux, LibreOffice, Thunderbird, and more.

That's good news. But it needs to be followed by private companies—and for that, we need to be more ambitious about the quality of software we create. Naive sovereignty that just sells "being European" while delivering poor quality doesn't work.

So it's on us to make the right choices and be ambitious. Let's not wait until it's too late.

Looking closer, I noticed that each contact form submission was followed by a user signup with the same email and a name that always followed the same pattern:

qSfDMiWAiLnpYYzdCeCWd

fePXzKXbAmiLAweNZ

etc... Let's just say their membership in the human species seems particularly dubious.

Anyway, it's probably time to add some controls, and one of the most famous is the captcha.

Next-generation captchas

Everyone knows captchas – they're annoying, probably on par with cookie consent banners.

Nowadays we see captchas where you have to identify traffic lights, solve additions, drag a puzzle piece to the right spot, and so on.

But you may have noticed that lately we're also seeing simple forms with a checkbox: "I am not a robot".

Sometimes the captcha isn't even visible anymore, with detection happening without asking you anything.

So how does it work? And how can I add it to my application?

Nuxt Turnstile, the default solution with Nuxt

In the Nuxt ecosystem, the most common solution is Nuxt turnstile. The documentation is pretty clear on how to add it.

It's a great solution, but it relies on Cloudflare turnstile, and I'm trying to use only european products for Writizzy and Hakanai.

Still, the documentation helps understand a bit better how next-generation captchas work.

When the page loads, the turnstile widget performs client-side checks:

• **proof of space: **The script asks the client to generate and store an amount of data according to a predefined algorithm, then asks for the byte at a given position. Not only does this take time, but it's difficult to automate at scale.
• trivial browser detections: The idea is to try to detect a bot (no plugins, webdriver control, etc.). Fingerprinting also helps in this case. It collects all available info about the browser, OS, available APIs, resolution, etc.

Note that fingerprinting can be frowned upon by GDPR, which may consider it as uniquely identifying a person. Personally, I find that debatable, but in the context of anti-spam protection, we're kind of chasing our tail here since it would be necessary to ask bots for their permission to try to detect them. We're at the limits of absurdity here.

But let's continue. Based on the previous info, the script sends all this to Cloudflare. Based on this info and relying on a huge database of worldwide traffic, Cloudflare calculates a percentage chance that the user is a bot.

The form will vary between:

• nothing to do, Cloudflare is convinced it's a human
• a checkbox "I am not a robot"
• a more elaborate captcha if the suspicion is really strong
• a blocking page when there's no doubt about the suspicion

Now, you might say, the checkbox is a bit light, isn't it? If I've gotten this far, I can easily automate a click on a checkbox. Especially since Cloudflare is everywhere, it's necessarily the same form everywhere.

Yes... But...

First, the way you check the box will be analyzed. Is the click too fast, does it seem automated, is the mouse path to reach the box natural? All this can trigger additional protection.

EDIT: Turnstile might not do this operation. reCaptcha, Google's solution, is known for doing it. Turnstile is less explicit on the subject.

But on top of that, the checkbox triggers a challenge, a small calculation requested by Cloudflare that your client must perform. The result is what we call a proof of work.

This work is slow for a computer. We're talking about 500ms, an eternity for a machine. For a human user, it's totally anecdotal. And the satisfaction of having proven their humanity makes you forget those 500 little milliseconds.

On the other hand, for a bot, this time will be a real problem if it needs to automate the creation of hundreds or thousands of accounts.

So it's not impossible to check this box, but it's costly. And it's supposed to make the economic equation uninteresting at high volumes.

Now, even though all this is nice, I still don't want to use Cloudflare, so how do I replace it?

Altcha, an open-source alternative

During my research, I came across altcha. The solution is open source, requires no calls to external servers, and shares no data.

The implementation requires requesting the Proof of Work (the famous JavaScript challenge) from your server. Here we'll initiate it from the Nuxt backend, in a handler:

typescript

// server/api/altcha/challenge.get.ts
import { createChallenge } from 'altcha-lib'

export default defineEventHandler(async () => {
  const hmacKey = useRuntimeConfig().altchaHmacKey as string

  return createChallenge({
    hmacKey,
    maxnumber: 100000,
    expires: new Date(Date.now() + 60000) // 1 minute
  })
})

In the contact form page, we'll add a Vue component:

vue

	<ClientOnly>
	  <Altcha
		v-model:payload="altchaPayload"
	  />
	</ClientOnly>

This altchaPayload will be added to the post payload, for example:

typescript

    await $fetch('/api/contact', {
      method: 'POST',
      body: {
        email: loggedIn.value ? user.value?.email : event.data.email,
        subject: event.data.subject,
        message: event.data.message,
        altcha: altchaPayload.value
      }
    })

The calculation result will then be verified in the /api/contact endpoint

typescript

    const hmacKey = useRuntimeConfig().altchaHmacKey as string

    const ok = await verifySolution(data.altcha, hmacKey)
    if (!ok) {
      throw createError({ statusCode: 400, message: 'Invalid challenge' })
    }

The Vue component I mentioned earlier is this one:

vue

<script setup lang="ts">
import { onMounted, onUnmounted, ref, watch } from 'vue'

const altchaWidget = ref<HTMLElement | null>(null)
const props = defineProps({
  payload: {
    type: String,
    required: false
  }
})
const emit = defineEmits<{
  (e: 'update:payload', value: string): void
}>()
const internalValue = ref(props.payload)

watch(internalValue, (v) => {
  emit('update:payload', v || '')
})

const onStateChange = (ev: CustomEvent | Event) => {
  if ('detail' in ev) {
    const { payload, state } = ev.detail
    if (state === 'verified' && payload) {
      internalValue.value = payload
    } else {
      internalValue.value = ''
    }
  }
}

onMounted(() => {
  const script = document.createElement('script')
  script.src = 'https://cdn.jsdelivr.net/gh/altcha-org/altcha@main/dist/altcha.min.js'
  script.type = 'module'
  document.head.appendChild(script)

  if (altchaWidget.value) {
    altchaWidget.value.addEventListener('statechange', onStateChange)
  }
})

onUnmounted(() => {
  if (altchaWidget.value) {
    altchaWidget.value.removeEventListener('statechange', onStateChange)
  }
})
</script>

<template>
  <altcha-widget
    ref="altchaWidget"
    challengeurl="/api/altcha/challenge"
    hidelogo
    hidefooter
    style="--altcha-max-width:100%"
  />
</template>

And there you go, the contact page and the signup page are now protected by this altcha.

Now, does it work?

Altcha's limitations

The implementation was done yesterday. And unfortunately, I'm still seeing very suspicious signups on Pulse. So clearly, Altcha didn't do its job.

However, now that we know how it works, it's easier to understand why it doesn't work.

Altcha doesn't do any of the checks that Turnstile does:

• no proof of space
• no fingerprinting
• no fingerprint verification with Cloudflare
• no behavioral verification of the mouse click on the checkbox.

The only protection is the proof of work, which only costs the attacker time.

Now for Pulse, for reasons I don't understand, the person having fun creating accounts makes about 4 per day. The cost of the proof of work is negligible in this case.

So Altcha is not suited for this type of "slow attack".

Anyway, I'll have to find another workaround... And I'm open to your suggestions.

But it didn't start this way. It started in 2007 with a book about freedom and time. Tim Ferriss's "4-Hour Work Week" wasn't really about working 4 hours - it was about reclaiming your time to pursue what matters.

Somehow, we turned that into a movement obsessed with "passive income" and easy money. I co-founded Malt in 2013, a freelance marketplace that grew to 700 people across Europe. I can tell you: you don't build that working 4 hours a week. But I can also tell you where this whole thing went wrong.

The Origins: Millennials vs. The 9-to-5

Remember the 2008 financial crisis? It hit the entire world. In the US, unemployment soared. But beyond the economic crisis, it marked something bigger: the millennial generation questioning their relationship with work. The 2000s signaled a break from the myth of lifetime employment and a general rejection of the traditional 9-to-5 grind. The social contract was broken, so many people decided to go their own way.

It's in this exact context, in 2007, that Tim Ferriss released "The 4-Hour Workweek."

And the story he told resonated with a lot of people.

His idea: automate your business, make yourself unnecessary, and then go live through your "muses" - personal pursuits that truly matter to you.

For a whole generation of tech-savvy readers, this was a revelation. If you can automate your work - something totally within reach for people in software - you can escape the alienating constraints of traditional employment. You can automate your income and live somewhere with a lower cost of living.

Tim Ferriss in 2007 had just popularized digital nomadism and the concept of passive income.

In short, Tim Ferriss became a solution to all the generational frustrations of millennials and soon Gen Z too.

And since then, many others have followed. But has his legacy remained intact? Well, not exactly.

The Indie Hackers Era

In 2010, I went freelance. But I quickly realized I enjoyed building products, largely inspired by startup culture - though it was still young in France at the time.

One book inspired me above all: "Rework."

Rework was a shot fired across the traditional working world, questioning all standard work habits. It demolished presenteeism, meeting culture, and basically everything that characterized old-school corporate employment.

Following Rework, in 2013 came the second installment: "Remote," which, as the name suggests, dealt with remote work.

Our relationship with work needed to change, I was convinced of it. In this context, I first created Lateral-Thoughts, then Malt in early 2013.

But parallel to this startup movement, another more frugal movement was launching.

Also in 2013, Jennifer Dewalt set herself a challenge: build 180 websites in 180 days to learn programming. This challenge got a lot of attention and sparked a new trend, later taken up by a young Dutch guy who would attempt to create 12 startups in 12 months: Pieter Levels.

This young Dutchman, expatriated in Asia, was one of the first proto-digital nomads. The solopreneur/digital nomad movement was officially launched, represented for a long time by this famous Pieter.

And this movement would soon take on a new name, a new identity.

People creating software solo, without external funding, existed before but it was still anecdotal and scattered. Then in 2016, Courtland Allen created the Indie Hackers website and everything changed. He gave the movement a name, created a community, and above all, normalized something radical: publicly sharing your revenue, failures, and strategies.

This was the origin of what we'd call "building in public."

It wasn't new - I've been blogging since 2001 myself - but it would establish a culture of transparency...

Except that it also created a playbook for faking success.

And that's maybe where everything went off the rails.

The Shovel Sellers

Between 2013 and 2024, I was far from all this. I was building a company that would grow to 700 people and cover all of Europe. Far from the 4-hour work week.

But in 2024, I chose to change paths and return to my roots, back to my freelance beginnings and my early inspirations when I read Rework and Remote.

Except that in the meantime, the landscape had drastically changed.

The floodgates opened. First no-code, now AI. Anyone can build software. And Tim Ferriss's "passive income" concept morphed into an obsession: SaaS, the holy grail that supposedly generates revenue while you sleep. Except it doesn't work that way. But that won't stop people from selling you courses on how to build one.

::gallery ::

To support this mirage, we see fake screenshots showing fake revenue, fake Stripe notification popups, fake dashboards - everything aligned with one of the mantras from the startup world: "Fake it until you make it."

And the worst part? Others started seeing the opportunity. The best thing isn't selling shovels - it's running the bar where everyone comes to drink in the evening. Selling alcohol to the shovel sellers.

Because now you can buy the app that lets you create fake dashboards, fake payment notifications, fake analytics panels - everything I just mentioned. Not to mention courses teaching you how to sell courses on creating SaaS products. And now there are even apps designed to prove your MRR isn't fake.

Does it sound a bit like a Ponzi scheme? Maybe.

But more importantly, beyond all that, when I say the indie hacker movement has lost its way, there's one thing I especially want to talk about.

Many have lost sight of one of the key concepts Tim Ferriss talked about.

What Everyone Missed

In 2010, as I said, I went freelance. And one of my first motivations was, let's say, somewhat financial.

Except that in my first year, I probably chased that too much. I worked way too much and yes, I had a great year financially, but I burned out. Simple as that.

Starting in 2011, I had a revelation and completely changed my approach. I set a maximum income threshold for myself.

My goal became to earn less, which would by default make me work less.

Because at that moment, I realized something: by going freelance, what I'd really gained wasn't the possibility of having more money, but the possibility of having more time.

And that's what Tim Ferriss talks about - the new wealth is time. It's time that allows you to pursue your muses.

Ferriss wanted to free himself from the constraints of salaried employment to dedicate himself to his muses. Whether it's tango, Sanda, or breakdancing for Tim Ferriss, it's hard to say he didn't work hard at those things. But in an unpaid way.

In reality, Tim Ferriss was working far more than 4 hours a week, just not in the traditional sense.

For a large majority of the current indie movement, the relationship with work has become toxic.

For every one Pieter Levels, there are hundreds of thousands of others who earn nothing and have no interest in what they're building which creates tons of soulless applications (yet another to-do app, yet another AI wrapper…).

Between the stress of results that never come and time consumed on topics that don't excite them, it's far from the dream sold by their guru.

The Point

Tim Ferriss's book wasn't so much about money as it was about the search for freedom - freedom over your time. Not to do nothing, but to work on finding meaning for yourself and for others.

And that's probably where the current movement has lost its way.

The indie hacker movement became a cargo cult. Everyone's copying the surface-level metrics (MRR! Growth! Passive income!) without understanding what made the original builders successful: they gave a shit about what they were building.

So before you let yourself be seduced by indie hacking, think carefully about the reasons driving you to do it.

If it's purely for financial reasons, the statistics aren't in your favor, and freelancing is much better suited.

But if the product you want to create is important to you, if it has meaning for you, then the game might be worth the candle.