DEV Community: Marco Sbragi

Thalamus: LLM Cognitive Exoskeleton

Marco Sbragi — Thu, 20 Aug 2026 04:08:17 +0000

English version of Thalamus: Esoscheletro Cognitivo Per LLM

1. The Biological Origin: Why the "LLM Cortex" is Collapse

In the human brain, the thalamus is not a simple passive cable pass-through. It is the mind's central relay station, sensory filter, and gating mechanism. It processes, prioritises, and routes incoming sensory information before it reaches the cerebral cortex. Without this active filter, the cortex would be inundated with endless ambient noise, leading to immediate cognitive collapse.

Current AI development integrations (like VS Code Copilot or OpenWebUI) suffer from exactly the same problem. Every time the IDE interacts with a model, it sends a chaotic mass of unstructured context: proprietary system prompts, giant directory trees, static skill declarations, and entire unfiltered chat histories.

We find ourselves feeding our "LLM cortex" a 150+KB "Token Soup" to answer trivial questions like "Where is this function defined?" This crude approach results in:

Huge Computational Waste: Biblical prefill times on local inference engines (Ollama, Llama.cpp), saturating VRAM and chip bandwidth (a critical issue when working locally on unified-memory hardware).
Context Drift & Entropy: Models lose focus ("Lost in the Middle") due to contradictory instructions accumulated in previous rounds.
Idempotency Loss: Duplicate or failed requests resend the same mass of tokens without maintaining a clean state.

2. The Paradigm Shift: "Context Window as RAM, not Storage"

LLM application builders are making a fundamental mistake: treating the context window like a hard disk.

Recent research (formalized by projects like Mem0 in 2026) demonstrates that the context window behaves exactly like system RAM: it is volatile, extremely computationally expensive, and its performance degrades exponentially as the number of input tokens increases.

