DEV Community: Frédéric Guariento

Alert on staleness, not on health

Frédéric Guariento — Thu, 05 Nov 2026 12:19:04 +0000

For eleven days this summer, my secondary DNS server answered every query, passed every health check, and enforced a configuration that was quietly going out of date. Nothing was down. That was the problem.

My Park network runs two AdGuard Home instances: a primary on a virtual machine, a replica on my NAS. A small sync container copies the primary's configuration (blocklists, custom rules, client settings) to the replica every thirty minutes.

On 17 July I changed one port binding on the primary so that its admin interface would be reachable from the LAN instead of only through an SSH tunnel. Docker replaces a port binding; it does not add a second one. The address the sync container relied on, the VM's own loopback, stopped listening. Every thirty minutes the sync tried, received "connection refused", wrote one line to its log, and waited for the next run.

The sync container stayed up. Both DNS servers stayed up. Both answered queries. Everything I watched measured liveness, and everything was alive.

On 27 July, a log analyzer that reads container errors flagged the repeated failures. Once the address was fixed, the first successful sync took 9.1 seconds and pushed eleven days of drift to the replica: a new blocklist, nine user rules, a blocked-services schedule and a client definition. For eleven days, half of my DNS had been applying an older policy than the one I believed was in place.

Health was the wrong question. A health check asks: do you respond? The question that mattered was: when did you last do your job? Those are two different signals, and only the first one comes for free.

Three rules I took from it:

Alert on the age of the last success, not on the presence of a process. A job meant to run every thirty minutes that has not succeeded for two hours is broken, whatever its container status says.
Let the job record its own success. The job writes when it last finished well; the alert compares that time with the expected interval. The monitor should not have to guess.
Treat silence as a finding. No errors from a job that should run every half hour can simply mean it never ran.

I have started applying this beyond DNS. One example: a check on the age of the last completed Time Machine backup, rather than on whether the backup service is running. A backup that is configured but has not completed recently is not a backup.

None of this is specific to a homelab. Database replicas, threat-intelligence feeds, antivirus signatures, the documents behind a search index: each can be reachable and stale at the same time, and a green dashboard will not tell you which.

In my case, the fix was a single line. Finding it took eleven days, because nothing I measured was designed to notice that time was passing.

What in your infrastructure is up, healthy, and quietly out of date?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Les trois obligations du NIS2 que tout le monde minimise

Frédéric Guariento — Thu, 29 Oct 2026 11:59:17 +0000

NIS2 : les trois obligations que tout le monde minimise

Vous avez lu le texte. Vous avez coché les cases. Votre déclaration de conformité est prête. Et pourtant, dans six mois, votre audit révélera des failles que ni vous ni votre CISO n'aviez identifiées. Qu'est-ce qui a échappé au radar ?

Le NIS2 n'est pas une checklist. C'est une mutation de notre rapport à la cybersécurité, et trois de ses exigences sont systématiquement sous-estimées — pas par ignorance technique, mais parce qu'elles heurtent nos habitudes organisationnelles. Je les ai vues passer au travers chez des acteurs pourtant avertis, des infrastructures critiques aux opérateurs de services essentiels. Voici ce que le décret belge d'octobre 2024 rend incontournable, et pourquoi cela change tout.

La gouvernance, pas la technique

Première illusion : penser que la sécurité opérationnelle suffit. Le NIS2 exige une gouvernance à trois niveaux — direction, CISO, et management — avec une responsabilité personnelle des dirigeants en cas d'incident majeur. Ce n'est plus une question de budget IT. C'est une question de culture du risque au conseil d'administration.

J'ai assisté à des réunions où la cybersécurité tenait quinze minutes en fin d'ordre du jour. Ce temps est révolu. L'article 20 impose une supervision active, des ressources dédiées, et une formation continue. Le décret belge précise : absence de mesures = responsabilité pénale des mandataires. Votre CA est-il prêt à signer une attestation de prise de conscience ?

La chaîne logistique, pas votre périmètre

Deuxième angle mort : vos fournisseurs. Le NIS2 étend l'obligation de sécurité à toute la chaîne de valeur. Vos sous-traitants, vos hébergeurs cloud, vos éditeurs de logiciels — vous devez en garantir la résilience.

Dans mon environnement, cela prend une forme concrète. Mon GPU local, une RTX 4070 Ti de 12 Go, héberge des services critiques via Ollama et LiteLLM. Aucun cloud externe pour l'inférence sensible. Mais mes conteneurs Docker ? Ils tirent des images de registres que je ne contrôle pas. Ma base vectorielle Qdrant ? Je dois en vérifier les mises à jour de sécurité comme je le ferais pour un équipement réseau. Le NIS2 me rend responsable de cette chaîne, même lorsque je déploie en interne.

Le décret belge parle d'évaluation des risques liés aux relations de fourniture. Traduction opérationnelle : inventorier, classer, contractualiser, vérifier. Combien d'entreprises ont une cartographie complète de leurs dépendances tierces ?

L'incident, pas l'attaque

Troisième mécompréhension : confondre détection d'intrusion et gestion d'incident. Le NIS2 impose des obligations de notification strictes — 24 heures pour l'alerte initiale, 72 heures pour le rapport détaillé, un mois pour le rapport final. Ces délais sont irréductibles.

Mais le vrai défi n'est pas bureaucratique. Il est organisationnel. Avez-vous testé votre chaîne de crise ? Vos procédures d'escalade fonctionnent-elles un samedi soir ? Votre CISO peut-il joindre votre hébergeur cloud à 3 heures du matin ?

Je gère mon infrastructure domestique comme un laboratoire de résilience. Whisper sur CPU pour l'OCR, paperless-AI pour la classification, un auto-classifieur de Gmail — chaque service a un propriétaire, une procédure de secours, un temps de récupération cible. À l'échelle d'une entreprise, cette discipline est rare. Le NIS2 l'impose.

L'Europe contre elle-même ?

Une tension traverse le décret belge : ambition européenne, réalité nationale. La transposition laisse une marge d'interprétation que les États membres exploitent différemment. L'Allemagne durcit. La France précise. La Belgique ? Elle crée un cadre, mais la mise en œuvre opérationnelle reste en construction.

Nous préférons éviter les vérités inconfortables : le NIS2 coûte cher, demande des compétences rares, et expose juridiquement ceux qui ne s'y conformeraient pas. L'ANSSI belge, reconfigurée en Centre de Cybersécurité, manque de moyens pour accompagner. Les entreprises moyennes, elles, manquent de CISO.

Et pourtant, c'est maintenant. La période de transition se rétrécit. Les premières sanctions — jusqu'à 1% du chiffre d'affaires mondial — ne sont plus théoriques.

À nous de jouer

Qu'est-ce qui bloque chez vous ? La gouvernance, la chaîne logistique, ou la réactivité incident ? Chacun de ces trois leviers demande des ressources, du temps, une culture du risque que nos organisations n'ont pas cultivée.

Mais le NIS2 a aussi une vertu : il oblige à la clarté. Plus d'excuses, plus de déni. La cybersécurité devient un sujet de direction, de stratégie, de survie.

Parler. Partager. Confronter. Comment avancez-vous sur ces trois fronts ?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Agentic ops in practice: what truly needs a human in the loop, measured

Frédéric Guariento — Thu, 22 Oct 2026 13:28:18 +0000

Agentic ops in practice: what truly needs a human in the loop, measured

When we hand over a decision to an autonomous agent, do we really know where the safety net ends? Can a single RTX 4070 Ti, a handful of Docker containers and a flat‑rate Claude subscription guarantee that the “human‑in‑the‑loop” (HITL) moment will happen exactly when it should?

The answer is: we must measure it. Not just in vague “it feels right” terms, but with concrete metrics that survive the jump from a home‑lab proof‑of‑concept to a production‑grade service. We are at a crossroads where the temptation to automate everything collides with the reality of limited hardware, privacy regulations and the ever‑present risk of an algorithmic misstep.

In my own setup, the core of the stack is a consumer‑grade NVIDIA RTX 4070 Ti (12 GB VRAM, ~285 W) that runs Ollama locally. The models that comfortably fit – Llama 3.1 8B, Mistral 7B, Llama 3.2 3B – give us token throughputs between 80 and 150 tokens per second. Anything larger spills over to the CPU and drops to a crawl of a few tokens per second. On the “frontier” side, I rely on Claude via Anthropic’s Max 5x plan, a flat USD 100 per month subscription that removes per‑token pricing from the equation. The rest of the ecosystem – LiteLLM as a routing proxy, Qdrant for Retrieval‑Augmented Generation (RAG), paperless‑AI for OCR, a Gmail auto‑classifier and Whisper running on the CPU – all live as Docker containers sharing that single GPU.

Why does this matter for HITL? Because every additional layer of automation consumes scarce VRAM, power and memory, and every extra model brings a new failure mode. Measuring where a human must intervene becomes a question of resource allocation as much as of ethics.

