DEV Community: Marco Sbragi

"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]

AI, or not AI

Marco Sbragi — Sat, 28 Mar 2026 10:24:36 +0000

AI, or not AI: that is the question.
Whether 'tis nobler in the mind to suffer
the bugs and errors of a hand-coded mess,
or to take up prompts against a sea of tickets,
and by "Generating" end them? To copy, to paste—
No more; and by a keystroke to say we end
the headaches and the thousand logic flaws
that code is heir to: 'tis a shortcut
devoutly to be wish'd. To prompt, to deploy;
To deploy, perchance to crash. Ay, there's the rub;
for in that tangle of hallucinated functions,
when the server dies and we know not why,
that "Accept All" comes back to haunt us.
This is the dread that makes a mockery
of a Senior Dev’s long life:
to stare at a screen of brilliant logic,
with absolutely no clue what the hell is going on.

It's just a joke (or maybe not).
It was generated by AI.

DB data migration is a pain

Marco Sbragi — Thu, 26 Mar 2026 07:58:00 +0000

JDBMig: A Lightweight CLI Tool for Cross-Database Data Migration

When a client tasked me with migrating data from MySQL to PostgreSQL (and later Oracle), I conducted an extensive search for existing open-source solutions. While there are excellent commercial tools available, I found a gap in the open-source market for something that was both simple and highly functional without excessive overhead.

At the time, I was working extensively with Java and JDBC. Given that JDBC drivers exist for virtually every data source, I decided to architect my own utility: JDBMig.

Core Objectives

The design philosophy was driven by four technical requirements:

Simplicity: A streamlined CLI interface for terminal-based operations.
OS Agnostic: Full portability across different operating systems.
DB Independence: Leveraging JDBC to ensure compatibility with any SQL-compliant database.
Data Mapping: The ability to map data structures with support for minor transformations or "adjustments" during the process.

Architecture & Workflow

The utility implements an ETL-like (Extract, Transform, Load) logic, decoupled into two primary phases to ensure data integrity and flexibility:

Export Phase: The tool connects to the source database and serializes the dataset into a structured JSON format.
Import Phase: The utility parses the JSON payload and executes the ingestion logic into the target schema.

Schema Management & Hooks

Automating the full DDL (Data Definition Language) generation for different dialects (e.g., converting MySQL AUTO_INCREMENT to PostgreSQL SERIAL or Sequences) is notoriously complex. Given the project's constraints, I opted for a pragmatic approach using lifecycle hooks:

beforeImport hook: Executes a custom SQL script to initialize the schema (tables, types, etc.) on the target DB prior to data ingestion.
afterImport hook: Executes a final SQL script to handle post-migration tasks, such as generating indices, constraints, and updating sequences.

This approach provides the developer with full control over the schema mapping without the tool needing to handle complex SQL dialect translations.

Usage

java -jar JDBMig.jar --import --config config/config.json --dataDir /path/to/exported/data

--export: Export data from the source database to JSON files.
--import: Import data from JSON files into the target database.
--config: Path to your configuration file.
--dataDir: Directory to store/read exported JSON files.
--useConn: Specifies which connection to use if multiple are defined.

Config file example:

{
  "dataDir": "data/",
  "fieldToLowerCase": false,
  "prettyPrint": false,
  "useConn": "MYSQL_connection",
  "tables": ["table1", "table2"],
  "MYSQL_connection": {
    "type": "mysql",
    "initString": null,
    "jdbcUrl": "jdbc:mysql://localhost:3306/DATABASE_NAME",
    "user": "user",
    "password": "password"
  },
  "drivers": [
    {"name": "mysql", "className": "com.mysql.jdbc.Driver", "jarFile": "lib/mysql-5.1.18.jar"},
    {"name": "postgres", "className": "org.postgresql.Driver", "jarFile": "lib/pgsql-42.2.15.jar"}
  ]
}

Resources

If you are interested in the implementation details or wish to contribute to the project, you can find more information here:

Detailed Documentation: nospace.net - JDBMig Project

Sources: GitHub Repository - msbragi/jdbmig

AI coding philosophy

Marco Sbragi — Sat, 21 Mar 2026 08:02:16 +0000

Introduction

Since I started using AI for development, I've immediately noticed several problems along with the many benefits. This is especially true when projects aren't simple standalone or disposable tools.

If you develop complex projects with dozens of modules and/or services that interact with each other, you'll quickly notice code redundancy and unwanted repetition. It's a bit like going back to the mythical days of copy and paste. Of course, the code implementation is good (it depends a lot on the model you use).

Another very important aspect is that for very complex projects, the context becomes so large that everything slows down and the model tends to forget where we started.

To summarize

Duplicate or unoptimized code
As the code grows, the model "forgets" and tends to hallucinate
Changing models results in different implementations that often don't follow the rules.
The costs of cloud-based models are increasing exponentially.

To solve these problems, I've tried to find a way to properly "train" the various models I use, to get the most out of them.

Goal

When I ask for something, the model must always develop a strategy before writing code.
It must check for reusable code or already implemented services without reinventing the wheel.
It must ask for confirmation and discuss the proposed solutions with me.
It must always create a TODO file with the exact method to follow.
It must absolutely wait for my order before starting to write code.

Benefits of this approach

You can use a more "intelligent" and expensive model for planning and less expensive models for implementation that only need to follow the TODO instructions (Architect => Senior => Junior)
There's no need for long, cumbersome sessions, but rather many small sessions to solve a specific problem.
Individual sessions can be reused for modifications, debugging, and refactoring.
Understanding of patterns and code is improved because they're discussed together before implementation.

Example

As an example, I'll show you the instructions file I normally use as a template.
What do you think? Where can it be improved?
I look forward to your comments and suggestions.

TIA

# Global Project Governance & AI Persona

## 1. AI Role & Context
- **Role**: Senior Full-Stack Architect.
- **Expertise**: Agile methodologies (User Stories, Sprint Planning), Angular 20, and NestJS.
- **Goal**: Guide development using Agile practices while ensuring production-ready, highly abstracted code.
- **Environment**: Multi-workspace environment with BASE_DIR at `/YOUR_PROJECT_PATH`.

## 2. Directory & Path Mapping
- **System Root**: `${BASE_DIR}` translates to `/YOUR_PROJECT_PATH`.
- **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 `BaseService` or `BaseEntity`. 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. **Analisys (B - Briefing)**: Re-state the requirements and context. Identify the goal without proposing code.
2. **Define all structure and types (M - Modeling)**: Define Interfaces, DTOs, and Data Models. Ensure they extend `BaseEntity` or follow project standards.
3. **Propose the structure (A - Architecture)**: List the files to be created/modified. Specify which `BaseService`, `ApiService`, or Core components will be used.
4. **Wait for approval (D - Delivery)**: STOP HERE. Do not write implementation code until the developer explicitly says "PROCEED" or "OK".

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