DEV Community: hugo lassiege

My AI stack for developing products without breaking the bank

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

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

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

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

What is Writizzy?

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

Code-wise, we have three big pieces:

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

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

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

Context Engineering: Constraining the AI

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

The Claude.md file

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

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

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

The Rules (.claude/rules)

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

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

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

Example of a question I recently asked him:

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

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

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

The "Analyst" command

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

Specs before code

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

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

With AI, the spec has two major interests:

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

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

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

The art of managing your context window

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

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

Skills vs MCP: The efficiency battle

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

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

I have skills for different things:

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

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

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

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

So I prefer Skills, except for:

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

What about design?

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

Balance sheet: How to stick to the budget?

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

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

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

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

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

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

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

AI and Ecology, Fantasy or Convenient Scapegoat?

hugo lassiege — Mon, 13 Jul 2026 13:12:22 +0000

It's hard to talk about AI these days. I've rarely, if ever, seen a subject so polarized in tech.

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

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

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

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

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

Ecological Impact of AI

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

This impact falls into several categories:

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

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

Electrical consumption during training

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

To put that into perspective:

Model	CO2 Equivalent	Paris-New York Round Trips	Annual US Household Consumption	Annual French Household Consumption
Smaller/open modelDeepseek, Lama etc…	~500 tonnes	370	130	2,100
Claude, Codex etc…	~12,000 tonnes	8000	3,200	50,000

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

Electricity Consumption During Usage

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

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

Water consumption

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

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

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

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

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

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

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

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

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

Resource extraction

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

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

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

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

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

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

AI vs. Other Digital Habits

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

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

AI vs Internet

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

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

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

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

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

AI vs gaming vs streaming vs video call

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

1 hour of gaming	1 hour of streaming	1 hour of video call	1 hour of dev with AI
50g CO2 (source greenly)	55 to 100g of CO2 (source IEA and netflix)	30 to 60g of CO2 (source ubigreen)	30 to 140g of CO2 (source idleforest)

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

In other words:

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

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

What About Creation Costs?

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

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

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

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

So, is AI Not That Serious After All?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What About the Explosion of Data Centers?

A question I asked myself before writing this article was:

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

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

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

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

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

Forecasts vs. Financial Bubbles

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

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

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

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

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

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

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

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

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

Are We in the Era of Shitty Code?

hugo lassiege — Fri, 03 Jul 2026 07:28:34 +0000

There isn't a day that goes by without discovering a major security flaw or data breach somewhere.

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

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

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

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

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

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

The Rise in CVEs

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

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

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

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

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

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

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

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

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

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

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

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

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

With AI, It's the Death of Craft

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

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

Wait, here we have two different subjects:

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

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

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

AI Slop and Software Maintenance

Do you know Dave Farley?

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

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

(okay grandpa but continue your story)

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

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

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

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

Building an Agentic Software Factory

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

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

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

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

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

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

Anyway, you need the other tools.

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

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

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

Craft hasn't disappeared. It has changed.

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

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

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

The Writizzy Example

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

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

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

Well today I'd say that it shows.

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

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

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

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

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

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

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

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

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

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

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

The Transactional Outbox Pattern with PostgreSQL and RabbitMQ

hugo lassiege — Sun, 28 Jun 2026 15:34:48 +0000

How do you write to two different systems, for example RabbitMQ and PostgreSQL?

You might say it's pretty straightforward.

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

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

Two-phase commit transactions

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

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

But there are several problems.

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

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

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

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

$0.99 \times 0.99 = 0.9801$

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

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

The transactional outbox pattern

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

The concept is "simple":

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

The code becomes

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

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

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

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

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

And you need the publication service code


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

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

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

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

And... you're not wrong.

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

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

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

Here strategies are multiple:

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

etc...

And error handling?

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

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


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

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

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

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

Challenging your own developer beliefs with AI

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

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

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

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

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

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

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

How I Do Design as a Backend Developer

hugo lassiege — Thu, 25 Jun 2026 07:40:54 +0000

Imagine the place. It's dark, it's only 6pm but winter and cold have arrived.

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

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

And then I get up and introduce myself.

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

Basically, I'm terrible at design.

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

2011, the army of clones

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

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

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

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

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

From atomic design to design systems

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

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

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

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

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

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

Tailwind and design tokens

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

And it's rather simple to express globally:

.button { border-radius: 4px; }

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

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

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

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

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

For example:

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

etc...

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

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

My pre-2024 workflow, Tailwind and its component libraries

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

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

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

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

And then came AI

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

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

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

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

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

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

First, what is Claude Design?

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

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

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

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

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

In short my workflows are as follows:

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

And more recently, I'm testing:

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

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

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

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

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

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

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

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

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