First, latency. An autonomous ticket‑routing bot that decides in 50 ms may look impressive, but if the decision triggers a security rule change, a 200 ms human verification window can be the difference between a prevented breach and a full‑blown incident. We can quantify this by tracking the end‑to‑end response time of each pipeline stage and defining a “human‑reaction budget” – the maximum latency we are willing to accept before a human must be prompted.

Second, error rates. In my Gmail auto‑classifier, the model flags 1 % of incoming messages as “sensitive”. However, a manual audit of the last 1 000 flagged mails revealed a false‑positive rate of 12 % and a false‑negative rate of 3 %. Those numbers translate directly into human workload: each false positive costs a reviewer a minute, each false negative a potential compliance breach. By logging true‑positive, false‑positive, true‑negative and false‑negative counts, we can compute precision, recall and the F1‑score, then set thresholds that trigger a HITL alert when precision drops below, say, 85 %.

Third, policy complexity. Autonomous agents excel at deterministic rule‑following, but they stumble when policies overlap or evolve. Consider a data‑loss‑prevention (DLP) rule that blocks outbound PDFs containing personal data. If a new regulation adds a clause about “synthetic data”, the model may not recognise the nuance. Here the metric is not latency or error rate but “policy‑conflict frequency”: the number of times the agent’s decision conflicts with a policy engine’s latest version. A spike in this metric is a clear signal that a human review queue must be opened.

Fourth, security exposure. Running a large language model locally means that prompts and responses travel through the same memory space as other containers. Any container escape could expose confidential prompts – a risk amplified when the model processes emails or internal tickets. The metric we track is “container‑isolation incidents per month”, derived from audit logs of Docker security events. As soon as the incident rate exceeds a predefined low threshold, we enforce manual validation for any operation that touches sensitive data.

Fifth, cost and sustainability. My flat‑rate Claude subscription removes per‑token accounting, but the GPU’s power draw is not free. By measuring GPU utilization (percentage of the 285 W cap) and correlating it with the number of queries served, we obtain a “energy‑per‑token” figure. When the energy cost of a fully automated pipeline exceeds the combined cost of a partially automated one plus human review, the economics clearly favour a HITL approach.

All these dimensions – latency, error rates, policy‑conflict frequency, security incidents and energy cost – can be combined into a single “human‑necessity score”. A simple weighted sum (with higher weight on security and compliance) yields a numeric value that, once it crosses a configurable threshold, automatically opens a review ticket in the workflow management system.

The practical upshot is that we no longer rely on intuition to decide where the human sits. Instead, we let the data speak. In my own environment, the first iteration of this score showed that the Gmail auto‑classifier needed human review for only 0.3 % of daily mail, while the RAG system built on Qdrant required human validation for roughly 2 % of queries – those that returned a similarity score below 0.6 or matched no documents at all. By tightening the similarity threshold, we reduced the RAG HITL load to 1 % without noticeable loss of answer quality, as measured by user satisfaction surveys.

What does this mean for anyone trying to scale agentic ops beyond a homelab? First, start with a baseline measurement. Log every request, every model inference, every policy check and every human intervention. Second, define clear thresholds for each metric based on the risk appetite of your organization – compliance teams will often set stricter limits than a pure‑tech team. Third, iterate. As models improve (for example, when a new 8 B model that fits the RTX 4070 Ti’s VRAM becomes available), re‑measure the human‑necessity score; you may discover that the human load drops dramatically, freeing capacity for new use‑cases.

Finally, we must remember that measurement is not an excuse for complacency. Even a perfect score today can deteriorate tomorrow when regulations change, when a new threat vector emerges, or when the model’s training data drifts. The human element remains the ultimate arbitrator of ambiguity, ethics and responsibility.

So, are we ready to let agents run unchecked? Or will we accept the modest overhead of a well‑measured human‑in‑the‑loop to preserve security, compliance and trust? The data we collect today will answer that question tomorrow.

Let’s discuss: what metrics do you already track in your autonomous pipelines, and where have you found the most surprising need for human oversight?

AI #Automation #HumanInTheLoop #Cybersecurity #Ops #SovereignTech #AIethics #Metrics 🚀

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

AI Systems: MCP vs CLI – Which Interface Should You Trust?

Frédéric Guariento — Fri, 28 Aug 2026 18:05:48 +0000

What if the command line we've trusted for decades is quietly becoming the wrong abstraction for how AI systems actually need to work?

I've been running both patterns side by side in my homelab — one RTX 4070 Ti, twelve gigabytes of VRAM, thirty-four Docker containers competing for attention — and the friction between them keeps surfacing. Not as a theoretical debate, but as a daily architectural decision. When should a local model invoke a tool through structured protocol? When does a bash script still win?

The Model Context Protocol promises something seductive: universal, stateful, discoverable interfaces between AI agents and their capabilities. No more parsing brittle command outputs. No more regex archaeology on stderr. Just clean contracts, typed schemas, capabilities exposed as resources rather than executed as commands. Anthropic's push has momentum — Cursor, Claude Desktop, an ecosystem growing weekly.

Yet my production reality looks different. That same Ollama stack running llama3.1:8b at 84 tokens per second? It talks to Qdrant through HTTP, to paperless-AI through filesystem events, to my Gmail classifier through Python scripts that shell out to gcloud when OAuth tokens expire. The LiteLLM proxy in the middle doesn't care whether the downstream tool speaks MCP or CLI. It cares about latency, reliability, whether the container restart policy actually works at 2 AM.

Here's what the protocol evangelists rarely admit: MCP servers are still mostly thin wrappers around the same binaries they claim to transcend. Your filesystem MCP? It's calling stat and read underneath. Your PostgreSQL MCP? psycopg2 with extra JSON-RPC framing. The abstraction leaks immediately when you need streaming responses, when authentication expires mid-session, when resource limits hit and you need backpressure semantics that the protocol spec hand-waves away.

But the inverse critique cuts deeper. CLI tools compose beautifully in ways that resist formalization. Pipe grep into awk into xargs and you've expressed a computation no single MCP server captures without bespoke implementation. The Unix philosophy — small tools, clean interfaces, text as universal glue — emerged from constraints that haven't disappeared. They've just been relabeled as "technical debt."

So where does this leave us for production?

I see three fault lines that decide the question, at least for environments like mine where "production" means household infrastructure that must not break, not a datacenter with SRE rotation.

First, discovery versus stability. MCP's resource templating lets an agent enumerate available tools dynamically. This matters when your capability surface changes — new RAG collections, ephemeral sandbox environments, model versions that expose different quantized variants. But dynamic discovery introduces version skew. My CLI integrations are static, brittle, explicit. A broken script fails fast and loud. An MCP server with drifting schema fails in subtle ways, authentication tokens refreshing silently until they don't.

Second, observability and debugging. When my local stack misbehaves — and with 12 GB VRAM, misbehavior means context windows truncated, models falling back to CPU at 4 tokens per second, the thermal throttling you only notice when responses lag — I need to see the full chain. CLI tools leave traces: shell history, process trees, exit codes that actually mean something. MCP's JSON-RPC framing obscures this. The error you need is three hops deep in a server you didn't write, wrapped in protocol layers that assume success.

Third, the human-in-the-loop boundary. Claude via my flat Anthropic Max plan handles reasoning I won't run locally — too expensive in GPU time, too complex for 8B parameters. But when that reasoning needs to touch my infrastructure, which interface feels appropriate? MCP's session-oriented design assumes persistent context, state accumulation, the long conversation. CLI assumes discrete invocation, idempotency, the command that completes or doesn't. My production flows mix both: planning via frontier model, execution via local tools, with explicit handoff points I control.

What I'm building toward — not yet deployed, still evaluating — is a hybrid architecture that doesn't pretend either pattern is sufficient. LiteLLM already routes between local and remote; extending it to tag tool calls by interface type seems tractable. Some capabilities deserve protocol formalization: vector search with metadata filtering, multi-turn stateful interactions. Others deserve the simplicity of subprocess invocation: image conversion, PDF extraction, the Unix tools perfected over decades.

The deeper question beneath MCP versus CLI is about where we place trust in our AI systems. Protocols promise safety through specification. Command lines promise safety through transparency. Both promises break in production, but they break differently, and your recovery posture should match your breaking mode.

My RTX 4070 Ti doesn't care about elegance. It cares about memory pressure and batch size and whether the next token arrives before timeout. Your production environment likely has analogous constraints, whatever your scale. The right abstraction isn't the one that wins technical debates — it's the one that fails gracefully when your context window slams against the VRAM wall at 3 AM.

Which interface are you betting your reliability on, and have you tested it under real resource pressure?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Your RAG Answers From 62% of Your Corpus and Won't Tell You

Frédéric Guariento — Fri, 28 Aug 2026 18:05:16 +0000

Every retrieval system I have ever deployed has one property in common with every retrieval system you have ever deployed: it will answer. It will always answer. Ask it something that lives in a document it never ingested, and it will not say "I do not have that." It will find the nearest thing it does have, rank it, cite it, and hand it to you with the same confidence it would give a perfect match.

This is not a hallucination problem. The model behaved correctly. It answered from what it was given. The failure happened one layer down, in the boring part nobody demos: ingestion.

