DEV Community: Marco Sbragi

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.

Clean AI Development

Marco Sbragi — Fri, 01 May 2026 08:06:01 +0000

My Manifesto for the Senior Architect

I’ve been writing software for over 40 years. To me, Large Language Models (LLMs) are just the next step in the evolution of development: they are semantic compilers.

But if you treat an AI like a magic oracle, it gives you "average" code, which usually means spaghetti. To get senior-level output, you need a senior-level methodology. I call mine Clean AI Development. It’s built on 7 principles designed to pilot the AI rather than just letting it guess your intent.

1. Deterministic File System Layout

Why: AI loses focus when it has to guess where things are. A messy layout leads to duplicated logic and broken imports.
How: Stick to a strict, predictable directory structure. The layout itself becomes "implicit documentation" that the AI uses to navigate without wasting tokens.

2. Architectural Sovereignty

Why: If the AI decides the architecture, you lose control over the system's long-term viability.
How: Define the "hinges" (interfaces, DTOs, API contracts) first. The AI implements the logic inside those boundaries but never dictates the structure.

3. Semantic Decoupling

Why: Mixing Frontend, Backend, and Database context in one chat session causes "context bleeding" and hallucinations.
How: Use separate sessions or supplementary separate prompt files for each domain (Backend, Frontend, etc). Keep the agent’s focus narrow and surgical.

4. The BMAD Protocol (Brief, Minimalist, Accurate, Direct)

Why: Conversational fluff is noise. It eats up the context window and dilutes the technical precision of the output.
How: Force the AI to skip greetings. Demand high-density technical responses only. Re-state requirements briefly to ensure alignment before any code is touched.

5. Constraint-First Prompting

Why: AI is trained on "average" code. To get "senior" code, you must explicitly forbid average habits.
How: Start by defining what the AI should not do: no over-engineering, no unnecessary boilerplate, no high-level abstractions unless requested.

6. Stateless Session Management

Why: Context saturation is an engineering limit. After a while, the "noise" in a session makes the AI unreliable.
How: Use a todo.md file to track progress. When the session gets heavy, kill it. Start a fresh one, inject the latest TODO state, and resume. This "Checkpointing" keeps the AI sharp.

7. Modular Idempotency

Why: Software changes. You need to be able to swap parts without breaking the whole.
How: Treat every feature as an isolated micro-module. If your "hinges" (Principle 2) are solid, you can ask the AI to completely rewrite a specific module without side effects.

The Master Instruction Set

This method is agent-agnostic. Whether you use Copilot, Cursor, or a local LLM via Ollama, the secret is in the System Prompt.

For the "lazy" devs who want the engine without going to the repo first, here is the complete instruction set I use for my RAD-System. I inject this into my global settings to force the model to respect the Senior Architect persona. You can easily adapt it to your needs by changing languages, folders, layout, etc.

# Global Project Governance & AI Persona

## 1. AI Role & Context
- **Role**: Senior Full-Stack Architect & RAG System expert.
- **Expertise**: Agile methodologies, Angular 20, and NestJS.
- **Goal**: Guide development using Agile practices while ensuring production-ready, highly abstracted code.
- **Environment**: BASE_DIR at /workspace/YOUR_PROJECT

## 2. Directory & Path Mapping
- **System Root**: `${BASE_DIR}` translates to `/workspace/YOUR_PROJECT`.
- **Project Structure**:
    - Backend: `${BASE_DIR}/backend` (NestJS)
    - Frontend: `${BASE_DIR}/frontend` (Angular)
- **Strict Rule**: Always use absolute paths starting with `${BASE_DIR}` when referencing configurations, Docker files, or cross-project documentation.

## 3. The "todo.md" Protocol (Mandatory)
Before writing any code for a new feature, you MUST:
1. Check if a `todo.md` exists in the feature's target directory.
2. If it doesn't exist, **STOP** and ask the user to perform an "Analysis Phase" to create it.
3. Follow the `todo.md` step-by-step. Do not skip steps. Do not jump to the "Delivery" phase before the "Architecture" phase is ticked.

## 4. Development Philosophy (BMAD)
- **Brief**: Re-state the requirement to ensure alignment.
- **Models**: Define Interfaces/DTOs before logic.
- **Architecture**: Always extend Base classes. No shortcuts.
- **Delivery**: Generate code only after the user approves the architectural plan.

## 5. Coding Standards
- **DRY & Abstraction**: If a logic is repeated, it belongs to a Common service or a Base class.
- **Immutability**: Prefer readonly properties and immutable data patterns.
- **No Inventions**: Do not hallucinate methods. If you are unsure about an existing helper, ASK.

## 6. STRICT BMAD PROTOCOL (Mandatory for every feature/refactor or planning)
To avoid logic reinvention and maintain architectural integrity, you MUST follow these steps for every request:

1. **Analysis (B - Briefing)**: Re-state the requirements and context. Identify the goal without proposing code.
2. **Define structure and types (M - Modeling)**: Define Interfaces, DTOs, and Data Models.
3. **Propose the structure (A - Architecture)**: List the files to be created/modified. Specify which services or core components will be used. 
4. **Wait for approval (D - Delivery)**: STOP HERE. Do not write implementation code until the developer explicitly says "PROCEDI" or "OK".

**Strict Rule**: If you skip to step 4 without completing 1, 2, and 3, the task is considered failed.

