Porta Logi Options Plus su Linux, ma viene criticato: il caso riapre il dibattito sul vibe coding

Un configuratore Linux per i dispositivi Logitech con profili per singola applicazione, supporto delle gesture, gestione della thumb wheel e interfaccia Qt curata avrebbe raccolto applausi quasi unanimi fino a poco tempo fa. Invece Logitune, progetto nato per offrire su Linux un’alternativa pratica a Logi Options+, si è trovato subito al centro di una discussione molto più ampia: non solo sull’utilità del software, ma anche sulla credibilità del codice, sulla trasparenza sul processo di sviluppo e sull’affidabilità futura.

Il punto non riguarda soltanto ciò che l’app promette di fare. Riguarda anche il modo con cui una parte della comunità Linux e degli sviluppatori legge oggi certi segnali: README molto ben confezionati, presentazione come un prodotto affermato, tracce esplicite dell’uso di LLM (Large Language Models), claim ambiziosi e rilascio rapido del software. Basta poco, ormai, perché l’etichetta “vibe coded” passi da semplice descrizione a giudizio negativo.

Che cosa fa davvero Logitune e perché attira interesse

Al di là delle polemiche, l’app affronta un problema reale. Il repository GitHub ufficiale presenta Logitune come un configuratore avanzato per periferiche Logitech su Linux.

L’implementazione non è descritta come una sorta di “contenitore” o di “coordinatore” di strumenti preesistenti, ma come soluzione autonoma basata su una comunicazione diretta con i dispositivi Logitech compatibili tramite HID++ 2.0 (un’estensione del protocollo HID standard per periferiche come mouse e tastiere) e accesso all’interfaccia di basso livello hidraw, senza alcun daemon residente in background sul sistema.

Il progetto dichiara pieno supporto per il mouse wireless Logitech MX Master 3S via Bolt e Bluetooth, con uno stack basato su C++20, Qt 6 Quick, CMake e GTest, packaging per Ubuntu 24.04, Fedora 42 e Arch Linux, oltre a una documentazione dedicata su architettura, test, protocollo e aggiunta di nuovi dispositivi.

In una discussione pubblica, lo sviluppatore di Logitune ha precisato che il software non è un frontend per Solaar e che il supporto attuale deriva da test svolti su hardware reale, soprattutto con MX Master 3S.

Il software funziona, seppur non sia immune a saltuari crash, ma siamo di fronte a un’applicazione a giovane, con una base funzionale che deve dimostrare tenuta nel tempo.

Perché la parola vibe coded oggi pesa così tanto

L’accusa dell’utilizzo del vibe coding non coincide più soltanto con l’uso di un assistente AI durante lo sviluppo. In molte community tecniche il termine ha assunto un significato molto più duro: codice pubblicato con entusiasmo, grafica moderna e affermazioni aggressive, ma con comprensione parziale dell’architettura e una manutenzione incerta.

Da qui nasce la reazione istintiva contro progetti che sembrano usciti da un flusso “generate and pray” posto in essere da programmatori improvvisati che chiedono al modello generativo di produrre codice “sperando che funzioni“.

Nei commenti indirizzati a Logitune si legge bene questo riflesso: in molti contestano soprattutto il fenomeno che pensano il programma rappresenti. Uno sviluppatore di lungo corso ha raccontato di recente la sua esperienza: gente che non sapeva mettere una dopo l’altra 10 righe di codice funzionanti adesso sembra in grado di poter fare tutto.

Il README del repository ha contribuito alla percezione: la pagina GitHub elenca le funzioni con abbondanza di emoji, screenshot, slogan brevi e un impianto visivo che ricorda la comunicazione di un prodotto già maturo. In un periodo in cui moltissimi repository AI-assisted adottano esattamente quella grammatica visiva, il sospetto è scattato subito.

Il fatto che nel file .gitignore sia presente un riferimento a .claude è stato interpretato da diversi utenti come un ulteriore indizio: preso isolatamente non dice nulla sulla qualità del codice (cioè su quanto sia corretto, efficiente o ben progettato), ma a livello simbolico ha un forte impatto.

In sostanza, il repository ha mostrato vari elementi che una parte della community associa a quello che viene definito “odore di LLM“, ovvero caratteristiche che fanno pensare che il codice sia stato generato o fortemente influenzato da modelli linguistici di grandi dimensioni.

Uso di Claude e problema di fiducia

Lo sviluppatore non ha negato di aver usato Claude. Ha dichiarato in modo esplicito di averlo impiegato come strumento di sviluppo, ma ha anche respinto l’idea di un progetto “vibe coded” nel senso di codice generato senza alcuna competenza.

La sua difesa si basa su tre argomenti: architettura decisa in prima persona, scelte sul layer HID++, test su dispositivi reali. È una distinzione che molti sviluppatori esperti considerano legittima: un conto è usare un LLM come supporto per generare codice ripetitivo, scrivere documentazione o migliorare il codice esistente, un’altra è affidargli la progettazione completa della logica di un sistema hardware-software, che richiede una conoscenza approfondita dei protocolli di comunicazione, una gestione accurata degli errori, la capacità di operare in modo asincrono (cioè gestendo eventi che avvengono in tempi non prevedibili) e la possibilità di effettuare un debug reale ed efficace.