Last week I measured the corpus coverage of a self-hosted knowledge base I have been running for months. Nineteen hundred documents, semantic search, embeddings served locally, the whole pipeline built and monitored by me. I expected a number close to 100%.

I got 62%.

The number before the number was worse, and also wrong

My first measurement said 8.8%.

That number was real in the sense that a computer produced it. It was also useless, because I had divided the indexed documents by every markdown file on the volume — 13,257 of them — and 11,368 of those belong to entirely different collections that were never meant to be in this index at all.

Same system. Same afternoon. Two measurements. A factor of seven apart.

The honest denominator was 1,890 indexable documents, of which 1,169 were present: 62%. Both numbers were arithmetically correct. Only one described anything.

I want to sit on this for a moment, because it is the part that generalises beyond my homelab. A coverage percentage with an unstated denominator is not a metric. It is a vibe with a decimal point. Every ingestion dashboard I have seen in a commercial product reports documents processed. That is a numerator. It is presented as an achievement — 1,169 documents indexed, green check, ingestion complete — and the question it is quietly not answering is: out of how many, and who decided what counted?

If your vendor cannot state the denominator, your vendor is not measuring coverage. They are counting successes and calling it completeness.

The cause: a notification that never arrives is indistinguishable from nothing to do

The technical root was almost disappointing.

The indexer watched the filesystem with inotify. inotify does not cross NFS. Documents written from the machine running the indexer were seen instantly. Documents written from anywhere else — a laptop, another VM, a sync client — were never seen at all. Not delayed. Not queued. Never.

There is no error state for this. The watcher is healthy. It is watching. It reports zero events, because zero events reached it, and zero events is exactly what a quiet system looks like. Every dashboard stayed green while a quarter of the corpus quietly aged out of reality.

This is the shape of the whole class of bug, and it is worth naming precisely: file events are a notification, not a guarantee, and nothing in the stack is obliged to tell you that the notification never came. Any system built on "react when something changes" inherits a silent failure mode the moment the change happens somewhere the events do not reach. Object storage. Network shares. Container bind mounts. Sync clients that write to a shadow directory and rename. Each one breaks the assumption in its own way, and none of them raise their hand.

What actually fixed it

Two things, neither of them clever.

Polling instead of events. A 60-second sweep calling stat() on the tree. stat() crosses NFS, because it asks rather than waits. It is less elegant and less efficient than inotify, and it works. Verified end to end: a file touched from a different machine now appears in the index ninety seconds later. Before the change, the correct number was never.

Hourly reconciliation. Walk the source tree, walk the index, compare. Emit three counts: documents missing from the index, documents in the index whose source has changed, documents in the index whose source no longer exists. Missing, stale, orphaned.

The division of labour matters more than either mechanism: polling catches up, reconciliation proves. Polling is the repair. Reconciliation is the evidence that the repair worked — and, critically, it keeps producing that evidence after everyone stops paying attention. A fix without a standing measurement is a fix that will silently regress and take another few months to notice.

Coverage went to 1,890 of 1,890. The directory that had been at zero — 235 files of accumulated operational notes, the exact material the system existed to retrieve — was finally in there.

The bug that only showed up once I was looking

Fixing coverage surfaced something considerably worse, and this is the part I would most want a stranger to take away.

The embedding step returned a list of vectors. On failure, that list was compacted — the failed entry dropped. The caller zipped chunks to embeddings by position.

You can see it. One embedding timing out did not lose one section. It shifted every section after it by one. The text of section twelve was stored under the coordinates of section thirteen, and so on to the end of the document.

Searches kept working. Results came back ranked, cited, plausible, and attached to the wrong source. There is no test called "does search return results" that catches this, because search returned results the entire time. The only thing that catches it is deliberately asking a question whose correct answer you already know, and checking the citation rather than the prose.

Related, and cheaper than it sounds: I also excluded roughly 1,500 near-identical boilerplate chunks — template sections repeated across auto-generated reports. They were not missing data, they were crowding. A real query for a specific configuration rule now returns that rule at 0.792 similarity; before, three auto-generated reports sat above it at 0.66. Coverage is not only what is absent. It is also what is present so many times that it drowns the thing you needed.

What to measure on Monday

If you operate retrieval in production, these are cheap and none of them require a vendor:

Coverage with a stated denominator. Write the denominator down in words. "Indexable" is a policy decision, not a fact — make someone own it.
Coverage per directory, never as a single average. An aggregate hides a folder at zero. That is not a hypothetical; it is the specific way this hid.
Staleness and orphans, not just presence. A document indexed at the wrong version is worse than a missing one, because it answers.
Alignment between text and vector. Store the chunk with its embedding as one unit, or verify the pairing. Never zip two lists by position across a boundary where one can fail independently.
A canary question. One query per corpus whose correct source you know by heart. Run it on a schedule. Check the citation, not the answer.

The uncomfortable part

None of this was a model problem. Nothing here would have been improved by a larger context window, a better reranker, or a more capable model. The failure was entirely in the plumbing, and the plumbing had no opinion about it.

We spend enormous energy evaluating whether models hallucinate, and almost none verifying that the corpus we are grounding them in is the corpus we think it is. Grounding is only as good as the ground.

A retrieval system cannot report the document it never read. It has no representation of the thing that is absent. Ask it whether its knowledge is complete and it will answer, fluently, from the fraction it holds — which is exactly the question you were trying to settle.

So the question is not whether your RAG works. It answers, so it works. The question is what your coverage number is, what its denominator is, and whether anybody has looked at it since the day it was built.

What is your coverage number — and did you measure it, or inherit it from a dashboard?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Why BYD's Victory Reveals the Future of Software: Vertical Integration Is Coming to AI

Frédéric Guariento — Fri, 28 Aug 2026 18:04:44 +0000

The world watched as BYD overtook Tesla in EV sales last year. But that wasn't the real story. The real story is why — and what it tells us about the software industry in the next five years.

BYD didn't win because they made a better car. They won because they controlled the entire value chain: batteries, semiconductors, software, manufacturing. They didn't outsource the core. They built it all in-house, iterated ruthlessly, and moved faster than anyone else.

Now watch what's happening in software and AI. The pattern is repeating itself. And most of us are still pretending it isn't.

1. The Vertical Integration Thesis — It's Not New, But It's Coming to Software

For decades, the software industry has worshipped modularity and outsourcing. You buy your database from one vendor, your cloud from another, your security from a third. You stitch it together with APIs and hope for the best.

This worked when the pace of change was slow and differentiation happened at the application layer.

It doesn't work anymore.

BYD's lesson is brutal: when you're in a race where the pace of innovation accelerates exponentially, controlling the entire stack — from foundational models to inference, from data pipelines to security — becomes a competitive necessity, not a luxury.

Look at what's happening:

OpenAI didn't just build ChatGPT. They're building their own infrastructure, training their own models, deploying their own endpoints. They're not betting their future on AWS or Azure alone.

Anthropic is doing the same. Claude runs on their own infrastructure, with their own safety layers, their own data practices.

Google has Gemini, Vertex AI, and TPUs. Meta has Llama and their own silicon roadmap. Microsoft is bundling Copilot so tightly into Windows and Office that the operating system itself becomes the moat.

The companies winning aren't the ones renting cloud capacity. They're the ones who own the entire experience.

2. The Data Flywheel — Where BYD's Real Advantage Lies

BYD sells millions of EVs. Every car generates data: driving patterns, battery performance, charging behavior, grid interaction. That data feeds back into product design, manufacturing optimization, and the next generation of batteries.

This is a flywheel that no pure software company can replicate unless they own distribution and user intimacy at scale.

But here's what's interesting: the SaaS industry is starting to build the same flywheel, just with different assets.

Companies like Notion, Figma, and Linear aren't just selling software. They're collecting behavioral data from millions of users — how people structure information, how teams collaborate, how developers organize their workflows. That data trains their AI features, which makes the product stickier, which generates more data.

The winners in the next wave won't be the ones with the best algorithms. They'll be the ones with the best data about how people actually work.

This is why Microsoft's bet on integrating Copilot into Office is so dangerous. They don't just have the software; they have 400 million users generating data about how work happens. That's a flywheel BYD would recognize immediately.

3. The Cost of Ownership Problem — And Why It Matters

Here's where the analogy gets uncomfortable.

For years, car manufacturers outsourced to suppliers. It was cheaper. It was faster. It was modular.

Then electric vehicles happened. Suddenly, batteries weren't just a component — they were the entire value proposition. The companies that controlled battery design, manufacturing, and supply chain didn't just make better products. They made them more profitable because they eliminated the middleman.

Tesla understood this early. So did BYD.

In software, we're at the same inflection point with AI.

Right now, most companies are renting AI: paying OpenAI per token, using Azure OpenAI, calling Anthropic's API. It feels cheap because the marginal cost is low.

But the total cost of ownership is about to explode.

As AI becomes embedded in every workflow — not as a novelty feature, but as the core of how work gets done — the economics of API calls break down. You're paying for every inference, every token, every interaction. At scale, this becomes unsustainable for anyone who isn't OpenAI or Anthropic.