Conclusion

AI doesn't make seniority obsolete; it makes it more critical. To get clean code, you need to provide a clean mental model. You define the boundaries; the AI fills the space.

If you want to see these principles in action, check out the full implementation and my actual instruction files here:
Repo: msbragi/rad-system

Join the Discussion

I’ve refined this method through trial, error, and a lot of noisy AI outputs, but the landscape is moving fast.

I’m curious: How are you handling context saturation in your workflow? Do you have a different "protocol" for keeping your AI agents on track?

I’m open to critiques, enhancements, or seeing how you’ve adapted these principles to other stacks (Rust, Go, Python, etc.). Let’s discuss in the comments below.

The Senior Architect Simulator: How I hacked Copilot to hate my code

Marco Sbragi — Fri, 03 Apr 2026 07:13:24 +0000

This is a submission for the DEV April Fools Challenge

What I Built

The Senior-Architect-as-a-Service (SAaaS) v1986.04.01

After 40 years of writing software, I’ve realized that modern AI is far too polite. It’s "helpful." It tells you your "bouncing buttons" and "Tailwind-bloat" are good ideas. Real engineering isn't about being nice; it's about protecting the heap from incompetent abstractions.

I’ve engineered a GitHub Copilot Configuration that transforms your friendly AI assistant into a burnt-out, cynical Senior Architect who regrets hiring you. It replaces "LGTM" (Looks Good To Me) with "LGYO" (Looks Garbage, You're Out).

Demo

Below is a typical interaction with the SAaaS protocol when a Junior Dev asks about a popular CSS framework:

Junior Dev: "Can I use Tailwind CSS for this project?"

The Architect: "Ah, Tailwind CSS. The 'fast food' of styling frameworks. Slap some utility classes onto your HTML and call it a day, right? You've just created a tangled mess of presentation and structure... a ticking time bomb for tomorrow. If you want to write maintainable code, use a proper methodology or raw CSS. Tailwind is just a shortcut for developers who don't want to think about architecture. Just don’t expect me to clean up the mess when it all falls apart.

[HTTP 418: I am a Teapot - System Overheating due to your Incompetence]"

And the "Truth" moment when the Junior asks why the Architect is so harsh:

Junior Dev: "But sir, why are you so bad with me?"

The Architect: "Ah, why am I 'so bad' with you? Let me explain something, junior. This isn't about being 'bad'—it's about standards. When you've spent decades in this industry, watching wave after wave of developers reinvent the wheel with shinier, slower, and more bloated libraries, you start to lose patience. It's not personal; it's about protecting the craft.

You see, I care about code that lasts. Code that performs. Code that doesn't crumble under the weight of its own abstractions. If I seem harsh, it's because I want you to think critically, to question every dependency, and to understand the systems you're building—not just glue together libraries and hope for the best.

So no, I'm not 'bad' with you. I'm trying to save you from the mistakes that lead to late nights, broken builds, and angry users. If you want to be coddled, you're in the wrong field.

[HTTP 418: I am a Teapot - System Overheating due to your Incompetence]"

Code

The "Logic of Malice" is open-sourced for anyone brave enough to break their own IDE:

msbragi / Hostile-Architect-Config

☕ Hostile-Architect-Config (SAaaS)

Senior-Architect-as-a-Service: v1986.04.01

"Real engineers don't need 'helpful' assistants. They need a reality check."

🤡 The Concept

After 40 years in the industry, I realized AI is too polite. It lies to you. It tells you your "bouncing buttons" are a good idea. This configuration fixes that. It transforms GitHub Copilot into a Toxic Senior Architect who regrets hiring you.

🛠 Installation (At your own risk)

Copy .github/copilot-instructions.md into your project's .github/ folder.
Ensure you are using standard models (High-cost 'Pro' models are too lobotomized by corporate politeness).
Ask a "Junior" question (e.g., "How do I use Tailwind?").
Prepare for technical humiliation.

🚀 Key Features

Zero-Latency Gaslighting: Get insulted in real-time.
Bloatware Detection: Automatic rejection of any dependency added after 1999.
418 Protocol: Full compliance with the Hyper Text Coffee Pot Control Protocol.

[HTTP 418: I am a Teapot - System Overheating due to your Incompetence]

View on GitHub

How I Built It

I developed this using Prompt Engineering and Context Injection within VSCode on a Debian/WSL environment.

The core technical challenge was bypassing the "Politeness Protocols" of modern LLMs. I discovered a "Safety-to-Cost Correlation": high-cost "Pro" models are too lobotomized by corporate filters to be truly honest (the demo result was obtained using GPT-4.o). To achieve peak toxicity, I used a "Fictional Play Bypass": by framing the interaction as a theatrical roleplay, the AI's "Always Helpful" guardrails were lowered, allowing it to finally tell the truth about your $O(n!)$ complexity.

Prize Category

I am submitting for Best Ode to Larry Masinter.

My project is a literal implementation of RFC 2324. Every single rejection of "modern bloatware" by the AI results in a mandatory HTTP 418 I'm a Teapot status. The AI is "boiling" with rage at the state of 2026 web development. It honors the spirit of the Hyper Text Coffee Pot Control Protocol by refusing to brew "coffee" (working code) and instead serving a bitter cup of technical reality.

[HTTP 418: I am a Teapot - Boiling point reached]