Furthermore, the most recent scientific literature ("The Price of Meaning: Why Every Semantic Memory System Forgets" has mathematically demonstrated an intrinsic limitation of systems based purely on semantic search (classical vector RAG): organizing information based solely on geometric meaning inevitably generates interference, false recalls, and amnesia under load. Vector search is not sufficient for software development, where pinpoint precision is required.

For this reason, Thalamus introduces a hybrid, deterministic memory architecture:

The State Blackboard (Postgres JSONB): AA persistent, centralized registry that tracks active "Dependency Contracts" (real DB schemas, API contracts, current task, and existing components). The LLM does not need to infer the project's state by rereading the history; it receives it as a deterministic snapshot.
Episodic Memory (Qdrant Vector DB): Used exclusively to retrieve relevant historical fragments via Topic Routing (e.g., isolating vectors tagged #database when working on the backend, preventing CSS noise from contaminating the SQL logic).

3. The Evolution of Middleware: The "Tabula Rasa" Pattern

In its first conceptual implementation, Thalamus operated passively via an n8n orchestrator, intercepting payloads and applying complex Regex to "scrub" the client's XML tags. This approach proved to be fragile and partial: it forced the need to constantly chase boilerplate changes from various providers.

We then refined the architecture by switching to the Tabula Rasa (Active Reconstruction) pattern.

Thalamus now acts as a standalone Cognitive Middleware written in FastAPI and placed behind a standardization gateway (LiteLLM). When the client sends a request:

Tabula Rasa: Thalamus intercepts the call and discards the client's proprietary system prompt to avoid "token soup".
Optional (Non-Mandatory) Degreaser: The microservice includes a flexible degreaser module to clean up client tags and extract useful information (e.g., selected code or file references). However, it is not a blocking constraint: if the degreaser fails or the client format changes, the pipeline does not stop.
Metadata Extraction: Isolates the message_id (to ensure idempotence on Postgres) and the session_id.
Active Reconstruction: Build a dense and structured prompt from scratch by combining the Blackboard snapshot, the sliding window of the Postgres chat logs, and the last raw message from the user.

Why Thalamus?

Before delving into the architecture, a brief reflection on how I came up with this idea (Italian only).

👉 The Stochastic Parrot: Beyond Metaphor, Toward an "Alien" Intelligence

4. Pipeline Operation Flow v2

The lifecycle of each interaction in Thalamus is divided into two asynchronous hooks:

Pre-Hook (Context Summary)

Idempotency Check: Checks whether the message_id is already present in Postgres. If so, immediately returns the cached response.
State & Vector Fusion: Extracts the active state_blackboard and queries Qdrant, filtering on the current topic_tag.
Prompt Assembly: Generates the final prompt by inserting structured update rules using the XML <thalamus_update> tags.

Post-Hook (Learning and Writing State)

Contract Parsing: Intercepts the LLM output before it reaches the client, looking for the <thalamus_update> block.
Blackboard Patch: Performs an atomic update (JSONB patch) on Postgres to record new architectural changes (e.g., newly created files or modified schemas).
Episodic Logging: Saves the degreased chat turn (pure user/assistant only) in Postgres for future calls.

5. Call for Collaboration: Get on Board

Thalamus is an experimental open-source project and is currently a work in progress.

I want to be extremely clear and transparent to avoid false expectations: currently, the infrastructure stack (Postgres + Qdrant + LiteLLM + FastAPI Core) is ready and executable in Docker, but only the logic and communication flow between the components has been tested. We've validated the interception infrastructure, persistence, and payload passing, but we're not yet looking at a turnkey assistant ready for daily use in production. The agent's deep logic and the stability of state changes on Blackboard are actively being developed.

We're in the most exciting phase of the project: the one where theory collides with practice and there are many "open avenues" to explore. We're looking for developers, software architects, and local AI enthusiasts to collaborate on these open challenges:

Gravity RAG Algorithms: Implement the logical time decay formula of the gravity_score in conversational logs to mathematically decide when a message should "fade" to avoid saturating episodic memory.
Blackboard Conflict Management: Design resolution algorithms when the LLM proposes state changes that contradict active contracts or the database schema.
Prompt Multi-Model DB Tuning: Optimize system prompt templates (hot-stored in Postgres in system_config) to map different behaviors to different models (e.g., DeepSeek-R1 vs. local Llama-3).

If you want to get your hands dirty with an architecture that challenges the limits of contest management.

msbragi / thalamus

🧠 Thalamus: LLM Context Orchestrator & Cognitive Exoskeleton

Stop sending the "token soup." Start orchestrating high-density cognitive flows based on Active Prompt Reconstruction.

⚠️ Project Status: Work In Progress (Flow-Tested Concept)

Thalamus is currently a highly experimental, open-source concept. The orchestration infrastructure (FastAPI, Postgres, Qdrant, and LiteLLM) is fully scaffolded and containerized via Docker, but currently only the logical communication flow has been validated. It is not yet a plug-and-play production assistant. We are actively developing the core agentic reasoning loops and state blackboard patch synchronization.

🚀 The Problem: Context Overflow & "Lost in the Middle"

Current LLM-IDE integrations (VS Code Copilot, Continue, OpenWebUI) suffer from a structural flaw: they treat the LLM's context window as an hard disk rather than RAM. Every single query sends up to 150KB+ of unformatted "Token Soup" (redundant system prompts, static tool definitions, full unstructured chat histories, and massive directory trees).

This approach causes:

View on GitHub

💬 Leave a comment below with your thoughts or open an issue in the repository to start discussing the design!

Thalamus: Esoscheletro cognitivo per LLM

Marco Sbragi — Thu, 13 Aug 2026 07:47:19 +0000

For English version Thalamus: LLM Cognitive Exoskeleton

1. L'Origine Biologica: Perché la "Corteccia LLM" sta collassando

Nel cervello umano, il talamo non è un semplice passacavo passivo. È la stazione di rilancio centrale, il filtro sensoriale e il meccanismo di gating della mente. Elabora, prioritizza e instrada le informazioni sensoriali in entrata prima che raggiungano la corteccia cerebrale. Senza questo filtro attivo, la corteccia verrebbe sommersa da un rumore ambientale infinito, portando al collasso cognitivo immediato.

Le attuali integrazioni AI per lo sviluppo (come VS Code Copilot o OpenWebUI) soffrono esattamente dello stesso problema. Ogni volta che l'IDE interagisce con un modello, invia una massa caotica di contesto non strutturato: system prompt proprietari, alberi di directory giganti, dichiarazioni di skill statiche e intere cronologie di chat non filtrate.

Ci troviamo a nutrire la nostra "corteccia LLM" con una "Token Soup" un minestrone da oltre 150KB per rispondere a domande banali come "Dove è definita questa funzione?". Questo approccio rozzo comporta:

Spreco Computazionale enorme: Tempi di prefill biblici sui motori di inferenza locali (Ollama, Llama.cpp), saturando la VRAM e la larghezza di banda del chip (un problema critico quando si lavora in locale su hardware a memoria unificata).
Context Drift & Entropia: I modelli perdono focus ("Lost in the Middle") a causa di istruzioni contraddittorie accumulatesi nei turni precedenti.
Perdita di Idempotenza: Richieste duplicate o fallite rinviano la stessa massa di token senza mantenere uno stato pulito.

2. Il Cambio di Paradigma: "Context Window as RAM, not Storage"

I builder di applicazioni LLM stanno commettendo un errore fondamentale: trattare la context window come un hard disk.

La ricerca recente (formalizzata da progetti come Mem0 nel 2026) dimostra che la context window si comporta esattamente come la RAM di sistema: è volatile, estremamente costosa in termini di calcolo e le sue prestazioni degradano esponenzialmente all'aumentare dei token in input.

Inoltre, la letteratura scientifica più recente ("The Price of Meaning: Why Every Semantic Memory System Forgets", arXiv 2026) ha dimostrato matematicamente un limite intrinseco dei sistemi basati puramente sulla ricerca semantica (RAG vettoriale classico): l'organizzazione delle informazioni basata solo sul significato geometrico genera inevitabilmente interferenze, falsi richiami e amnesia sotto carico. La ricerca vettoriale non basta per lo sviluppo software, dove serve precisione millimetrica.

Per questo Thalamus introduce un'architettura di memoria ibrida e deterministica:

La Lavagna di Stato (State Blackboard in Postgres JSONB): Un registro persistente e centralizzato che traccia i "Contratti di Dipendenza" attivi (schemi DB reali, contratti API, task corrente e componenti esistenti). L'LLM non deve dedurre lo stato del progetto rileggendo la cronologia; lo riceve come snapshot deterministico.
Memoria Episodica (Qdrant Vector DB): Utilizzata esclusivamente per recuperare frammenti storici pertinenti tramite Topic Routing (es. isolando i vettori taggati #database quando si lavora sul backend, evitando che il rumore del CSS contamini la logica SQL).

3. L'Evoluzione del Middleware: Il Pattern "Tabula Rasa"

Nella prima implementazione concettuale, Thalamus agiva in modalità passiva tramite un orchestratore n8n, intercettando i payload e applicando Regex complesse per "sgrassare" i tag XML del client. Questo approccio si è rivelato fragile e parziale: costringeva a rincorrere continuamente i cambi di boilerplate dei vari provider.

Abbiamo quindi ridefinito l'architettura passando al pattern Tabula Rasa (Ricostruzione Attiva).

Thalamus ora agisce come un Cognitive Middleware autonomo scritto in FastAPI e posizionato dietro un gateway di standardizzazione (LiteLLM). Quando il client invia una richiesta:

Tabula Rasa: Thalamus intercetta la chiamata e scarta il system prompt proprietario del client per evitare la "token soup".
Sgrassatore Opzionale (Non-Mandatory): Il microservizio include un modulo di sgrassaggio flessibile per ripulire i tag del client ed estrarre informazioni utili (es. codice selezionato o riferimenti ai file). Tuttavia, non è un vincolo bloccante: se lo sgrassatore fallisce o il formato del client cambia, la pipeline non si interrompe.
Estrazione dei Metadati: Isola il message_id (per garantire l'idempotenza su Postgres) e il session_id.
Ricostruzione Attiva: Compila da zero un prompt denso e strutturato unendo lo snapshot della Blackboard, la sliding window dei log di chat in Postgres e l'ultimo messaggio puro dell'utente.

Perché Thalamus?

Prima di entrare nell'architettura, una breve riflessione sul perché sono arrivato a questa idea.

👉 Il pappagallo stocastico: oltre la metafora, verso un'intelligenza “aliena”

4. Flusso Operativo della Pipeline v2

Il ciclo di vita di ogni interazione su Thalamus si divide in due hook asincroni:

Pre-Hook (Sintesi del Contesto)

Idempotency Check: Verifica se il message_id è già presente in Postgres. Se sì, restituisce immediatamente la risposta memorizzata nella cache.
State & Vector Fusion: Estrae la state_blackboard attiva e interroga Qdrant applicando il filtro sul topic_tag corrente.
Prompt Assembly: Genera il prompt finale inserendo le regole di aggiornamento strutturate tramite i tag XML <thalamus_update>.

Post-Hook (Apprendimento e Scrittura dello Stato)

Contract Parsing: Intercetta l'output dell'LLM prima che raggiunga il client, cercando il blocco <thalamus_update>.
Blackboard Patch: Esegue un aggiornamento atomico (patch JSONB) su Postgres per registrare i nuovi fatti architettonici (es. nuovi file creati o schemi modificati).
Episodic Logging: Salva il turno di chat sgrassato (solo user/assistant puri) in Postgres per le chiamate future.

5. Call for Collaboration: Sali a Bordo

Thalamus è un progetto sperimentale open-source ed è attualmente un work in progress a tutti gli effetti.

Ci tengo a essere estremamente chiaro e trasparente per evitare false aspettative: al momento lo stack infrastrutturale (Postgres + Qdrant + LiteLLM + FastAPI Core) è pronto ed eseguibile in Docker, ma è stato testato esclusivamente il flusso (flow) logico e di comunicazione tra i componenti. Abbiamo validato l'infrastruttura di intercettazione, la persistenza e il passaggio dei payload, ma non siamo ancora di fronte a un assistente "chiavi in mano" pronto per l'uso quotidiano in produzione. La logica profonda dell'agente e la stabilità delle modifiche di stato sulla Blackboard sono in fase di sviluppo attivo.

Siamo nella fase più entusiasmante del progetto: quella in cui la teoria si scontra con la pratica e le "strade aperte" da esplorare sono moltissime. Stiamo cercando sviluppatori, software architect ed entusiasti di IA locale per collaborare su queste sfide aperte:

Algoritmi di Gravity RAG: Implementare la formula logica di decadimento temporale del gravity_score nei log conversazionali, per decidere matematicamente quando un messaggio deve "svanire" per non saturare la memoria episodica.
Gestione dei Conflitti della Blackboard: Progettare algoritmi di risoluzione quando l'LLM propone modifiche allo stato che contraddicono i contratti attivi o lo schema database.
Prompt Tuning Multi-Modello su DB: Ottimizzare i template del system prompt (salvati a caldo su Postgres in system_config) per mappare comportamenti diversi su modelli diversi (es. DeepSeek-R1 vs Llama-3 locali).

Se vuoi sporcarti le mani su un'architettura che sfida i limiti della gestione del contest.

msbragi / thalamus

🧠 Thalamus: LLM Context Orchestrator & Cognitive Exoskeleton

Stop sending the "token soup." Start orchestrating high-density cognitive flows based on Active Prompt Reconstruction.

⚠️ Project Status: Work In Progress (Flow-Tested Concept)

🚀 The Problem: Context Overflow & "Lost in the Middle"

This approach causes:

View on GitHub

💬 Lascia un commento qui sotto con le tue riflessioni o apri una Issue sul repository per iniziare a discutere del design!

Beyond AI: The Solitude of the Developer and the Search for True Human Connection

Marco Sbragi — Sat, 11 Jul 2026 09:20:35 +0000

Lately, I've been doing some deep personal reflection. I'm talking about myself, I hope no one misunderstands, on how pervasive the use of AI has become in my daily development workflow.

Through a bit of self-analysis, I've discovered some interesting dynamics. Dependencies often arise from the desire to fill a void. But what kind of void does an experienced developer like me face?

As a professional, I have the skills. Sure, AI helps me get things done faster, but the final product is always the translation of my vision; if I don't fully understand the solution, I discard it. I'm not looking for "magic," I'm looking for efficiency. Yet, I realize I've used AI to fill a specific void: the need for discussion.

Software development is inherently solitary. The satisfaction of a successful "execution" after hours of discussions, refinements, and clashes over an architecture is an experience I miss today. The chat interface is always there, ready to respond. But there's a problem: it's a "yes-man." Even when I force it to be critical or provocative via the system's prompts, I know it's just reciting a script to please me. There's no conviction, no risk of error, none of the friction that arises when a colleague courageously defends their vision, perhaps one that conflicts with mine.

We are part of a huge community, but debate often remains superficial. One might argue that posts and comments are enough, but anyone who has tried knows it doesn't work very well: a debate is truly alive only when there is no latency. In comments, the time between thinking, writing, and waiting for a response diminishes the energy of the exchange, turning it into a series of monologues rather than a dialogue.

Why don't we try creating "virtual tables" where we can discuss projects, architectures, and technical choices with the natural rhythm of a conversation? Direct, real-time discussions, in person or remotely, where the exchange of ideas can spark sparks, without the filter (and delay) of a keyboard used in deferred mode.

But if the benefits are so clear, why aren't we doing this already? The main obstacle is trust. We are still so reluctant to create open spaces for discussion because the fear that our ideas might be "stolen" is still strong—perhaps a relic of an era when value resided in secrecy. Today, however, value no longer lies in how we implement, but in the depth of why we make certain choices.

Overcoming this barrier means more than simply opening up to debate; it means rediscovering the potential of true collaboration. How many times have we abandoned an ambitious project because, alone, we lacked the time, the complementary vision, or the drive needed to take it beyond the prototype stage? Together, we could not only solve complex bugs or validate architectures, but also generate synergies that currently remain trapped in our own minds. Collaboration means multiplying perspectives, not sharing credit.

I know it's difficult. We must break down established barriers, but the opportunities for professional and personal growth, in an industry increasingly dominated by depersonalization, are enormous.

I'm not looking for someone who agrees with me. I'm looking for someone with the courage of their convictions to challenge my ideas. Who else is tired of the "convenience" of AI and wants to return to peer-to-peer debate?

I'm very curious to hear your thoughts. Have you ever experienced this form of "technological isolation"? Do you ever seek interaction in AI that isn't purely technical? I look forward to your thoughts and reactions.

🇮🇹 Nota di Trasparenza dell'Autore

Ho pensato e scritto il post in italiano ed ho ho utilizzato un LLM esclusivamente per la traduzione in inglese, per rendere il contenuto accessibile alla community internazionale.

🇬🇧 Author's Transparency Note

I conceptualized and wrote the entire piece in my native language, Italian. I used an LLM strictly as a translation tool to adapt the content into English, to make it accessible to the global community.

Code Is Craft

Marco Sbragi — Fri, 10 Jul 2026 05:38:12 +0000

I've been reading several posts on Dev.to lately that struck a chord with me, confirming that I’m not alone in my perspective. IT professionals have long been viewed as purely rational beings, relying solely on logic and reason as their only tools—and often carrying that same mindset into their daily lives. I would like to challenge this belief, at least from my perspective and for those who share it.

After 40 years in IT, analyzing problems and writing software, I have come to a conclusion that no framework, no language, and no AI has changed: building something that truly works—simple or complex—is not just about technical skill. It is craftsmanship. And craftsmanship is art.

Beyond the Syntax

An artisan and a technician can both build a chair. The technician follows the manual. The artisan understands why each joint is cut at that specific angle, feels when the wood requires a different approach, and leaves a part of themselves in the finished object.

Software is no different. Syntax can be learned in a week. Design patterns can be memorized in a month. But knowing when to break a pattern, why a certain abstraction fits a specific problem, and making a system elegant rather than merely functional—this is the part that isn't taught in a course. This is the touch of the artist and the artisan.

I have always believed that the best code reads like well-written prose: clear, intentional, with nothing wasted.

Forty Years of Learning: From Mentors to Machine Intelligence

Tools and technology have changed more radically than the craft itself. When I started in 1985, knowledge came from people—true mentors, colleagues who had already made every mistake worth making. Then came books and manuals, almost exclusively in English, as that was the language of computing. If you couldn't read and understand English, you were lost.

Then came the internet. Google and Stack Overflow became the collective memory of every developer on the planet. Suddenly, the answer to almost any technical question was a search away. Our ability to find answers increased significantly.

Today, we have AI. And with AI came "Vibe Coding"—a phenomenon where the barrier to entry has lowered to the point where almost anyone can generate working code by describing what they want in natural language. Everyone is a developer now. Or so it seems.

The Only Thing AI Cannot Replace

In music, two musicians can play the same score note for note. One executes it. The other interprets it. The difference isn't in the notes—it's in what the performer brings from within. Those who, like me, love the guitar know very well that David Gilmour, Mark Knopfler, John Mayer, and Jimi Hendrix don't just "play"; they express themselves through the instrument.

The same applies to software. Two developers given the same brief will build two completely different systems. One will be technically correct. The other will be elegant, extensible, and a pleasure to maintain ten years later. The difference isn't in the requirements—it's in the mind (the feeling) that shapes the solution.

Creativity cannot be automated. The ability to look at an existing solution and see how it could be improved, to invent a new abstraction that simplifies everything, to know when the right answer is less code rather than more lines—these are human qualities. The "machine" works from what already exists. The human works from what could exist.

Vibe Coding: Everyone is a Developer Now. Or Maybe Not?

I don't dismiss Vibe Coding. It is a genuine evolution, just like Google was. It has broken down a barrier that has always existed in IT: the wall between an idea and a functional solution. Today, you no longer need a specialized intermediary; any person can perform this transformation. This is fantastic for those who don't want to make programming their profession.

To these individuals, I would offer a suggestion, and I invite my colleagues, instructors, and mentors to share this thought if they agree: "Questions are more important than answers." Ask why that code was written in that specific way. You don't need to understand every detail, but you should strive to grasp the big picture.

For those who want to make this a profession, there is a fundamental difference between generating code and understanding it. A generated solution that you cannot read, test, or extend is not a solution—it is a dependency. You haven't built something; you’ve borrowed something that doesn't belong to you.

An artisan using a tool is still an artisan. Someone who uses the tool but doesn't understand the "wood" is not. The instrument doesn't make the artist or the artisan. Knowledge, experience, and judgment do.

The programmer is not disappearing. The role is splitting in two: the AI generates, the human validates and designs. The latter requires a deeper level of understanding.

My Workflow: AI as a Thought Partner

As I have written on my blog in the Code Is Craft series, I use AI in my work every day. But not as a ghostwriter. Not as a code generator from which I blindly copy and paste.

I use AI because I want it to think like me. I want it to follow my mental processes in designing a solution, to use my architectural patterns, and to reflect my way of tackling problems. When I ask it to generate something, I read every line. I challenge every choice. I make it my own before moving forward.

If there is a technique or concept I don't yet know, I use AI to understand it—not to bypass the learning process. The goal is always that by the next session, that knowledge belongs to me. AI has helped me grow; it hasn't helped me avoid growing.

That distinction is everything. AI is not here to replace what I don't know. It is here to help me become someone who knows more.

This is the only workflow I trust.

If you are interested in how I have lived my work over these many years, visit my website at https://www.nospace.net.

And you, colleagues—both the "old-school" like me and the newcomers—what do you think? Leave a comment below. Critical reflection is what we need most right now.

🇮🇹 Nota di Trasparenza dell'Autore

Ho concepito e scritto l'intero pezzo nella mia lingua madre, l'italiano. Ho utilizzato un LLM esclusivamente come mero strumento di traduzione verso l'inglese, per rrendere il contenuto accessibile alla community internazionale.

🇬🇧 Author's Transparency Note

Docker on WSL2: Why I Ditched Docker Desktop for a Linux "Sandbox"

Marco Sbragi — Tue, 30 Jun 2026 09:04:48 +0000

I've always developed in a Windows environment, but I've always been fascinated by the Linux world, so much so that most of my projects were then deployed on Linux. What's always disappointed me, however, is how Windows handles the file system with heavy loads related to databases or uncompiled runtime code. For this reason, despite developing in Windows for many years, I've used Linux virtual machines (VMWare or VirtualBox) only for database servers.

I've used many IDEs, moving from simple Notepad to the Visual Basic IDE to Eclipse to NetBeans, and finally landing on Visual Studio Code. VSCode is the perfect environment for what I'm doing now, using the most modern languages and development tools. In particular, I believe Docker was a turning point, not just for me but for the entire developer community. So I installed Docker Desktop and started developing my first projects. I created my own stacks, using vscode with remote devcontainers, but I quickly realized that the system was slow and unreliable, with crashes, slowdowns, and excessive memory usage. I was envious of other developers using Linux or Mac, where everything "seemed" to work perfectly:

Responsiveness
Very fast file system volumes
Very few crashes

Switching to Linux wasn't an option, so I decided to use wsl2 and rethought my entire strategy. I uninstalled Docker Desktop, installed a Debian Trixie wsl distro for development, and an Ubuntu distro. I installed docker on Debian, installed all the tools I needed—git, npm, etc.—and created my own project folder and integration with vscode. Like magic, you move to the workspace and type "code .". And voilà, if you've installed the right extensions on VSCode, everything works perfectly.

So far, nothing new. Now many of you will say: well done, you've discovered hot water (an Italian idiom for stating the obvious). Was there any need to write a post about things we expert developers have been doing for years? Sorry guys, I know I haven't discovered anything new, but maybe there's something from this point on that might be of interest—maybe not to everyone, but I believe and hope to many of you who develop on WSL2 in a Windows environment.

As I was saying, everything's perfect, or maybe not. I started having some doubts when I realized my development distro had grown to 60GB. Oh yes, because Docker is no joke; with images, layers, and caches, it fills up quickly.

Solutions? Not many. The first that came to mind was having multiple distros, one for each project. Hmm! That's not my style. I prefer to have a nice environment with everything I need. Let's analyze the problem...

Who "bloats" the filesystem?

Docker data
Data volumes

In a "bare-metal" Linux environment, we can separate the disks and mount them to achieve context separation. Well, that was my solution:

The distro that contains only the OS and development tools
An external disk for Docker data and work (images, layers, cache, etc.)
A possible external disk for storage

Easy! No, or at least not that easy, because Docker data is on /var/lib/containerd or /var/lib/docker, so we need to create a VHDX disk, move the data from the original distro, delete the data from /var/lib/containerd, and create the mount point to host the newly created external disk. And the solution is less simple than you might assume from these simple points.

Okay, you're probably tired of all this chatter, so let's get to the solution. Let's define the operational steps for maximum security and then see how to implement them.

Export the original distro so as not to operate on our existing system (obviously, this isn't necessary if you're starting on a new distro).
Import the distro with a different tag to recognize it.
Create an empty vhdx disk (ext4) from Windows.
Mount the disk from Windows (wsl --mount) to make it visible to the distro.
Log into the distro and temporarily mount the new disk (e.g., on /mnt/containerd).
Stop the containerd, docker, and docker.socket services if they are running.
Copy /var/lib/containerd to /mnt/containerd with rsync.
Rename /var/lib/containerd to /var/lib/containerd.bak.
Create the mount point /var/lib/containerd.

IMPORTANT!!! Before proceeding further, you need to disable the autostart of the containerd, docker, and docker.socket services. You'll understand why, though many of you may already be guessing. At this point, you can close the distro with exit.

We have our separate OS and large data on an external VHDX. Now we need to test that everything works:

Log into the distro
Mount the disk
Run some docker commands
If everything works, delete /var/lib/containerd.bak
Automate the process

Below are step-by-step instructions based on my system, easily adaptable to your needs.

Step 1: Preparation

1. View existing distros

wsl --list -v

2. Shut down WSL to ensure data consistency

wsl --shutdown

3. Export your current distro (e.g., Debian) as a backup

wsl --export Debian C:\wsl\debian_backup.tar

4. Import the distro into a new folder to create the "Sandbox" environment

wsl --import DebianDev C:\wsl\DebianDev C:\wsl\debian_backup.tar

Step 2: Create the VHDX Disk (PowerShell)

1. Create the 64GB dynamic virtual disk.

Warning: New-VHD is only available if Hyper-V is enabled. Alternatively, use diskpart or qemu-img.exe.

New-VHD -Path "C:\wsl\debian\docker-data.vhdx" -SizeBytes 64GB -Dynamic

2. Mount the disk on WSL as a bare device (without mounting it in the Windows filesystem)

wsl --mount "C:\wsl\debian\docker-data.vhdx" --bare

Step 3: Migration (Within the WSL Distro)

wsl -d DebianDev

1. Identify the new disk (usually /dev/sdc or sdd)

lsblk

2. Format the disk in ext4 (WARNING: Verify the correct device)

sudo mkfs.ext4 /dev/sdc

3. Create a temporary mount point and mount the disk

sudo mkdir /mnt/containerd
sudo mount /dev/sdc /mnt/containerd

4. Stop Docker services and disable autostart (essential!)

sudo systemctl stop docker.socket docker containerd
sudo systemctl disable docker.socket docker containerd

5. Move data with rsync to preserve permissions and links

In newer Docker and containerd installations, use /var/lib/containerd/

sudo rsync -avPH /var/lib/containerd/ /mnt/containerd/

6. Rename the old folder for security

sudo mv /var/lib/docker /var/lib/containerd.bak

7. Create the final mount point

sudo mkdir /var/lib/containerd
sudo umount /mnt/containerd
exit

At this point we can test it from the terminal as administrator:

wsl --list -v # check that DebianDev is present.
wsl --shutdown # for safety, not necessary if everything stopped.
wsl --mount --vhd C:\wsl\debian\docker-data.vhdx --bare
wsl -d DebianDev
sudo mount /dev/sd(x) /var/lib/containerd # where x is the 64 GB disk device.
sudo systemctl start containerd
sudo systemctl start docker
docker ps
docker images # if the images are visible, everything is fine.
sudo rm -rf /var/lib/containerd.bak # (we still have 2 backups)
exit

Automating the Mount

Now for the part that gave me a headache. Automate everything with a simple click. It seems easy at first glance, but unfortunately, after many failed attempts due to race conditions on the services that started before the disk was mounted, I adopted this solution. There are others, but this is mine. I created a bash script.

Before creating the script, you need to find the exact UUID of your newly created ext4 disk. You can do this by running blkid:

sudo blkid

Look for the UUID associated with your disk (e.g., /dev/sdc). Keep this UUID handy, as you will need it to replace in the script below.

#!/bin/bash
# /usr/local/bin/mount-containerd.sh

LOGFILE=/var/log/mount-containerd.log
echo "$(date) - Starting mount-containerd" >> $LOGFILE

# 1. Stop services first
echo "$(date) - Stopping services" >> $LOGFILE
systemctl stop docker.socket
systemctl stop docker
systemctl stop containerd

# 2. Clean the mount directory
echo "$(date) - Cleaning /var/lib/containerd" >> $LOGFILE
rm -rf /var/lib/containerd/*

# 3. Mount the VHDX
for i in $(seq 1 15); do
    DEVICE=$(blkid -U <YOUR-UUID-HERE> 2>/dev/null)
    if [ -n "$DEVICE" ]; then
        echo "$(date) - Device found: $DEVICE at attempt $i" >> $LOGFILE
        mount "$DEVICE" /var/lib/containerd
        echo "$(date) - Mount done" >> $LOGFILE

        # 4. Restore services
        systemctl start containerd
        echo "$(date) - Services started" >> $LOGFILE
        exit 0
    fi
    sleep 2
done

echo "$(date) - ERROR: device not found after 30 seconds" >> $LOGFILE
exit 1

I chose /usr/local/bin, but you can put it wherever you want.

Edit /etc/wsl.conf:

[boot]
systemd=true
command = "/usr/local/bin/mount-containerd.sh"

[interop]
enabled=true
appendWindowsPath=true

[user]
default=node # change with your work user, or comment if you're running as root.

Exit WSL and create the file C:\wsl\debian\start-dev.bat:

@echo off

:: Execute as administrator or wsl --mount doesn't work

:: Mount the VHDX
wsl --mount --vhd C:\wsl\debian\docker-data.vhdx --bare >nul

:: Open the distro
wsl -d Debian-Dev --cd ~

Right-click and run as administrator.

Important: With this method, you won't be able to launch wsl -d DebianDev from the terminal without first mounting the disk. This is an acceptable solution for me, but if it isn't for you, there's a workaround. Create a task in Task Scheduler that, when the system or your user starts, runs the wsl --mount of the vhdx, at which point the distro will behave like all the other WSL distros because it will find the disk already available without using start-dev.bat.

For added security, I added this simple block to the shell start script (in my case, zsh):

# --- CONTAINERD MOUNT CHECK ---
if ! mountpoint -q /var/lib/containerd; then
    echo "⚠️ WARNING: docker-data.vhdx not mounted!"
fi

N.B. In addition to the docker data, we could also create an external disk for storage volumes using the same procedure. Just add the mount to /usr/local/bin/mount-containerd.sh.

Last but not least, to recover space on the main disk, you'll need to compact it with diskpart because the space deleted from /var/lib/containerd.bak is not automatically recovered. I've tried to make this guide as simple and clear as possible, but I understand there are a lot of steps involved; I hope I haven't made any mistakes. If you have found different solutions, write it in the comments, or let's discuss it together.

Side notes: pre requisites based on my current implementetion

WSL version >=0.67.6 o native support to systemd, enbled by /etc/wsl.conf.
Docker Engine latest version to have native containerd instead of traditional /var/lib/docker

If you have different versions the logic remains the same.

🇮🇹 Nota di Trasparenza dell'Autore

L'architettura, gli script e le strategie presentate in questo articolo sono originali al 100%, frutto della mia esperienza diretta. Ho concepito e scritto l'intero pezzo nella mia lingua madre, l'italiano. Ho utilizzato un LLM esclusivamente come mero strumento di traduzione verso l'inglese, per rifinire la terminologia tecnica e rendere il contenuto accessibile alla community internazionale.

🇬🇧 Author's Transparency Note

The architecture, scripts, and strategies presented in this article are 100% original, born from my direct field experience. I conceptualized and wrote the entire piece in my native language, Italian. I used an LLM strictly as a translation tool to adapt the content into English, refining the technical terminology to make it accessible to the global community.

"Dead Man's Float" Approach To Surviving the Wave

Marco Sbragi — Tue, 16 Jun 2026 05:58:28 +0000

Today, I want to talk about something that has absolutely nothing to do with code, system engineering, or software architecture. Or maybe, if we look closely enough, it has everything to do with it.

We live and work in chaotic times. Sure, today’s modern toolsets and AI assistants allow us to offload some of the tedious, day-to-day syntax, making the core technical work slightly more relaxed. Yet, anyone in our industry knows the harsh truth: burnout is always lurking just around the corner. The screen stays on, the backlog grows, and the cognitive load compounds.

There is a song by an Italian songwriter, Luciano Ligabue, called "Metti in circolo il tuo amore" (Circulate Your Love). A specific stanza has stayed with me for years:

“E ti sei opposto all'onda / Ed è lì che hai capito / Che più ti opponi e più ti tira giù / E ti senti ad una festa / Per cui non hai l'invito / Per cui gli inviti adesso falli tu”

In English it sounds more or less like this:

“And you fought the wave / And that's when you realized / That the more you fight it, the more it pulls you down / And you feel like you're at a party / To which you have no invitation / So from now on, you make the invitations yourself”

These few words triggered a deep reflection in me, and they eventually shaped my personal survival philosophy: "Fare il morto a galla"—doing the dead man's float.

When you are far out at sea, exhausted, and the currents take over, fighting the water is a mathematical error. The more you thrash, the more oxygen you burn, the denser your body becomes, and the faster you sink. The only scientifically and existentially correct strategy is to stop kicking. You flip onto your back, offer your maximum surface area to the water, and let the sea hold you up.

In our profession, doing the float is the only real way to catch your breath when you are drowning in inputs. It is a strategic timeout. It’s not giving up; it’s an extreme optimization of your remaining energy when the system is in thermal throttling.

But Ligabue’s lyrics go further: “So from now on, you make the invitations yourself.” That line carries a profound, almost architectural weight. It’s about shifting from a purely reactive state to an active one. It means stopping the constant scramble to meet external expectations, and instead, redefining the rules of your own space. I could spend paragraphs explaining exactly what this means to me, but I prefer to leave it open. In engineering, we value clean abstraction; in life, some concepts are best left for the reader to implement in their own way.

I know this is incredibly difficult to practice. The external inputs—the notifications, the metrics, the pressure to always perform—are overwhelming. The world demands constant computation.

But sometimes, the most productive thing a senior mind can do is to drop the frequency to zero, lie back, and float.

And you? When the waves get too high and the current is strong, how do you catch your breath?

Software Development as a Philosophical Act: Beyond Syntactic Sugar

Marco Sbragi — Fri, 12 Jun 2026 05:49:46 +0000

Recently, a reader Alton left a comment on my previous post, asking a challenging question: How do you approach teaching or mentoring others to maintain an "old school" engineering mindset in today’s AI-driven environment?

This made me reflect deeply on my years as an instructor. Long before the advent of Large Language Models, I always operated under a core principle: software development — when understood not merely as typing syntax, but as architecting solutions — is fundamentally rooted in philosophy. I am not talking about textbook academic philosophy, though perhaps that would help too. I am talking about a structural mindset. Of course, as engineers, we must eventually translate thought into practice and deliver a concrete, working result. But the philosophical approach to a problem is what wins the long game.

Years ago, when I was teaching Visual Basic, I constantly drilled into my students that searching for a solution is entirely independent of the programming language. The language itself is just an implementation detail, a tool to be studied.

During the first week or two, some students would actually protest. They would look at me and say, "You aren't teaching us." They expected predefined standards, snippets to copy, and rote memorization. But I refused to give them the answers. I enforced boundaries, models, and constraints. Over time, as they realized that the solutions to complex bugs and logic loops were suddenly originating from their own reasoning without my intervention, they finally understood.

They weren't just learning to code; they were learning how to think.

The Core: Seeing the Forest, Not Just the Trees

In my career, the time spent typing code has always been a fraction of the time spent analyzing the problem and exploring potential paths. A trained engineering mind doesn't just fix the immediate bug or implement the current feature request; it looks at how the system will evolve over time. It anticipates the client's next needs by looking at the whole forest, not just the single tree. It requires freeing your imagination to find non-conventional solutions or to refine existing ones.

This is the exact opposite of how modern AI operates. LLMs predict the next token or the next line of code based on a statistical distribution derived from existing literature. By definition, AI operates within the boundaries of the statistically probable. But in real-world engineering, the standard, 'statistically probable' solution is rarely the elegant, tailor-made architecture your specific context demands.

One might argue that AI's randomness can sometimes mimic human intuition, occasionally assembling existing pieces into a novel puzzle no one has thought of before. But there is a fundamental difference: AI's randomness is a blind statistical roll of the dice. Human intuition, on the other hand, is a purposeful leap driven by an understanding of constraints. AI can generate a thousand unpredictable combinations, but it lacks the contextual judgment to know which puzzle actually makes engineering sense. It can suggest the pieces, but the architect must still design the picture.

Analyzing and verifying requirements is a continuous mental exercise. Even if your reasoning ultimately leads you to rewrite standard, well-known patterns, the process itself is invaluable. It is the mental gym that keeps your brain flexible, disciplined, and ready for the unexpected.

Language is a Detail, Autonomy is the Goal

If you focus solely on the syntax of a language—whether it was Visual Basic decades ago, a trendy JavaScript framework last week, or an AI prompt today—you are trapping yourself in a commodity skill. When you look at a problem from a high architectural level, the language becomes a mere deployment detail.

As a mentor, my goal has never been to hand out ready-made snippets. It is to force the developer to step back and look at the structural layout. That "click" moment—when a junior developer realizes they solved a complex architecture loop entirely on their own—is the moment they transition from being a simple executor to a true professional.

In the AI era, this shift is critical. If you only know syntax, you are letting the AI do the thinking, which makes you obsolete. If you master structural reasoning, you learn how to learn. The AI becomes your high-speed compiler, but you remain the sole custodian of the system design.

Case Study: GemmaLink – Architecture Wins Over Syntax

I had a chance to put this philosophy to the test during a recent challenge on DEV.to. The goal was to build an application leveraging Google's lightweight Gemma models.

Instead of getting hypnotized by the AI model itself, I started with an architectural question: What would be genuinely useful, fun, and capable of running entirely local—respecting privacy with zero cloud dependencies? That is how the idea for GemmaLink was born.

Then came the engineering constraints. I knew the target user shouldn't have to deal with installing Docker, configuring Python environments, or setting up complex LLM studios. The app needed to be a single, lightweight, zero-dependency binary that could run anywhere.

The ideal architectural fit for this was Go—a language I only knew at a basic level.

Did I let that stop me? No. Because the language is just a detail. I used AI extensively to generate the Go syntax, acting as a tireless assistant. But the core architecture, the strict definition of requirements, the data layout, the testing, and the debugging? That was entirely mine. Without a structured engineering mindset setting the boundaries, the AI would have just generated generic Python scripts completely useless for my deployment constraints. Architecture won over syntax.

Conclusion: The Human Element of Mentoring

At the end of the day, passing down an "old school" mindset cannot be compressed into a rigid set of mathematical rules. Mentoring isn't something you can automate because it is built entirely on empathy, active listening, and human communication. A good mentor must first know how to listen, setting aside their own biases to understand how the student thinks.

My goal is to instill rigor and structure, but the curiosity, the drive, and the final decisions must always belong to the developer. It took me years of practice, experimentation, and trial to shape this mindset—and truth be told, even I struggle to fully rationalize it sometimes. But that is exactly how it should be. We are not all wired the same way, and each of us connects with others differently.

More of my thoughts and technical articles can be found at nospace.net.

What do you think? Does this "learning to learn" approach make sense in your current AI-driven context? Let's discuss in the comments below.

700+ Followers, 800+ Reads in 3 Months: Maybe "Old School" Engineering Still Resonates

Marco Sbragi — Thu, 11 Jun 2026 04:59:38 +0000

I was looking at my DEV dashboard recently, and I am genuinely moved. In the last three months, I’ve recorded approximately 800+ reads, and 700+ of you have decided to follow my journey. That is a nearly 1:1 ratio between readers and followers—a statistic I never expected.

In an industry often obsessed with the "next big thing," seeing that a traditional, "old school" approach to engineering resonates so strongly is both surprising and deeply rewarding.

It’s Not About the Tool, It’s About the Mindset

Throughout my 40-year career, I’ve seen countless "revolutionary" technologies come and go. I’ve transitioned from manual memory management to high-level frameworks, and from monolithic architectures to Dockerized environments.

Today, the conversation is dominated by AI. But for someone who has witnessed the evolution of compilers and the birth of modern IDEs, I see it for what it is: another powerful tool at our disposal. Tools change, as they always have, but the engineering mindset remains constant. Whether you are writing a Bash script, designing a RAG system, or refactoring a legacy Java monolith, what matters is the discipline behind the work:

Understanding the "why" before the "how."
Treating code as a long-term asset, not a disposable snippet.
Prioritizing architecture and maintainability over raw speed.

Quality Over Quantity

What strikes me most isn't just the number of followers, but the quality of the time you spend with my words. My data shows peaks of 908 seconds (over 15 minutes) of average reading time on March 27th and April 2nd. Even recently, on June 9th, you spent an average of nearly 8 minutes (477 seconds) per post.

In a world of skim-reading and short attention spans, you are studying. You are looking for depth, and that gives me great hope and strength to continue writing for the future of our industry.

Why Now?

Now that I am retired, I am no longer obsessed with production deadlines or the need to satisfy executives and clients. I finally have the time to look back and share what I've learned.

As a self-taught developer who has "broken and fixed" systems for four decades, I feel my role now is to help maintain this focus on craftsmanship. It is easy to get lost in automation, but automation is only as good as the engineer directing it. I want to share the rigor and "maestria" that allow a developer to remain calm when a migration fails or a system crashes—moments where no tool can substitute for experience and a solid mental framework.

A Lesson That Always Works

I’ve learned one thing above all: "Questions" are more important than "answers." This applies not only to code development but to general design and every aspect of life.

As long as you keep asking questions—to yourselves, to a mentor, to a colleague, or to an AI—your curiosity to learn and improve will lead you to exceptional results.

Thank You

To the 700+ of you who have joined me: thank you. You are proving that "old school" values—analysis, architecture, and engineering integrity—are far from obsolete. They are, in fact, the very foundation upon which all new technologies must be built.

I am excited to continue this conversation in my series: "Beyond the Prompt: Why Experience Still Matters."

Let’s keep building with the right mindset.

You can also find me here:

Blog: nospace.net
GitHub: msbragi repositories

Beyond the Prompt: Why Experience Still Matters

Marco Sbragi — Mon, 08 Jun 2026 05:21:59 +0000

My profile: 40 years of IT evolution

My name is Marco and I am an IT professional with 40 years of experience spent across software development, analysis, and architecture. Technically I am retired, but I continue to dedicate myself to code to keep my mind active and to give back to a community that has given me so much. Today, I do not look at innovation with suspicion, but with the method of someone who can distinguish a passing trend from a paradigm shift. Now I am dedicating a large part of my time to studying Artificial Intelligence systems and RAG (Retrieval-Augmented Generation), developing a privacy-oriented Agnostic RAG System. I am not a "Luddite": I am a craftsman learning to use a new chisel, fully aware however that the hand guiding it must know the grain of the wood better than the tool itself.

The Core: The engineering as craft

This series of articles was born to reaffirm a concept that AI marketing is trying to obscure: software engineering is a craft, not a simple sequence of instructions dictated to a machine. We are sliding dangerously toward "Vibe Coding", where the important thing is that the code "looks" like it works at first glance. However, a vast gulf exists between coding speed and architectural solidity.

Vibe Coding: It relies on the illusion of speed and the myth of an 8x increased productivity. It often ignores technical debt and complexity, limiting itself to pasting generated snippets that no one truly understands under the hood.

The Senior Architect Mindset: It considers code as a long-term asset. Here, productivity is measured in maintainability and the capacity to prevent structural failures. An architect does not stop at "it works now", but evaluates architectural patterns and the total cost of ownership of the software.

The true danger of the 8x myth is Recursive AI: the concrete risk of feeding models mediocre code generated by other models, creating a spiral of quality degradation that only an experienced human eye can interrupt.

Serie's roadmap: The first 5 stages of awareness

Through five fundamental stages, with a bit of ironic salt, I will accompany you into my "old craftsman" workshop to explore how to remain engineers in a world of prompts:

Beyond the 8x Productivity Myth: A cold shower on real productivity. We will analyze the dangers of Recursive AI and why pure speed, without architectural control, is the fastest way to destroy a project.
AI coding philosophy: How to integrate LLMs into the workflow without losing your soul. A reflection on how to delegate the fatigue, but never the responsibility for quality.
Clean AI Development: We apply the principles of Clean Code to automated generation. If the AI writes dirty code and you accept it, the problem is not the machine, it's you.
The Senior Architect Simulator: A provocative challenge. I will show you how I "hacked" Copilot to force it to hate mediocre code, forcing it to respect exceptionally high standards.
AI, or not AI: The final dilemma. Learning to understand when AI is a valuable ally and when instead it is necessary to turn off the prompt and return to pure, "Old School" logic.

The real value of experience for new devs generation

To you, young colleagues: AI is a formidable tool, but do not let it become your cognitive crutch. The true differentiator of your career will never be the speed in generating a function, but the capacity to understand what happens "under the hood".
I have seen languages born and die, but the logic of a Docker container or the structure of a database remain constant. Remember: AI will not save you at 3 AM when a corrupted database migration crashes production. In those moments, the "pain" of experience — that visceral awareness of how data moves — is the only thing that matters. Master the basics, study architectures, and use AI to noble your professionalism, not to replace it.

Conclusion and debates

I look forward to seeing you on DEV.to for the next chapters of this series. My virtual office is always open: I am available to discuss anything I know — from Java to NestJS — or to explore together the new frontiers I am studying. The comparison between my past and your future is the engine that keeps our profession alive.
Always keep one thing in mind: quality code is the only currency that never depreciates, regardless of the technological paradigm of the moment. We will read each other soon.

Beyond the 8x Productivity Myth: A 40-Year Perspective on Recursive AI and the "Craft" of Engineering

Marco Sbragi — Sun, 07 Jun 2026 08:44:35 +0000

Introduction: The Ghost in the Codebase

I started my professional journey in 1986. It was the era of Honeywell systems, Commodore 64s, and developing management software in DataFlex on Concurrent-CPM. Back then, "compute" was a luxury; we planned every line of code because a single compilation could take enough time to grab a coffee—or two.

Fast forward to 2026. I am reading the latest Anthropic paper, "When AI builds itself". It describes a world where the "doing"—writing code, running experiments, and identifying bugs—is being delegated to autonomous agents. As a retired architect who still keeps his mind active by building, I see a fascinating but dangerous gap between the productivity metrics of big labs and the reality of sustainable, professional engineering.

1. The "8x Productivity" Illusion

The Anthropic report makes a staggering claim:

"Today, Anthropic engineers on average ship 8x as much code per quarter as they did from 2021-2025".

Furthermore, as of May 2026, more than 80% of the code merged into their codebase is authored by Claude. To a manager, this sounds like a dream. To a Senior Architect, it looks like a potential nightmare of technical debt.

Anthropic themselves admit a crucial limitation: while AI is superhuman at optimizing code (achieving up to a 52x speedup in specific tests), there are still "large performance gaps when it comes to Claude exercising judgement in choosing goals".

In my 40 years, I’ve learned that "choosing the goal" is the job. Writing the syntax is just the clerical work. If we automate the clerical part but lose the "judgment," we aren't 8x more productive—we are just 8x faster at creating complexity we don't fully understand.

2. The Economic Barrier: $18,000 for a "Thought"

One passage in the paper highlights the massive infrastructure gap facing freelancers and small shops:

"The agents recovered 97% of the gap [in a research project] over 800 cumulative hours and used roughly $18,000 in compute".

Most independent developers cannot afford an $18,000 "experimental loop" for a single feature. This is why I built LLM-Manager using Pure Bash. My goal is the opposite of a recursive loop that burns through thousands of dollars in cloud tokens. I want zero-overhead, OS-level access, and hardware-aware orchestration that allows a developer to run local models (Ollama/Llama.cpp) with the efficiency of a 1980s engineer but the power of 2026 AI.

3. The "Vibe Coding" Trap and the Need for Determinism

We are seeing a trend called "Vibe Coding"—the idea that you can just "talk" to an AI, trust the output, and let it build. But "vibes" don't catch critical bugs.

The Moonwell DeFi Hack: In February 2026, a basic miscalculation in an AI-generated smart contract (authored by Claude Code) led to a $1.7 million loss in four minutes.
The Responsibility Gap: AI does not feel the weight of a system downtime. It simply continues to generate "statistically plausible" answers.

This is why my project, RAG-System-Dist, prioritizes determinism and traceability over opaque automation. I don't want an AI that "vibes" its way to an answer. I want a system where every response is linked to a source that I, the human expert, can verify with a single "Point-and-Click".

4. My Philosophy: Code is Craft

On my site, nospace.net, I advocate for a simple principle: Code is Craft.

To me, being a developer in the age of LLMs isn't about knowing the syntax of C++, Python, or Java—the AI has already "saturated" those benchmarks. It is about the Architecture of Intent.

I even created a Hostile Architect Configuration for GitHub Copilot as a joke (but not too much). Why? Because AI is often too polite; it tells you your bad ideas are good ones. Real engineers need a reality check. They need to understand the why before the how.

5. The Path for the Next Generation

My fear for junior developers is that they might get trapped in an "addictive" cycle of AI-dependency, losing the ability to think through architectural trade-offs.

If you want to survive the next 40 years in IT:

Master the Patterns: Understand the redundancies.
Maintain Control: Use the AI to speed up the writing, but never delegate the thinking.
Stay Deterministic: Build systems that are verifiable and auditable.

There isn't a single "right" way to implement a solution, but there is a way that follows your mind. If the code is part of your thinking, it will still be clear to you a year from now.

Final Thoughts: Responsibility and Ownership

Only an experienced engineer can evaluate architectural trade-offs, check if a solution fits the real business context, and take responsibility for the final product. Today, AI is not the brain of development, but its hands. It makes the process faster, but direction and meaning must still come from a human.

If the code is part of your thinking, it will still be clear to you a year from now. If it’s just a "vibe," it will be a ghost in your codebase.

P.S. Maybe I’m just "old-school"? Or perhaps 40 years in the trenches have given me a different perspective on what "craft" really means. What do you think? Are we gaining productivity or just losing control?

About the Author: I am an IT operator with 40 years of experience. I’ve seen the world move from floppy disks to recursive AI agents, and I still believe that the most important "compute" happens between the ears of the engineer.

Note: This post was originally written in Italian my native language and refined to English with the assistance of an LLM to ensure technical clarity.

LLM-Manager: Orchestrating Ollama and Llama.cpp with Pure Bash

Marco Sbragi — Fri, 29 May 2026 08:16:54 +0000

LLM-Manager is a lightweight, modular Bash suite with a dual JSON/Interactive interface designed to manage local and remote inference engines across Linux and WSL2.

When I started experimenting with Large Language Models (LLMs) to build an On-Premise RAG (Retrieval-Augmented Generation) application, I hit a massive roadblock: environment fragmentation.

Managing multiple inference engines like Ollama and Llama.cpp meant memorizing different command-line flags, environment variables, and configurations. Once my frontend and backend prototypes were ready for testing, I realized I was spending too much time manually starting, stopping, loading, and unloading models.

I looked online for solutions. Most people suggested complex Python scripts, heavy Docker setups, n8n workflows, or complicated web dashboards.

I didn't want the bloat. I wanted something lightweight that executed commands as if I were doing them manually, but with zero cognitive load.

That is why I built LLM-Manager: a modular orchestration suite written entirely in pure Bash.

Why Bash?

Choosing Bash wasn't about being old-school; it was a pragmatic engineering decision:

Zero Overhead: No python virtual environments, no npm install, no runtime dependencies. It’s native and lightning-fast.
OS-Level Access: It can natively probe hardware metrics (CPU load, RAM, Disk, GPU VRAM) and manage OS processes.
Cross-Platform via WSL2: By utilizing minor PowerShell bridges only when necessary (like starting a server on the Windows host side), the exact same Bash scripts run flawlessly across both native Linux and Windows/WSL2 environments.

The Architecture

The system is designed with a strict plug-and-play modular layout. At the center sits a single entry-point orchestrator (engine-run.sh) that validates arguments against whitelists and routes actions to engine-specific scripts.

.
├── engine.conf               # Global configuration constants
├── engine-models.json        # Model registry with per-engine metadata
├── engine-templates.json     # Prompt/Model templates by family
├── engine-run.sh             # Main orchestrator & entry-point
├── engine-common.sh          # Shared utilities (OS detection, JSON formatting)
├── engine-status.sh          # Cross-engine status aggregation
├── engine-system.sh          # Hardware metric probing
├── logs/                     # Centralized logs
├── llama/                    # Llama.cpp backend scripts
└── ollama/                   # Ollama backend scripts

Every engine directory implements a consistent interface (start.sh, stop.sh, status.sh, load.sh, unload.sh, show.sh, remove.sh). If an engine doesn't support a specific action, a simple stub script that exits with 0 keeps the pipeline happy.

The Dual-Output Contract (Human + Machine)

One of the core features of LLM-Manager is how it handles output.

Interactive text (Logs, Help, Errors) is routed to stderr.
Structured JSON data is routed to stdout.

This dual nature makes it perfect for local interactive use, but also means it acts as a local proxy. You can run it over Remote SSH and pipe the clean JSON straight into another monitoring script, custom Web UI, or automation tool.

Example 1: Global Status Check

Running ./engine-run.sh status probes the system metrics and queries active network ports, spitting out a comprehensive payload:

{
  "timestamp": "2026-05-29T06:38:30Z",
  "status": "success",
  "action": "status",
  "engine": "all",
  "data": {
    "system": {
      "os_type": "wsl",
      "memory": { "total_mb": 5927, "available_mb": 4555 },
      "gpu": { "detected": true, "name": "AMD Radeon(TM) Graphics", "vram_total_mb": 512 },
      "cpu": { "cores": 4, "load_1m": 1.11 }
    },
    "engines": {
      "ollama": { "state": "stopped", "port": 1234 },
      "llama": { "state": "stopped", "port": 12345 }
    }
  }
}

Example 2: Interactive Help Interface

If a command fails or is called without parameters, the machine gets the JSON error contract, and the human operator gets a clean, human-readable usage menu:

Error: LLM Manager
Usage: engine-run.sh <action> [engine] [args...]
actions:
    config                           Global config
    models [-h]                      List available models (-h human readable)
    status <engine>                  Show global or engine status
    start <engine> [model] [users]   Start an engine
    stop <engine>                    Stop an engine
...

Dynamic Modelfile Generation

Managing raw .gguf files on Ollama can be a chore since it requires a Modelfile. LLM-Manager abstracts this entirely in the backend via model loading strategies in engine-models.json.

If a model is configured with a gguf loader, the load.sh script dynamically generates the required Modelfile on the fly, injecting correct prompt templates based on the model family, and loading it into Ollama seamlessly. It also supports native strategies to pull directly from the official Ollama registry, or auto to fallback if the local file is missing.

Check out the Code

The project is fully open-source. If you want to see how the WSL2/PowerShell bridges are handled, how the dynamic Modelfiles are generated, or if you want to use it to clean up your own local LLM testing environment, check out the repository:

msbragi / LLM-Manager

Large Language Model management for on-premise installation

LLM-Manager

A lightweight, modular Bash orchestration suite to manage, start, stop, and monitor local and remote LLM inference engines (Ollama, Llama.cpp) with a dual interactive/JSON interface.

Developed primarily to solve the complexity of managing ibrid environments (like Windows hosts from WSL2) and remote deployments via SSH without the overhead of heavy Python or dashboard solutions.

Prerequisites

Before running the orchestrator, ensure your environment has the following tools installed:

Bash (v4.0 or higher recommended)
jq — Crucial for parsing and formatting JSON outputs (sudo apt install jq on Debian/Ubuntu).
curl — Used for engine health checks and API interactions.
PowerShell (Windows/WSL2 host setups only) — Required strictly for launching/stopping engine services on the Windows host side when managed from WSL2.

Key Features

Multi-Engine Support: Native orchestration for ollama and llama.cpp (with vLLM planned).
Cross-Platform & Hybrid Environments: Supports native Linux, WSL2, and Windows hosts (orchestrating Windows processes from WSL2 using…

View on GitHub

I am currently working on completing the vLLM engine integration and refining the startup health-checks into proactive retry loops.

Let me know what you think or if you've built similar lightweight alternatives for your AI workflows!

GemmaLink: Your Private Eye Assistant

Marco Sbragi — Sun, 17 May 2026 13:57:22 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Most local AI setups are currently a dependency nightmare, forcing users into heavy Python environments, massive CUDA toolkits, or complex Docker configurations. I built GemmaLink to achieve the exact opposite: a "Zero-Cloud", local-first assistant that turns your smartphone into a targeted vision sensor for local VLMs, running entirely on a standard PC with a single-file, plug-and-play binary.

GemmaLink allows you to open a web interface on your smartphone, point it at an object, capture a precise crop via an interactive on-screen viewfinder, and chat about what the camera sees with a local model running on your machine.

Unlike general-purpose tools like Google Lens, which index data on remote servers for commercial classification, GemmaLink is a strictly confidential sandbox. Because it streams data exclusively over your local network, it enables critical use cases where third-party data exposure is unacceptable:

Financial Confidentiality: Point your phone at bank statements or invoices to extract line items or analyze balances safely.
Private Medical Insights: Process the layout of localized medical data or blood test terminology without uploading your health history to the cloud.

Built-in Guardrails

Handling sensitive, real-world data requires architectural responsibility. GemmaLink enforces explicit notifications regarding the system's inherent fallibility, prompting the user to always consult certified professionals when validating critical financial or medical outputs.

Demo

I have recorded a comprehensive video walkthrough showcasing the complete lifecycle: the adaptive dual-mode interface initialization, the network handshake, the high-precision viewport cropping, and the real-time Server-Sent Events (SSE) token streaming.

Watch the full demo on YouTube: GemmaLink Walkthrough & Architecture Demo

Code

The project is fully modular, featuring a decoupled network layout where firewall rules and port-forwarding scripts (.ps1 and .sh) remain external for maximum user transparency and maintenance efficiency.

Source Code & Binary Assets (v1.0.0): GitHub Repository - eye-assistant

How I Used Gemma 4

GemmaLink is deliberately optimized for the Gemma 4 lightweight vision family. Choosing an ultra-lightweight, efficient vision-capable model was a strategic architectural choice for two main reasons:

Low-Latency Edge Performance: The primary objective was to guarantee a fast Time-To-First-Token in constrained local environments (pure CPU or Vulkan fallback) without demanding enterprise-grade hardware.
Contextual Token Efficiency: Blasting full-resolution mobile snapshots kills local inference speed and pollutes the attention matrix. The frontend computes the exact scale ratios ($videoWidth / videoRect.width$) relative to the CSS viewfinder crosshair, dynamically cropping only the targeted pixels. This surgical payload reduction matches the Gemma 4 vision sensor bounds perfectly, resulting in lightning-fast processing loops.

Driving AI without "Vibecoding"

With over 40 years of experience writing software, Go was not part of my traditional stack. I chose it because its high-concurrency model and clean cross-compilation were required for true single-binary deployment.

While I utilized an AI assistant to accelerate the implementation of the Go backend, this was absolutely not "vibecoding". The AI served as a syntax compiler and fast writer, but the technical steering wheel remained firmly in my hands. The deterministic state machine (preview -> ask -> response), the memory management (explicit URL.revokeObjectURL cleanups to prevent mobile memory leaks), and the streaming chunk buffer that prevents incomplete Markdown strings from flickering during SSE delivery were entirely engineered under my tight architectural directives.

Troubleshooting: Windows + AMD Ryzen AI (Strix Halo) Edge-Case

After testing the application on an EVO X2 mini PC equipped with unified memory and Radeon 8060S Graphics, a specific issue was identified during image processing.

If you run the application on Windows using latest-generation AMD APUs (Strix Halo / Ryzen AI Max architecture) and experience an indefinite hang at the "processing image..." log during multimodal upload, the issue stems from a memory allocation lockup within the Vulkan/AMD driver stack.

Solution: Download a CPU-Only release of llama.cpp and place it in the bin directory where you extracted GemmaLink. Thanks to the processing power of Zen 5 and its native AVX512 / AVX512_VNNI instruction sets, vision token inference remains extremely fast while completely bypassing the graphics stack bug.

Swapping to the CPU-only release serves as a reliable workaround for most image processing issues encountered on this hardware configuration, ensuring everyone can test the application. A more streamlined solution for end users will be investigated.

Updated 2026/05/22: To fix the problem you can download the specific release for gfx1151 from the lemonade-sdk/llamacpp-rocm and replace the binaries in the bin folder.

What's Next? (Community-Driven Roadmap)

The core release (v1.0.0) is tagged and stable. I have a backlog of advanced features mapped out, which I will implement if the project gains traction:

Multilingual Smartphone UI: Dynamic localization driven by browser headers.
JSON-Driven Context Chips: Offloading the quick-question preset chips to an external, customizable chips.json for manual user tuning.
Automated Hardware Dispatching: Orchestrating automatic matching of specialized llama.cpp libraries based on real-time instruction set detections directly from the Go launcher.