The companies that will own the next decade are the ones building their own inference stacks. Not because it's trendy. Because it's the only way to achieve unit economics that make sense at scale.

This is already happening quietly:

Slack is building their own AI features rather than just embedding ChatGPT.
Figma is training models on their design data, not outsourcing to OpenAI.
GitHub Copilot is moving toward GitHub's own models, not just GitHub + OpenAI.
Enterprise software companies are evaluating local inference with models like Llama or Mistral, not because they're as good as GPT-4, but because they cost a fraction of the price at scale.

I've been experimenting with this myself. Running llama3.1:8b locally on a single consumer GPU gives me 84 tokens per second — enough for most tasks. The cost? Zero per inference, after the hardware. Compare that to the API economics of Claude or GPT-4, and the math becomes obvious.

4. The Sovereignty Play — Control Means Resilience

BYD's vertical integration also gives them something less tangible: sovereignty. They're not dependent on Japanese suppliers for batteries, or American chip designers for semiconductors. When supply chains break, they can adapt.

Europe learned this lesson the hard way during the chip shortage. So did Taiwan. So is every government now.

The software industry hasn't fully grasped this yet, but it will.

Right now, the entire AI industry is built on a single point of failure: a handful of American companies controlling the foundational models. If OpenAI has a crisis, if there's a regulatory crackdown, if there's a geopolitical rupture — the entire ecosystem breaks.

This is why governments are investing in sovereign AI. Why Europe is funding projects to build European large language models. Why China is building its own stack. Why India is exploring local alternatives.

It's not about ideological purity. It's about risk.

The companies that will thrive are the ones that can operate with multiple models, multiple inference strategies, and multiple data sources. Not because one is "better," but because resilience requires optionality.

5. The Real Disruption — Speed and Iteration

Here's what people miss about BYD's victory: it wasn't about having a better battery in 2024. It was about the capability to iterate faster than anyone else.

BYD can design a new battery architecture, test it, manufacture it, and integrate it into production cars in months. Tesla takes longer. Traditional OEMs take years.

The same dynamic is playing out in software.

The companies winning with AI aren't the ones with the most sophisticated models. They're the ones that can iterate on their entire stack — from data collection to inference to user experience — in weeks, not quarters.

This requires:

Owning the data pipeline. You can't iterate fast on data you don't control.
Owning the inference layer. You can't optimize what you can't measure and modify.
Owning the user interface. You can't learn from users if there's an API boundary between you and them.

This is why Vercel (the Next.js company) is dangerous. They're not just selling a framework. They're building a complete stack from code to deployment to AI features, all integrated. They control the entire experience.

This is why Replit is interesting. They're building an IDE where the AI is native, not bolted on.

This is why Linear is winning against Jira. They own the entire workflow, and they can integrate AI at every point because there's no architectural boundary preventing them.

6. The Consolidation Is Coming

Here's the uncomfortable truth: the next three to five years will see massive consolidation in the software industry.

The companies that can afford to build and maintain a complete stack — data, models, inference, applications — will pull further ahead. The companies that are stitching together third-party components will find themselves in a cost structure they can't escape.

This doesn't mean the small players lose. It means the small players that win are the ones that own a specific, defensible part of the stack and integrate deeply with it. Not the ones trying to be a general-purpose platform.

What should you be thinking about?

If you're building a SaaS company:

Are you dependent on API costs that will become unsustainable at scale?
Do you have a plan to own your inference layer, or are you betting your unit economics on OpenAI's pricing staying favorable?
Can you build a data flywheel that improves your product over time, or are you just a UI layer on top of someone else's model?

If you're evaluating AI tools:

Does this solve a problem, or does it solve a problem while also building a moat for the vendor?
What happens to your costs when this moves from novelty to core workflow?
Are you building a dependency on a single vendor's API, or are you building flexibility?

If you're in enterprise IT:

Your AI strategy shouldn't be "use OpenAI's API for everything." It should be "use multiple models, multiple inference strategies, and own the data."
Local inference, federated learning, and hybrid architectures aren't nice-to-haves. They're becoming table stakes.

7. The European Moment (Again)

Europe is uniquely positioned to learn this lesson, but probably won't.

We have strong regulatory frameworks (GDPR, AI Act). We have companies with real technical depth. We have the ability to build sovereign infrastructure.

What we don't have is the speed and ruthlessness to move fast enough.

By the time European companies realize they need to own their stack, the Americans and Chinese will have already won. Again.

The window is closing. It's not closed yet, but it's closing.

The Bottom Line

BYD didn't win because they were smarter than Tesla. They won because they understood that in a race where the pace of change accelerates, controlling the entire value chain is non-negotiable.

The software and AI industry is at the same inflection point.

The next wave of winners won't be the ones with the cleverest algorithms or the best user interface. They'll be the ones who own the entire stack: data, training, inference, application, and user experience. The ones who can iterate faster because there are no architectural boundaries slowing them down. The ones who can achieve unit economics that make sense at scale.

This is already happening. Most of us are still not seeing it.

The question isn't whether this will happen. It's whether you're building for it or waiting to be disrupted by it.

The time to move is now. Not because it's trendy. Because the math is becoming undeniable.

🚀 #AI #SaaS #Strategy #Verticalintegration #BYD #Tesla #SoftwareArchitecture #CloudComputing #Sovereignty

Word count: 1,647 | Tone: Urgent, analytical, pattern-driven | Audience: Technical leaders, product managers, enterprise decision-makers

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

How Fast Could Your AI Do This?" — The Honest Answer

Frédéric Guariento — Fri, 28 Aug 2026 18:04:13 +0000

I get the question almost every week. At work, at dinner, under a LinkedIn post: "How fast could you do this with your AI?"

People expect a number. An hour? A day? And I watch their face change when I give the honest answer: "It depends entirely on what you bring me."

Because the real answer isn't a deadline. It's a question turned back on the asker.

🧊 What you see is only the tip

On social media, AI looks like magic. You type three lines, click a button, and a flawless result appears in thirty seconds. Video, report, code, image — take your pick.

What you're seeing is the last mile. The moment everything works. Nobody films the weeks that came before, because it doesn't dazzle and it doesn't sell in ten seconds.

Yet that's where 95% of the work lives. And 100% of the cost.

🏗️ Before AI even enters the room: three non-negotiables

Whether you're an individual automating your bookkeeping or a company building a domain assistant, AI doesn't start from nothing. Three ingredients have to be in place first. Without them, no AI stands up.

1. A specification. What do you actually want? Which inputs, which outputs, which edge cases? "I want AI to handle my emails" isn't a requirement — it's a wish. A requirement is: which emails, by what criteria, triggering what action, and what happens when something falls outside the frame.

2. Data. AI doesn't invent your reality — it digests it. If your data is scattered, inconsistent, and uncleaned, the most powerful model on earth will produce confident sludge. "Garbage in, garbage out" has never been truer than with AI — except here, the garbage comes out beautifully written.

3. Documented processes. You can't automate what you can't describe. If the know-how lives only in someone's head, the first step isn't technical — it's writing it down. Plenty of AI projects die right here, before a single line of code.

⚙️ Then the real work begins

Once those foundations are in place, you build. And now we're not talking minutes. We're talking hours, days, sometimes weeks to get a pipeline that ticks every box:

it works end to end — not just on the demo example;
it survives updates — the model changes, the API shifts, a dependency breaks, and it keeps running;
it's documented, so that in six months you still understand what you built;
it handles the unexpected instead of crashing on the first surprising input.

That pipeline — robust and maintainable — is what costs money. Not the prompt. Not the button. The invisible engineering around it.

🔧 An example I live every week

Let me be concrete, with one of my own systems.

I wanted my inbox to sort itself: every incoming message filed into the right folder, the real topics surfaced, the noise pushed aside. On paper, "an AI that sorts my email" is the perfect thirty-second-demo pitch.

In reality:

First I had to define my categories — not ten vague ones, but precise rules. What counts as "urgent"? What gets archived? Where's the boundary? No AI guesses that for you: it's your judgment that has to be written down.
I had to look at my data: years of heterogeneous email, recurring senders, improbable formats. Clean, sample, understand the weird cases.
I had to document the process I'd been doing by hand for years without even noticing.
Then I built the pipeline. Several evenings. Failures. False positives to correct. A model that changes behavior after an update and has to be re-tested.

Today? It runs on its own. I spend a few minutes a week keeping an eye on it. The gain is real, measurable, daily.

But the month a new type of message appeared — a case I hadn't anticipated — the system misfiled it, confidently. I didn't click a "go further" button. I reopened the spec, added the category, re-tested, redeployed. Back, partly, to square one.

That's exactly the AI contract nobody puts on the label.

⏱️ The paradox of "a few minutes a day"

Here's what nobody explains: once the system is built, using it really does take a few minutes a day. It's true. That's the entire point.

On one condition: stay inside the frame you defined at the start.

As long as you ask the system the questions it was designed for, it saves you an enormous amount of time. The day you step outside the perimeter — new data type, new use case, new requirement — you go around the loop again: new spec, new data, new cycle.