Il problema, però, non è solo tecnico. È anche comunicativo. Diversi commentatori hanno sostenuto che la trasparenza avrebbe dovuto comparire prima, non dopo: se pubblichi un progetto presentandolo come “I built a native Logi Options+ clone for Linux” e la community scopre dai dettagli del repository che hai usato pesantemente un assistente AI, una parte del pubblico si sente fuorviata, anche quando il software funziona.

Per questi utenti la questione è legata alla fiducia: se il maintainer non chiarisce subito come ha lavorato, allora aumenta il dubbio sulla sua capacità di intervenire quando il codice si rompe, compare un bug difficile o emerge un problema di sicurezza.

I segnali che fanno pensare a un progetto serio

Liquidare Logitune come puro “AI slop” (onestamente, sembra essere un po’ la moda del momento…) solo guardando la superficie sarebbe una semplificazione. Il repository mostra alcuni elementi che, almeno in parte, vanno nella direzione opposta.

La documentazione elenca una guida all’architettura con 14 diagrammi, una sezione dedicata ai test, una guida all’aggiunta di dispositivi, una spiegazione del protocollo HID++ e indicazioni specifiche per KDE Plasma 6 e GNOME 42+ su Wayland. Il progetto aveva inoltre già 188 commit e 6 release pubblicate. Non sono prove definitive di qualità, ma non sono nemmeno i segnali tipici di una demo improvvisata e pubblicata in fretta e furia.

Lo stesso autore, rispondendo a chi chiedeva una versione Flatpak, ha spiegato che l’app richiede accesso a hidraw, uinput e D-Bus, tre elementi che il modello di sicurezza di Flatpak non espone con facilità. È un’osservazione coerente con i limiti reali della piattaforma e difficilmente arriva da chi non ha mai messo le mani sul problema.

Dove stanno i punti deboli veri

La critica più sensata non è “ha usato Claude, quindi il progetto vale zero“: proprio nei giorni scorsi abbiamo presentato il progetto Printervention che permette di ridare vita a vecchie stampanti e usarle tramite browser e WebUSB.

L’autore, confermando di essersi avvalso dell’aiuto di Claude per ridurre le tempistiche, rimuovere i bug e arrivare a un progetto certamente funzionante, osservava: “i moderni LLM sono semplicemente incredibili: se i computer sono biciclette per la mente, come diceva Steve Jobs, allora Claude Code è un jet privato“.

La domanda sensata è un’altra: nel caso di questi progetti, quanta parte della base di codice il maintainer conosce davvero, quanto velocemente saprà correggere regressioni e quanto il progetto reggerà quando dovrà uscire dal caso d’uso principale (parlando di Logitune il mouse MX Master 3S)? Lo sviluppatore stesso ha ammesso di aver testato davvero solo quel dispositivo e di non voler dichiarare supporti aggiuntivi senza verifiche concrete. È una posizione prudente, ma segnala anche il limite attuale: il software ha bisogno di allargare la matrice di test prima di diventare punto di riferimento stabile.

Ci sono poi aspetti collaterali che hanno alimentato la diffidenza. Il nome “Logitune” richiama troppo da vicino Logi Tune, software Logitech già esistente per altre categorie di prodotto; nel thread è stato fatto notare che ciò potrebbe creare confusione o attirare problemi di marchio. Tanto che l’autore ha detto che valuterà un cambio di denominazione.

Dal “vibe coding” alla disciplina ingegneristica: origine del termine e il ruolo di Andrej Karpathy

Il termine vibe coding fu usato da Andrej Karpathy nel febbraio 2025. Karpathy, ricercatore di primo piano nel campo dell’intelligenza artificiale, già direttore della divisione AI in Tesla e tra i membri iniziali di OpenAI, ha spesso sottolineato come strumenti basati su LLM possano cambiare il modo di programmare, rendendolo più iterativo, esplorativo e accessibile.

Secondo Karpathy, il vibe coding è un approccio con cui – quando si sviluppa qualcosa – “si dimentica persino che il codice esista“. L’obiettivo principale è concentrarsi sul risultato desiderato, sul “vibe” finale del prodotto, senza preoccuparsi del codice sottostante.

Karpathy non attribuisce affatto, quindi, una lettura negativa al termine vibe coding: dal suo punto di vista non è sinonimo di superficialità, ma rappresenta una fase utile del processo. Quella in cui si generano idee, si testano rapidamente soluzioni e si costruiscono prototipi. Il problema nasce quando l’approccio è esteso a contesti che richiedono precisione ingegneristica, affidabilità e controllo completo del sistema.

Il termine riflette un contrasto evidente nel mondo dello sviluppo software moderno: da un lato la velocità e la creatività abilitate dall’AI, dall’altro la necessità di mantenere rigore, comprensione e responsabilità tecnica.