The "few minutes a day" isn't a lie. It's just the visible tip of an iceberg someone hid from you.

🧭 Where to actually start

If you want to do this seriously — personally or at a company — here's the order that avoids 90% of the disappointment. None of these steps is technical. That's the whole point.

Write your need as a single testable sentence. Format: "from [input], produce [output], applying [rule], and when in doubt, do [action]." If you can't, your need isn't ready — and neither is the AI.
Inventory your data. Where is it? In what format? Is it clean, current, accessible? An honest afternoon of inventory saves you weeks of illusion.
Document the process by hand first. Do the task yourself five times, writing down every decision. That document is the real specification. AI only automates what you managed to describe.
Define the frame — and especially the out-of-frame. Put in writing what the system will NOT do. That boundary is what protects your reliability.
Pick one narrow use case to start. Not "all of my accounting." One ticket. One category. One document type. You expand after the foundation holds.
Plan for maintenance from day one. Who re-tests when the model changes? Where are the docs? An unmaintained pipeline isn't an asset — it's sleeping debt.

Do those six steps, and you'll already know, on your own, "how fast."

🎣 Why so much of it feels like bait

I don't think people are lying. I think they show the finish line without showing the race.

You get a bit of text, a few hints, a button that says "go further." It's seductive, it looks true, and it sells a genuine skill. I understand the move — everyone monetizes their expertise, and there's real expertise behind it.

But the essential part gets left out — and it's exactly why this will be expensive: the specification, the data, the processes, the robustness engineering, the maintenance. The work that doesn't fit in a thirty-second clip.

So — how fast?

The real question isn't "how quickly can AI do this?" It's: "how well-defined is my problem, how clean is my data, how written-down are my processes?"

AI isn't slow or fast. It's exactly as ready as you are.

And if this resonates — whether you're curious, skeptical, or in the middle of a project — let's talk it over: a coffee, a conference, or simply the comments below. That real conversation is usually where a need gets framed far better than under any demo. 👇

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

AI in the SOC: The Seductive Trap of Automation Without Thinking

Frédéric Guariento — Fri, 28 Aug 2026 18:03:41 +0000

We are living a dangerous moment in cybersecurity. Vendors are flooding the market with AI-powered Security Operations Centers, promising to "eliminate alert fatigue" and "automate threat response" — and enterprises are buying them like lottery tickets, hoping the machine will do the thinking for them.

But here is the uncomfortable truth: most of these deployments are not solving the SOC crisis. They are masking it. And in doing so, they are breeding a new generation of analysts who cannot think.

Let me be direct. I have spent years in network security, incident response, and threat intelligence. I have seen the pattern repeat: technology arrives with utopian promises, gets deployed without discipline, and creates more problems than it solves. AI in the SOC is following that exact trajectory. The question is not whether AI can help — it can. The question is whether we are using it as a crutch or a catalyst. Right now, most organizations are choosing the crutch.

The Alert Fatigue Myth (and Why AI Deepens It)

Let's start with the core problem. Modern security tools generate thousands of alerts per day. A typical enterprise SOC drowns in noise. The human analyst, exhausted and deskilled, clicks through dashboards, dismisses 99% of alerts without reading them, and misses the one that matters.

The vendor pitch is simple: AI will filter the noise for you.

What actually happens is more insidious.

When you deploy an AI-driven alert triage system, you hand the classification problem to a black box. The model learns patterns from historical data — mostly false positives, because that is what fills the logs. So the AI becomes very good at recognizing false positives. It suppresses them. Alerts drop from 5,000 per day to 500.

The analyst feels relief. The SOC director reports "70% reduction in alert volume" to the board. Everyone celebrates.

But what has actually changed? The underlying security posture has not improved. The tools are still misconfigured. The baselines are still wrong. The logging is still noisy. What has changed is that the analyst no longer sees the problem. The AI has built a wall between them and the reality of their infrastructure.

And then, when a sophisticated attacker comes — one that does not match the training data — the system fails silently. Not because the alert was not generated, but because the analyst, now accustomed to trusting the AI's filtering, no longer has the muscle memory to read an alert critically. They have outsourced their judgment.

This is skill atrophy in real time.

The False Positive Trap: Why AI Amplifies What It Claims to Solve

Here is another layer. False positives are not random noise — they are signals of misconfiguration. When your IDS generates 200 alerts per day on port 443 traffic, that is not a detection problem. That is a tuning problem. The alert is telling you something: your rule is too broad, your baseline is wrong, or your environment has changed.

A human analyst, forced to triage those 200 alerts, would eventually ask: "Why are we seeing this every day?" They would escalate to the engineering team. Rules would be tuned. The baseline would be refined. Over time, alert quality would improve.

An AI system does something different. It learns that port 443 traffic at 2 AM is "normal" and suppresses it. The underlying misconfiguration persists, invisibly. The analyst never discovers it. The next time an attacker uses port 443 — which, let us be honest, is often — the AI has already taught itself that this is benign.

The paradox: the system that claims to reduce false positives has actually made them structural. They are no longer visible. They are baked into the model.

Analyst Skill Atrophy: The Quiet Crisis

I want to be clear about what I mean by skill atrophy, because it is not what the tech press usually discusses.

A SOC analyst is not just an alert classifier. A good analyst is a threat hunter, a pattern recognizer, a systems thinker. They understand their infrastructure. They know what normal looks like. They can read a log file, spot an anomaly, and trace it back to root cause. They develop intuition.

When you remove the analyst from the alert triage process — when you say "the AI will handle this, you focus on the interesting stuff" — you are actually removing them from the learning loop. They no longer see the baseline. They no longer develop intuition about what is normal in their environment. They become reactive instead of proactive.

Worse, when they do need to intervene, they have lost the foundational knowledge to do it well. I have seen SOCs where analysts cannot manually tune an IDS rule because they have never had to. They cannot read a raw packet capture because the AI has always done the parsing. They cannot estimate the risk of an alert because the AI has always assigned the score.

This is not a small problem. This is the slow hollowing-out of institutional knowledge.

And here is the kicker: the vendors know this. They have built a lock-in mechanism. The more dependent your analysts become on the AI, the harder it is to leave. You cannot suddenly ask humans to do what they have not done in five years. So you are stuck. You are paying for a system that has made you more vulnerable, not less, because you have no alternative.

Where AI Could Actually Help (But Rarely Does)

I do not want to be a pure skeptic here. AI can be valuable in a SOC — but only under specific conditions that most organizations ignore.

First: AI should augment, not replace. The analyst should remain in the loop. The AI should surface candidate patterns, with high confidence and clear reasoning. The analyst should retain the ability to override, to drill down, to question. This is hard to build, which is why vendors do not do it.

Second: AI should be trained on your data. A model trained on generic security data is nearly useless in your environment. Your normal is not someone else's normal. Yet most commercial SOC AI systems are pre-trained on aggregated threat intelligence. They are solving a generic problem, not your problem.

Third: AI should be transparent. You should understand why an alert was suppressed or escalated. If the system cannot explain itself, you cannot trust it, and you cannot learn from it. But transparency is expensive, and it does not scale well, so most vendors skip it.

Fourth: AI should improve your processes, not hide your problems. A good AI system should help you identify misconfigured rules, refine baselines, and reduce alert volume at the source. Instead, most systems just suppress the noise.

When I see a SOC deploying AI under these conditions — with human oversight, local training, transparency, and a focus on process improvement — I am optimistic. I have not seen it often, but it is possible.

The Real Question: What Are We Optimizing For?

Here is what I think is really happening, and why I am concerned.

SOC budgets are constrained. Analyst salaries are high. Burnout is real. Vendors see an opportunity: promise to replace analysts with AI. Executives see an opportunity: reduce headcount without admitting it. Analysts see a trap: learn to depend on the system or lose your job.

Everyone is optimizing for the appearance of solving the problem, not the problem itself.

The real solution — the one that actually reduces risk — is harder and more expensive:

Invest in analyst training and retention. Pay them well. Give them time to learn. Build a culture of continuous improvement. This is not scalable. It does not look good in a PowerPoint. It does not generate vendor revenue. So no one does it.
Fix the underlying data quality. Stop generating false positives by tuning your tools, refining your baselines, and understanding your infrastructure. This requires discipline and patience. It takes months. There is no quick win. So no one does it.
Use AI as a tool within a human-centered process. Let analysts use machine learning to detect patterns they could not see manually. But keep humans in charge of judgment, prioritization, and strategy. This requires building systems that are explainable and contestable. It is harder than black-box optimization. So most vendors do not do it.

Instead, we are doing what is easy: deploying opaque AI systems, hoping they will magically solve the problem, and then wondering why our security posture has not improved.

What This Means for You

If you are building or managing a SOC, here are the hard truths:

Do not buy AI-powered alert triage as a substitute for good tuning. If your baseline is noisy, AI will hide the noise, not fix it. Fix the noise first.

Do not assume that automation means you can reduce analyst headcount. Good SOCs need more thinking, not less. Automation should free analysts to do deeper work, not eliminate the work itself.

Do not trust a system you cannot understand. If the AI cannot explain why it suppressed an alert, you cannot learn from it. Demand transparency. If the vendor cannot provide it, walk away.

Do invest in your people. An analyst who understands their infrastructure, who can think critically about risk, who can trace an attack from indicator to impact — that person is irreplaceable. Do not let them atrophy. Do not let the tool do their thinking for them.

Do treat AI as a catalyst, not a crutch. Ask: does this system help my analysts think better, or does it let them think less? If the answer is the latter, you are moving in the wrong direction.

The Uncomfortable Conclusion

We are at a moment where the technology is moving faster than our wisdom about how to use it. The vendors are smart. The marketing is seductive. The promise of automation is real. But the trap is also real: the false sense of security that comes from delegating judgment to a system you do not fully understand.

The SOC of the future will not be one where AI has replaced human thinking. It will be one where humans and machines work together, with humans firmly in control of judgment and strategy, and machines handling the scale and speed that humans cannot match.

That future requires discipline, investment, and honesty about what we do not know. It is not as exciting as the vendor pitch. It will not generate headlines. But it is the only path to real security.

The question is: are we willing to take it?

The conversation starts here. What is your experience? Have you seen AI in the SOC used well? Or have you watched it become a crutch? I want to hear from practitioners who have lived this tension.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Dark Factories Are a Myth—But the Real Automation Story Is More Complex

Frédéric Guariento — Fri, 28 Aug 2026 18:03:09 +0000

When you write about the future of work, "dark factories" — automated warehouses and manufacturing plants running 24/7 with minimal human presence — become an easy reference. I've used the term myself in talks about AI-driven displacement. It's a vivid, urgent image: robots working in the dark while humans sleep, jobs evaporating overnight.

But last month, I decided to stop citing it without interrogating it. What I found was uncomfortable: the narrative is real, but the evidence is thinner than the hype.

The Problem with Borrowed Authority

Let me be direct. I've written about dark factories as a harbinger of mass unemployment. The concept appears in my talks on automation and the future of work. But when I tried to pin down where the numbers come from, I hit a wall.

A "dark factory" is not a standardized term. There's no registry of them. The companies running them — Siemens, Trumpf, some automotive suppliers — don't publish detailed employment data tied to specific facilities. Trade press coverage exists, but it's often breathless and promotional rather than investigative.

The most-cited examples are real: Siemens' Amberg facility in Germany, which has run with minimal night-shift workers for decades. But Siemens is also one of the largest employers in Germany. That one factory is not representative of an industry transformation.

What I found instead was a pattern I recognize from other tech narratives: a kernel of truth, amplified by repetition, divorced from context, and then treated as inevitable.

What Dark Factories Actually Are (and Aren't)

Let's separate fact from extrapolation.

What is real:

Highly automated manufacturing and logistics hubs exist. Companies like Amazon, DHL, and major automotive suppliers have invested heavily in robotic systems that reduce the need for night-shift human labor. Some facilities do operate with skeleton crews or 24/7 autonomous processes.

The economic logic is sound: labor in developed economies is expensive; robots don't demand breaks, healthcare, or overtime. For repetitive, high-volume tasks — picking, packing, welding, assembly — automation makes financial sense.

What is speculative:

The claim that dark factories represent a significant, measurable portion of global manufacturing or logistics. I found no credible data suggesting that "dark factories" employ a meaningful percentage of the workforce or that they are displacing workers at the scale implied by the rhetoric.

A 2023 report from the International Federation of Robotics (IFR) shows that industrial robot installations are growing, yes — but the growth is concentrated in a handful of sectors (automotive, electronics, food) and geographies (China, Germany, Japan, South Korea). Even in those sectors, robots augment rather than replace entire workforces. The factories are not dark; they have people managing, maintaining, and quality-checking the machines.

The World Economic Forum's "Future of Jobs" reports, which I've cited, do predict significant job displacement from automation. But they don't single out "dark factories" as the primary mechanism. They point to broader digital transformation, AI, and process automation — which is different from the specific image of unmanned factories.

Why the Myth Persists (and Why I Perpetuated It)

The dark factory narrative is seductive because it is visually compelling and emotionally urgent. It's easier to imagine a future where robots work in silence than to explain the messy reality: gradual automation, skill shifts, uneven impact across regions and sectors, and the stubborn persistence of human labor in places we'd expect it to be automated away.

For someone like me — someone who writes about technological disruption and societal risk — the dark factory is a useful metaphor. It crystallizes anxiety. It makes the abstract concrete.

But metaphors are not data. And when you're trying to persuade people to act on policy, education, or investment, the difference matters.

I also suspect that journalists, consultants, and academics (myself included) have been lazy. We cite "dark factories" because others have cited them. We trust the framing because it aligns with our thesis. We don't dig into the source.

What the Data Actually Shows

Here's what I found when I looked harder:

Robot density is increasing, but unevenly. The IFR reports that industrial robot density (robots per 10,000 manufacturing workers) is highest in South Korea (~932), Singapore, Germany, and Japan. It's much lower in the US (~376) and lower still in Europe overall. China is investing heavily but still has lower density than developed economies. This suggests that automation is not uniform and that labor remains central to manufacturing even in high-tech facilities.

Employment in manufacturing hasn't collapsed. In developed economies, manufacturing employment has declined, yes — but the decline predates modern robotics and is driven by offshoring, deindustrialization, and shifts in consumer demand. Within factories that have invested in automation, employment has often stabilized rather than disappeared. Jobs have changed (more technicians, fewer assembly-line workers), but the facilities haven't gone dark.

Logistics is the real automation frontier. Amazon's warehouses, which are often cited as dark-factory precursors, still employ hundreds of thousands of people. They use robots to move shelves and assist picking, but humans still do the fine-motor work and problem-solving. Amazon's own data shows that in facilities with robots, they've added workers, not subtracted them. The economics of scale require volume, and volume requires people.

Night-shift work hasn't disappeared. In fact, 24/7 operations have increased demand for shift work in many sectors. The shift has been from manufacturing night shifts to logistics, healthcare, and service-sector night shifts. The jobs are different, but the labor is still there.

The Uncomfortable Truth

The uncomfortable truth is this: automation is real, displacement is real, and the future of work is genuinely uncertain. But the mechanism of displacement is not dark factories. It's more diffuse, more gradual, and harder to visualize.

Displacement happens through:

Skill obsolescence (the truck driver whose route is optimized by AI)
Wage suppression (the worker competing with cheaper offshore labor and automation)
Sectoral shift (manufacturing jobs lost; service jobs gained, often at lower pay)
Geographic concentration (some regions adapt; others don't)
Credential inflation (the job that once required a high school diploma now requires a degree)

These are harder to write about. They don't fit into a single image. They require nuance, regional data, and acknowledgment of complexity.

But they're also where the real policy action is needed.

What I'm Doing Differently

I'm retiring "dark factories" from my standard vocabulary. Not because they don't exist, but because I can't cite them with confidence, and I've been using them as a rhetorical shortcut.

Instead, I'm committing to:

Specificity over metaphor. If I cite automation, I cite the IFR data or company reports. If I discuss displacement, I reference labor statistics and sector-specific studies, not vague warnings.
Naming my sources. When I make a claim about the future of work, I'll say where it comes from: a study, an interview, an observation — or I'll say "this is speculative."
Distinguishing between what is and what might be. The dark factory might happen at scale. But it hasn't yet. I need to say that clearly.
Acknowledging where I'm wrong. I've been part of amplifying a narrative without sufficient evidence. That's a failure of intellectual rigor, especially from someone writing about technology's societal impact.

The Broader Lesson

This matters beyond dark factories. We live in an era where urgent narratives about technology circulate faster than evidence. AI will destroy jobs. Blockchain will decentralize everything. Quantum computing will break all encryption. Dark factories will eliminate work.

Some of these may be true. But we won't know if we treat them as axioms rather than hypotheses.

The capacity to innovate and think creatively is important. But so is the discipline to say: "I don't know yet. Let me check. I was wrong."

For those of us writing about technology's future, that discipline is not optional. It's foundational.

The work ahead is urgent. But urgency without rigor is just noise.

What's your experience with automation in your sector? Have you seen the dark factory narrative in practice, or have you found the reality different? I'd genuinely like to hear where the evidence points in your field.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

What It Actually Takes to Run Your Own AI: One Consumer GPU, a Routed Model Mesh, and $100 a Month

Frédéric Guariento — Fri, 28 Aug 2026 18:02:37 +0000

Every "local AI vs cloud" article I've read shares one quiet feature: the author never touched the hardware they describe.

They quote NVIDIA A100s at €15,000 each. They build €60,000 GPU "nodes." They add "0.5 FTE of staffing," AWS SageMaker line items, €36,000 a year. The numbers are clean, the tables are tidy, and the whole thing is fiction — generated from training data by people benchmarking a spreadsheet they invented.

I want to do the opposite: show you the real system. What I run, how it's wired, what it costs, and the discipline that keeps it cheap. It's less glamorous than a fantasy datacenter. It's also something you could actually build.

The Hardware: One Card, Doing Everything

The "AI infrastructure" is a single consumer graphics card. An RTX 4070 Ti. 12 GB of VRAM. Around €800, bought as a general-purpose GPU.

There's no rack and no A100. That card lives inside a bare-metal host that is also running dozens of other containers. Zoom out and the whole homelab is 35 stacks and roughly 100 Docker containers spread across three machines — a GPU box, a second Docker host (vm-docker), and a NAS. The AI doesn't get a dedicated palace. It shares the building with everything else I self-host.

The Wall Nobody Shows You

Here's what those local models actually do on 12 GB of VRAM — real ollama --verbose generation speeds, measured this week:

Model	Size	Speed	Fits 12 GB?
Llama 3.2 (3B)	2.0 GB	152 tok/s	✓ easily
Mistral 7B	4.4 GB	98 tok/s	✓
Llama 3.1 (8B)	4.9 GB	84 tok/s	✓
Qwen2.5-Coder (32B)	19 GB	3.9 tok/s	✗ spills to CPU

Read the last row twice, because it governs everything.

The 32-billion-parameter model — the impressive one on every capabilities chart — runs at 3.9 tokens per second. Roughly one word every two seconds. Unusable for anything interactive. The 8B model on the same card is 20× faster.

Why? The 32B needs 19 GB; I have 12. The instant a model overflows VRAM, it spills into system RAM and CPU and falls off a cliff. This is the VRAM wall, and it's the single fact the fantasy benchmarks paper over. On a 12 GB consumer card your real ceiling is 8B-class. You don't buy past it with patience — you buy past it with VRAM.

Which is exactly why the next hardware step is a 24 GB RTX 3090, bought opportunistically second-hand. Not for prestige — to move that 32B model from 3.9 tok/s to genuinely usable, and pull more of the mesh back in-house. The whole upgrade is a response to one measured number.

So I Don't Run a Model. I Route a Mesh.

This is the part the "local vs cloud" framing misses entirely. The question was never which one. It's which job goes where.

A small proxy — LiteLLM — sits in front of everything and routes each request to the cheapest box that can do it well:

Job	Goes to	Why
Bulk reasoning, drafts, classification	DeepSeek V3 (cloud API)	~$0.27 per million input tokens — cents where frontier charges dollars
Step-by-step reasoning	DeepSeek R1	replaced my local 7B reasoner — faster and cheaper than running it myself
Long context / code	Kimi K2 (Moonshot, 262k context)	holds an entire codebase or book in one prompt
Needs to be fast	Groq (Llama 3.3 70B)	absurd throughput when latency matters
Hard reasoning, the actual writing	Claude	the 5% that has to be genuinely good
Private / offline / high-volume	Local Ollama (Llama 3.1 8B, nomic-embed)	never leaves the building; zero marginal cost

And it's not just routing — it's failover. The config has explicit fallback chains: if DeepSeek's API is down, the request drops to a local model; if the local model can't carry it, it escalates to Claude. Embeddings and the private RAG path have no silent fallback at all — if the retrieval service is down, the system errors out rather than quietly answering without sources. That's a deliberate security choice, not an accident.

That's the real answer to "local or cloud": neither — a routed mesh, chosen per task, with the cheap options first and the expensive ones held in reserve.

The Cost Has Two Regimes, Not One

Here's where the fabricated €36,000/year falls apart completely. My AI spend lives in two buckets:

1. A flat subscription for interactive work. The heavy agent sessions — the ones writing code, refactoring, driving the homelab — run on a $100/month flat Claude plan. Not metered. Ten requests or ten thousand, same bill. I did not spend $3,000 on API calls; that sentence describes a pricing model I don't use.

2. Pay-per-million credits for the pipelines. Everything automated — document OCR, email triage, RAG, the article generator you may be reading right now — runs through the mesh on DeepSeek and Kimi API credits. And the unit here is the million tokens. DeepSeek V3 is around $0.27 per million in, ~$1.10 out. The pipelines cost single-digit dollars a month. Local inference on the GPU costs a fraction of a cent per answer in electricity, on a card that idles at 8 W.

So the honest total for a working, daily-use AI stack is: one flat subscription, a handful of dollars in API credit, and a few euros of power. The fantasy benchmark wasn't just wrong on the numbers — it modelled the wrong animal: a corporation replacing a cloud contract, instead of one person assembling more capability than a 2020 enterprise had, for less than a phone plan.

The 5-Hour Problem (and the Console That Fixes It)

A flat plan has a catch: a rolling usage window. Push hard enough in a session and you hit the limit, and the interactive agent goes quiet for a while.

That used to mean I was blocked. Now it doesn't. An OpenWebUI console sits on top of the same LiteLLM mesh, so when the Claude window is spent, I keep working — the same prompts route straight to the DeepSeek and Kimi credits instead. The flat plan handles the bulk; the pay-per-million mesh absorbs the overflow. This handoff is the piece I'm actively wiring now, and it's the difference between "blocked until the window resets" and "never fully blocked."

That's the real resilience story. Not redundant A100s. A second front door onto a cheaper set of models.

Compression: Spending Fewer Tokens on Purpose

Cheap models still reward discipline, and a lot of the optimization is simply not spending tokens you don't need to — on both ends:

Input side: prompt caching (a caching proxy in front of Claude so repeated context isn't re-billed every call), and compressed memory files — the long instruction and context files the agents load get squeezed to a denser form that says the same thing in far fewer tokens.
Output side: terse-by-default response modes that strip filler, articles, and pleasantries — easily a 50–75% cut in output tokens for the same information, which on a per-million meter is real money and, locally, real watts.

In/out compression isn't a gimmick. On metered models it's the bill; on the local GPU it's the power draw and the latency. Same lever, three payoffs.

The Actual Job: Harden, Optimize, Reduce

None of this was designed once and left alone. The real work is a loop, and every iteration has the same three verbs:

Harden — tighten what's exposed, remove silent fallbacks where a wrong-but-confident answer is dangerous, keep private data on private paths.
Optimize — better routing, more caching, the right model for each job instead of the biggest model for every job.
Reduce consumption — schedule heavy jobs off-peak (some providers are markedly cheaper at off-peak hours), push non-urgent work to CPU so the GPU can sleep, wake the GPU on demand instead of idling it hot, and organize tasks so the machine does less to deliver the same result.

That loop is the system. The hardware is almost incidental. What makes it work is treating a closet like infrastructure: measure, route, cache, schedule, repeat.

Where This Is Heading (Stated as Intent, Not Fact)

I'll be precise about the difference between what runs today and what I'm aiming at — because blurring the two is how these articles turn into fiction.

What's planned: the 24 GB RTX 3090 to break the VRAM wall and pull more of the mesh in-house; finishing the OpenWebUI handoff so the 5-hour overflow is fully automatic; and a longer-term move toward a dedicated GPU host so the AI stops sharing a card with everything else.

What I'm still questioning: there's a whole shelf of heavier orchestration — agent frameworks, long-running autonomous daemons, multi-agent "swarm" tooling. The honest answer is I haven't deployed them, and I'm not convinced they earn their place here yet. On a single 12 GB card, a long-running multi-agent framework competes for the exact VRAM my real workloads need. The bar isn't "is it impressive" — it's "does it earn its VRAM and its complexity against what I already get from a simple routed mesh." So far, for a solo operator, the simple mesh keeps winning. That may change when the 3090 lands. I'll measure it, not assume it.

That's the discipline: name the destination, but never describe it as if you'd already arrived.

What This Actually Proves

Strip away the spec sheet and here's what's left.

A complete, sovereign, mostly-private AI stack — one that classifies my documents, searches my archives, transcribes recordings, triages my inbox, runs retrieval over my own corpus, and drafts my work — runs on a single gaming GPU, a routed mesh of cheap-and-frontier models, one flat subscription, and a handful of dollars in credit. It lives in a closet next to 100 other containers. And it gets cheaper and tougher every iteration, by design.

That's the story the fantasy benchmarks hide, probably without meaning to. The frontier of AI automation isn't the hyperscaler datacenter with its €60,000 nodes. It's the collapse in the cost of doing real work — the capability that needed an enterprise budget in 2020 now needs a hobbyist's, plus the discipline to wire it well.

When automation lived in a megacorp datacenter, you could at least see it coming. The next wave doesn't have a datacenter. It has a fan, 12 GB of VRAM, a routing table, and a $100 subscription. It's already running.

Run by a practitioner, on real hardware, with measured numbers. If you're building something similar — a routed model mesh, a sovereign homelab, a cheaper way to do serious AI work — **contact me. Happy to compare notes and share what I've learned.**

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

After NEXUS: Three Books That Reshaped How I Read AI

Frédéric Guariento — Fri, 28 Aug 2026 18:01:31 +0000

Have you noticed how we talk about artificial intelligence as though it were a single coherent force, rather than a collision of incompatible ideas, economic interests, and philosophical traditions? I spent years absorbing technical papers and vendor whitepapers, convinced that deeper understanding of neural networks or transformer architectures would clarify the stakes. Then I read Blake Blake's NEXUS, and realised I had been reading the wrong literature entirely.

That book — which traces how connectivity itself rewires human cognition, from writing to the internet — cracked open something I'd been missing: AI isn't a technology problem. It's a social one. The algorithms matter less than the power structures they embed. And once you see that clearly, three other books become essential reading, not as supplements to technical knowledge, but as corrections to it.

The first is Yuval Noah Harari's Sapiens. I know, I know—it's been on every LinkedIn influencer's shelf for a decade. But most people read it for the narrative sweep, the story of how humans conquered the world. What I needed from it, and what I finally understood after NEXUS, was something else: the observation that large-scale cooperation depends on shared myths. Money is a myth. Nations are myths. The idea that humans are inherently rational is a myth. So when we deploy AI systems at scale—when we ask algorithms to make decisions about credit, hiring, criminal justice—we're not implementing neutral logic. We're encoding myths about human worth, economic value, and social order into machines, then hiding behind claims of objectivity. Harari shows that this sleight of hand is ancient. Recognising it in AI requires seeing how myths have always driven human societies, long before we had neural networks to blame for our choices.

The second is Cathy O'Neil's Weapons of Math Destruction. This one is more direct: it's a catalogue of how algorithmic systems, even well-intentioned ones, amplify inequality and lock people out of opportunity. What struck me most was not the examples—they're damning and necessary—but her argument that the power asymmetry is structural. We deploy algorithms without understanding them, without consent from those affected, and without meaningful accountability when they fail. And because they're opaque, people can't fight back the way they could against a human decision-maker. O'Neil is writing about the governance problem, not the technical one. And that's the conversation we're not having loudly enough. We debate whether AI is "safe" or "aligned," as if safety were a property of the code rather than a question of who controls it and for what purpose.

The third is Bruno Latour's We Have Never Been Modern. This is the hardest of the three, and the one I return to most often. Latour argues that our entire intellectual tradition rests on a false divide: nature versus culture, science versus politics, fact versus value. We pretend we can separate them, keep them in different boxes. But we can't. Every scientific fact is entangled with social interests. Every technology embeds politics. And when we build AI systems, we're not separating intelligence from values—we're weaving them together, then claiming we've done something neutral. Latour's insight is that we need to stop pretending. We need to acknowledge that every system we build is a hybrid, a mixture of the technical and the social, and we need to govern it as such. No amount of alignment research will change that fundamental truth. What changes is whether we admit it.

These three books sit uneasily together. Harari is a historian, O'Neil a data scientist turned critic, Latour a philosopher of science. But they converge on a single point: the AI crisis is not about intelligence. It's about power, myth, and the stories we tell ourselves about objectivity. If you're reading only technical literature on AI—papers on scaling laws, constitutional AI, mechanistic interpretability—you're missing the essential context. You're reading as though the problem were solvable by engineering alone.

That doesn't mean the technical work is irrelevant. It means it's insufficient. We need both: people who understand the mathematics deeply enough to ask hard questions about what systems actually do, and people who understand the social consequences well enough to demand accountability. We need engineers who read Latour. We need policymakers who understand neural networks. And we all need to stop pretending that AI is a neutral tool waiting to be "aligned" by the right incentive structure.

The uncomfortable truth these three books converge on is that alignment is not a technical problem we can solve and move on from. It's a permanent tension between what systems can do and what we collectively decide they should do. That tension requires ongoing negotiation, not a final solution. It requires admitting that every choice we make about how to build and deploy AI is a choice about what kind of society we want to live in.

Which is why I keep returning to them. Not because they give me answers, but because they ask the right questions.

Have you read any of these? What's shifted in how you think about AI after encountering work that challenges the technical frame?

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works

Building Your Own Sovereign CVE Watch: An OpenCVE Field Report

Frédéric Guariento — Fri, 28 Aug 2026 18:01:27 +0000

How many times this week have you learned about a critical vulnerability from a vendor newsletter, a Twitter thread, or a Slack message from a colleague—hours after it went public? And how many of those alerts were noise, commercial pressure, or simply irrelevant to your actual infrastructure?

The vulnerability intelligence game has become a game of noise. Every vendor wants to sell you their feed. Every security platform wants to own your threat perception. Every incident response consultant wants to monetize your fear. Meanwhile, your actual risk—the specific software running on your specific machines, in your specific context—drowns in the flood.

This is not a technical problem. It is a sovereignty problem.

I have spent the last few months building and refining an OpenCVE instance on modest hardware: a single RTX 4070 Ti homelab, running alongside 34 other Docker containers, no dedicated infrastructure, no cloud bill. The exercise revealed something uncomfortable: the difference between having vulnerability data and owning your vulnerability perception is not a scale problem. It is a control problem.

Why does this matter? Because the moment you outsource CVE intelligence to a platform you do not run, you outsource your threat model. You accept someone else's definition of "critical." You inherit their blind spots. You become dependent on their uptime, their API rate limits, their pricing decisions. In cybersecurity, dependency is risk.

Let me walk through what changed when we stopped consuming and started owning.

The Problem with Curated Feeds

Vulnerability feeds exist on a spectrum. At one end: raw NVD data, unfiltered, thousands of entries per day, 95% noise for any given organization. At the other: vendor-curated feeds, which promise relevance but deliver what the vendor believes is relevant—which is often what the vendor sells you tools to fix.

CVSS scores are not risk scores. A 9.8 vulnerability in software you do not run is not a risk. A 5.5 in your core infrastructure is. Yet every commercial feed treats these with the same urgency.

OpenCVE changes the premise. It is a self-hosted vulnerability database that ingests NVD, GitHub Advisories, and other sources, then lets you define what matters. Not through a UI checkbox—through code, automation, and explicit policy. Your rules. Your context. Your risk model.

The moment I could write a filter that said "alert me only on CVEs affecting PostgreSQL, Python, or Docker, and only if they score above 7.5 and we run that version," the noise dropped by 80 percent. Suddenly, the remaining alerts were not alerts—they were actionable intelligence.

But here is the uncomfortable part: that clarity requires you to know what you are running. Not vaguely. Not "we use Docker." Specifically: Docker 24.0.6, running on Debian 12.1, with these kernel versions, these Python packages. If you cannot articulate your inventory, no CVE watch will save you. The tool exposes the gap.

Ownership Changes Behavior

Running your own CVE watch forces a conversation your organization has probably been avoiding. What actually matters to us? What is our risk appetite? What do we run, and why? What can we patch, and what cannot?

I have watched teams discover, through OpenCVE, that they are running seventeen versions of the same library across their infrastructure—some patched, some not. I have watched others realize that their "critical" application depends on an unmaintained package from 2019. These are not new problems. They are old problems that commercial feeds let you ignore because the feed is someone else's job to manage.

When you own the watch, you own the inventory. When you own the inventory, you can own the risk.

The operational rhythm changes too. Instead of reactive "a vulnerability was announced, let me check if we are affected," you shift to proactive "here is our vulnerability surface, here is our patch cadence, here is our risk tolerance." You move from incident response to risk management.

This does not require enterprise hardware. My instance, running on a single GPU with a few CPU cores, ingests the full NVD, processes it through custom filters, and delivers a weekly digest to our team. The latency is acceptable. The cost is negligible. The control is absolute.

The Sovereignty Angle

Here is what keeps security leaders awake: if your vulnerability intelligence comes from an external platform, so does your threat perception. If that platform goes down, gets acquired, changes its pricing, or pivots its business model, you are affected. If it is compromised, you are exposed. If it is in a jurisdiction with different data governance rules, you inherit those rules.

Europe has been talking about digital sovereignty for a decade. Most of that talk is vague and political. But vulnerability intelligence is concrete: do you control the data that defines your security posture, or do you rent it?

OpenCVE is not the only open-source CVE tool, but it is the only one I have found that is genuinely self-hostable, genuinely low-overhead, and genuinely designed for the question "what if I want to know, on my own terms, what vulnerabilities matter to me?" The answer is: you can. Not in six months. Not with a dedicated team. Now.

The trade-off is real: you lose the convenience of a managed service. You gain the clarity of owning your threat model. You lose the vendor's curated intelligence. You gain the ability to ask questions the vendor never thought to answer.

For organizations serious about cybersecurity—not compliance theater, not vendor checkbox ticking, but actual risk management—that trade-off is not even close.

What Comes Next

I am evaluating integration with Wazuh for automated response and Falco for runtime threat detection, so that CVE intelligence feeds directly into your detection layer. Not yet deployed—the pieces exist, but the orchestration is still being tested. The vision is straightforward: your vulnerability watch becomes part of your threat model, not separate from it.

The vulnerability landscape will not get simpler. Vendors will not stop selling you fear. Noise will not decrease. But you can choose not to be a passive consumer of someone else's interpretation of that noise.

The question is not whether you can afford to build this. It is whether you can afford not to.

What is your organization's single biggest blind spot in vulnerability management? Is it inventory, patching speed, or something else entirely? I am curious what friction points teams hit when they try to move from reactive alerts to proactive risk ownership.

Originally published at articles.savethemall.eu.

🤖 Written with AI assistance, reviewed and approved before publication. Editorial responsibility: Frédéric Guariento. How it works