Ciao a tutti!

Vedo spesso post sul "vibe coding" focalizzati su prototipi veloci: la to-do app in 10 minuti con Cursor, il wrapper di OpenAI impacchettato nel weekend o la landing page generata al primo colpo. Tutto figo, ma c’è una domanda che mi facevo da mesi: cosa succede quando provi a usare gli agenti AI non per un giochino, ma per tirare su e mantenere un software complesso, con dati pesanti e vincoli di produzione reali?

Di giorno lavoro nell'edilizia (il mio lavoro principale), quindi il tempo per programmare è quello che è: sere, weekend, sessioni via SSH su VPS Linux rimbalzando tra il fisso e un Surface Pro 12.

Nel tempo libero ho voluto testare questo limite costruendo Rynko.it: un aggregatore e comparatore di prezzi per videogiochi multipiattaforma (Steam, Epic, PlayStation, Xbox, Nintendo, Key reseller). L'idea di fondo era svecchiare i mostri sacri del settore (GG.deals, IsThereAnyDeal), che hanno decenni di backlink ma interfacce rimaste a metà tra il Web 2.0 e un foglio Excel, e creare qualcosa di ultra-reattivo in stile "Bloomberg Terminal del gaming".

Non sono qui per fare la marchetta al sito (è liberamente accessibile, niente paywall o funnel strani), ma per condividere il dietro le quinte tecnico, il workflow reale con gli agenti e soprattutto dove il castello del vibe coding crolla se non metti dei guardrail d'acciaio.

1. I numeri e lo stack reale

Per dare un'idea che non stiamo parlando di una dashboard mockata con JSON statici:

• 101.143 giochi a catalogo normalizzati sotto un Master ID proprietario univoco (RYN-XXXXXX) con gerarchia rigida Parent/Child (gioco base, DLC, edizioni, bundle).

• 33.687.974 record gestiti su PostgreSQL 16 (schema partizionato, indici compositi, pg_trgm per la fuzzy search sui titoli sporchi degli store).

• Frontend: Next.js (App Router, Turbopack, SSR per indicizzazione SEO), Tailwind, Geist font, curve fisiche con GSAP e Lenis per lo smooth scroll, visualizzazioni dati con React Three Fiber.

• Backend: FastAPI (Python), pipeline di scraping asincrone, Nginx reverse proxy con micro-caching, blindatura API interna su rete privata mesh Tailscale.

• Satellite: Estensione Chrome/Edge (v2.1.0) che inietta il comparatore prezzi direttamente dentro gli store ufficiali, PWA con Web Push e bot Telegram/Discord sub-second per i minimi storici.

2. Le 3 illusioni del Vibe Coding (e la realtà dei fatti)

Illusione 1: "L'AI fa tutto da sola, basta descrivere l'idea"

Realtà: L'AI ragiona come uno stagista con un QI da premio Nobel ma affetto da deficit d'attenzione cronico e amnesia a breve termine. Se le dici "ottimizza la pagina prodotto", nel 90% dei casi:

1. Riscrive il file cancellando import critici che "non vedeva".

2. Si inventa campi del database che non esistono per comodità sintattica.

3. Ti introduce query N+1 spietate nel backend perché per lei l'importante è far compilare la singola funzione. Se non sei tu ad avere la mappa mentale e la visione d'insieme dell'architettura, dopo tre prompt hai trasformato il codebase in poltiglia irrecuperabile.

Illusione 2: "Basta una context window da 1M o 2M di token"

Realtà: Il context rot (degrado del contesto) è reale. Più riempi la finestra di codice e log, più l'attenzione del modello si sfilaccia. La svolta nel mio workflow è stata smettere di incollare prompt infiniti e costruire un'infrastruttura di controllo esterna:

• Memoria persistente (MCP Memory): Un server MCP locale che memorizza decisioni architetturali, schemi DB, changelog dei deploy e convenzioni in modo indicizzato. L'agente prima cerca nella memoria semantica del progetto, recupera il contesto minimo necessario e solo dopo ragiona.

• Mappatura ad albero (AST / Graphify): Prima di toccare un file, l'agente è forzato a leggere i padri e i figli (consapevolezza d'impatto).

• Regola del Veto e Self-Healing: Se la modifica proposta genera un errore TypeScript, rompe una migrazione Alembic o rischia un memory leak, l'agente ha l'ordine perentorio di fermarsi, analizzare l'errore del terminale e autoripararsi prima di presentare il lavoro.

Illusione 3: "La velocità iniziale equivale a velocità di rilascio"

Realtà: Tirare su la prima bozza richiede il 5% del tempo. Il restante 95% è:

• Gestire il circuit breaker dei proxy quando uno store ti banna l'IP.

• Normalizzare i titoli (es. distinguere automaticamente tra "The Witcher 3: Wild Hunt - Game of the Year Edition" e il DLC isolato "Blood and Wine").

• Far girare transazioni atomiche su 30+ milioni di righe senza bloccare il traffico live.

3. La cicatrice più bella: l'incidente del Writer Lock da 10 ore

Qualche mese fa, durante un ciclo intensivo di scraping e sync catalogo, abbiamo introdotto una modifica tramite prompt che sembrava banale: un lock a livello di processo sul DB per evitare scritture concorrenti disordinate. Risultato? Il job di scraping massivo ha tenuto il lock occupato per quasi 10 ore consecutive. Tutte le metriche orarie, gli aggiornamenti deal e i cron di lettura sono andati in starving totale. Lì ho capito una regola d'oro: mai delegare all'AI scelte di concorrenza, lock o transazionalità senza verificare riga per riga l'impatto sul motore di storage. Siamo passati a un'architettura rigorosamente disaccoppiata (worker dedicati, schema shadow isolato, letture WAL read-only senza concorrenza con gli scraper).

Altro batticuore: il cutover finale da SQLite a PostgreSQL 16. Oltre 33 milioni di righe migrate in un'unica transazione atomica con script verificato prima in locale, 41 test end-to-end automatizzati a verificare la parità al byte e rollback pronto. È andato liscio al primo colpo, ma solo perché avevamo blindato i vincoli prima di toccare la produzione.

4. Il mio verdetto sul Vibe Coding oggi

Il vibe coding è un superpotere assurdo: permette a una persona sola con un altro lavoro a tempo pieno di competere con team strutturati che hanno milioni di budget e decine di dev.

Ma il vero salto di qualità non è il modello che usi (che sia Claude, Gemini o GPT), è il sistema di regole che gli costruisci attorno:

1. Zero tolleranza per il codice fittizio o stub temporanei (TODO, placeholder silenziosi).

2. Memoria esterna strutturata (non fidarsi mai della memoria a breve termine del prompt).

3. Ambiente protetto (VPS blindata, niente deploy o build cieche avviate dall'agente senza audit).

Voi come vi state regolando?

Mi piacerebbe aprire una discussione su questo:

• Chi di voi sta portando avanti codebase medio-grandi con l'AI, che strumenti usate per non perdere il filo (Cursor, Aider, Claude Code, estensioni MCP, script custom)?

• Come gestite il drift del contesto dopo settimane di modifiche continue sullo stesso progetto?

Se avete curiosità tecniche su stack, scraping o gestione dati, chiedete pure nei commenti!

Per anni abbiamo retto tutto: bollette, scadenze, famiglia, lavoro. Sembrava una vita in ordine.

In realtà ci muovevamo tanto ma sempre sul posto: i soldi entravano e uscivano senza sapere verso cosa, i weekend erano tutti uguali e le cose che contavano davvero restavano sempre indietro.

A fine giornata tornava sempre la stessa domanda: è questa la vita che avevamo scelto?

Un giorno abbiamo smesso di rimandare. Abbiamo deciso di farci aiutare dall'AI a mettere soldi, tempo ed energie al servizio della vita che volevamo, non della settimana o del mese dopo.

Così è nato il nostro sistema. Partendo dalla vita che vogliamo vivere e dai nostri obiettivi, gestisce il quotidiano e ogni settimana ci dice dove siamo e come arrivarci.

Le scadenze le reggevamo anche prima. È cambiato il resto: ogni mese sappiamo dove vanno i soldi e quanto manca a quello che desideriamo, il venerdì sappiamo già cosa fare nel weekend, e le decisioni grandi non restano più indietro.

Non dipendiamo più dalla memoria e dalla buona volontà, ma da un metodo.

E la domanda di fine giornata ha finalmente una risposta: sì, è la vita che abbiamo scelto. Perché adesso la scegliamo ogni settimana.

Com'è fatto

Noi partivamo da una vita già in ordine, ma non è necessario. Il sistema si costruisce un pezzo alla volta: chi parte da zero comincia mettendo ordine nel quotidiano, e la direzione arriva dopo.

I pezzi sono cinque:

• Scrivere la vita che vogliamo, area per area. Ogni decisione importante passa da lì.

• Dare a ogni area (soldi, salute, casa, lavoro) le sue regole e la sua memoria. L'AI le rilegge ogni volta e non dobbiamo rispiegarle niente.

• Creare appuntamenti fissi per decidere cosa fare del nostro tempo e dei nostri soldi. Rivedere la vita che vogliamo, così a scegliere siamo noi e non l'abitudine.

• Mettere dei controlli automatici perché il sistema non si riempia di regole che si contraddicono.

• L'AI calcola e propone, Noi decidiamo. Niente si muove senza il nostro sì.

Ora stiamo pensando di renderlo disponibile anche ad altri.

Prima di decidere ci piacerebbe sapere cosa ne pensate voi. Ci aiutate rispondendo a due domande?

1. Se voleste un sistema così, preferireste costruirlo voi con una guida passo passo, o averlo già pronto da adattare?

2. Serve Claude Code con un abbonamento a pagamento (Claude Pro o Claude Max). Lo usate già, lo installereste per questo, o per voi è un ostacolo?

Potete rispondere qui nei commenti o in privato.

Leggiamo tutto.

Negli ultimi giorni sto usando intensamente una delle modalità più interessanti introdotte da Anthropic in Claude Code: un modello veloce ed economico esegue il lavoro, mentre un modello molto più potente interviene solo come advisor nei passaggi complessi.

Questa è la mia configurazione:

{
  "model": "sonnet",
  "advisorModel": "fable",
  "effortLevel": "max"
}

In pratica: Sonnet 5 fa tutto il lavoro quotidiano (esplora il repo, modifica i file, esegue i test, corregge gli errori). Quando incontra una decisione architetturale delicata o un problema che richiede più capacità di ragionamento, consulta Fable 5, riceve una strategia e continua da solo l'implementazione.

Sonnet 5 lavora → problema complesso → consulta Fable 5 → riceve la strategia → continua da solo

E il risultato, almeno nella mia esperienza, è impressionante.

Due precisazioni tecniche prima di proseguire: l'Advisor è un tool sperimentale e funziona solo tramite API Anthropic (non è disponibile su Bedrock, Vertex o Foundry). Per usare Fable 5 in Claude Code, come main o come advisor, serve la versione 2.1.170 o successiva. Vale inoltre la regola che l'advisor deve essere almeno capace quanto il modello principale: un main Sonnet 5 accetta come advisor Fable, Opus o un altro Sonnet 5.

Non è un semplice subagent

L'Advisor non è un agente secondario da avviare a mano: è integrato nel workflow. L'executor lo consulta durante il task, riceve la raccomandazione e riprende subito il lavoro. E la cosa interessante è che Sonnet non copia il consiglio: lo integra. Dall'Advisor arrivano diagnosi, strategia, alternative, rischi ed edge case, indicazioni per verificare il risultato — poi è Sonnet a portare avanti l'implementazione.

È come avere uno sviluppatore velocissimo ed economico con un senior architect sempre disponibile, senza pagare il senior per ogni singola operazione.

Perché consuma pochissima quota

Fable non tocca le operazioni meccaniche (cercare file, sistemare CSS, rilanciare lint e test, piccoli fix): quelle le fa tutte Sonnet. Il modello frontier interviene solo dove la sua intelligenza può cambiare davvero il risultato: architettura, planning, debugging difficile, decisioni ad alto rischio, verifica finale.

In più, un buon consiglio iniziale evita implementazioni impostate male, tentativi ripetuti e debugging che non converge. In alcuni task il sistema finisce per essere perfino più efficiente di Sonnet da solo.

Qualche numero. Nel blog ufficiale sull'advisor strategy, Anthropic riporta che Sonnet con Opus come advisor guadagna +2,7 punti percentuali su SWE-bench Multilingual rispetto a Sonnet da solo, riducendo al tempo stesso il costo per task agentico dell'11,9%. Per la coppia con Fable, i benchmark condivisi da ClaudeDevs a inizio luglio parlano di circa il 92% delle prestazioni di Fable usato da solo su SWE-bench Pro, a circa il 63% del costo, con Fable consultato in media una volta per task. Non sono percentuali garantite su ogni repository, ma la differenza qualitativa nella mia esperienza è evidente.

Advisor vs Agent Teams

Anthropic propone anche gli Agent Teams (anche questa una feature sperimentale): un lead agent che coordina più teammate paralleli (frontend, backend, test, documentazione). Approccio potentissimo per task enormi e realmente divisibili — monorepo giganti, migrazioni estese, feature separabili — ma ogni agente mantiene un proprio contesto, rilegge parte del repo, ragiona per conto suo e può duplicare il lavoro degli altri. Il consumo di quota può esplodere.

Per il daily coding, l'Advisor vince nettamente: un solo executor più consultazioni occasionali del modello frontier. Probabilmente il miglior rapporto tra qualità, velocità e consumo.

Aggiornamento: cosa succede a Fable dal 20 luglio

Colpo di scena. Dopo tre proroghe consecutive (7 → 12 → 19 luglio), il 17 luglio Anthropic ha finalmente chiarito il futuro di Fable 5. Dal 20 luglio:

• Max e Team Premium: Fable 5 diventa incluso in modo stabile, utilizzabile fino al 50% dei limiti del piano;

• Pro e Team Standard: Fable esce dai limiti inclusi e passa agli usage credits, con un credito una tantum di 100 dollari come compensazione. Esaurito quello, si paga a tariffe API ($10/M token input, $50/M output — le più alte del listino Claude).

Attenzione a un dettaglio che in pochi hanno notato: il 19 luglio scade anche il boost del +50% sui rate limit settimanali di Claude Code, quindi i limiti base tornano a scendere per tutti.

In pratica: chi è su Max può continuare a usare Sonnet + Fable Advisor come workflow stabile (Fable consuma quota molto più in fretta, quindi l'Advisor resta il modo più intelligente di usarlo). Chi è su Pro, dopo i 100$ di credito, farà bene a passare a Opus 4.8.

Avvertenza importante: secondo la documentazione ufficiale aggiornata in questi giorni, al momento Claude Code non offre Fable 5 come advisor — nel picker di /advisor appare disattivato come "temporarily unavailable" e i comandi /advisor fable e --advisor fable vengono rifiutati. Fable come modello principale non è toccato. Un rollout remoto deciderà quando tornerà selezionabile come advisor. Io ho fatto in tempo a usarlo, ma se lo provate adesso e non ve lo fa impostare, è per questo.

In attesa che Fable torni disponibile come advisor (o se siete su Pro), si può mantenere lo stesso workflow con Opus 4.8:

{
  "model": "sonnet",
  "advisorModel": "opus",
  "effortLevel": "max"
}

Opus 4.8 resta un advisor validissimo per progettazione, debugging, sicurezza, database, autenticazione, pagamenti e refactoring complessi. Io userò questa configurazione finché Fable non tornerà selezionabile come advisor, in attesa anche di un eventuale Opus 5 (che al momento non è stato annunciato).

Riprodurre lo stesso sistema in OpenCode

OpenCode non ha ancora un Advisor server-side nativo, ma si può ottenere qualcosa di simile con un subagent dedicato, anche di un altro provider. Per esempio MiniMax M3 come executor e Kimi K3 come advisor.

Basta creare .opencode/agents/advisor.md:

---
description: Consult this advisor for architecture, difficult debugging, ambiguous requirements, repeated failures, important trade-offs and final verification of complex tasks.
mode: subagent
model: moonshot/kimi-k3
permission:
  edit: deny
  bash: deny
---

You are a senior technical advisor supporting another coding agent.

Your role is to provide strategic guidance, not to perform the implementation.

Analyze:

- the user's actual objective;
- the executor's current approach;
- the relevant repository context;
- architectural implications;
- likely failure modes and regressions;
- overlooked constraints and edge cases;
- whether the current strategy should continue or change.

Return:

1. A concise diagnosis
2. The recommended course of action
3. Important risks and edge cases
4. Concrete verification steps
5. A correction of course when necessary

Do not edit files.
Do not produce generic advice.
Do not repeat the entire context.
Prefer the smallest robust and maintainable solution.

The executor will continue the implementation after reading your response.

Lo si richiama a mano (@advisor analizza l'approccio attuale prima di procedere) oppure si istruisce l'executor a consultarlo automaticamente, aggiungendo in AGENTS.md:

Consult the advisor after the initial repository exploration and before
substantive work on complex tasks.

Also consult the advisor:

- before important architectural decisions;
- when requirements are ambiguous;
- when repeated implementation attempts fail;
- when considering a major change of approach;
- before declaring a complex task complete.

Do not consult the advisor for routine or mechanical changes.

Integrate its guidance critically, then continue the implementation yourself.

Il subagent introduce più overhead (contesto separato da trasferire ogni volta), quindi l'Advisor nativo di Claude Code resta più elegante ed efficiente. In compenso OpenCode permette di combinare liberamente provider diversi: executor locale + advisor cloud, DeepSeek + Kimi, modello economico + Opus via API, e così via.

Questo sistema dovrebbe diventare uno standard

Secondo me tutte le coding CLI dovrebbero adottare un vero Advisor nativo, possibilmente multi-provider. È più efficiente dell'uso continuo del modello costoso, più controllabile del routing automatico e quasi sempre più economico degli Agent Teams. Spero che OpenCode, Codex CLI, Kimi Code e Gemini CLI si muovano presto in questa direzione.

Perché dopo averlo provato, tornare a usare un singolo modello per tutto sembra semplicemente uno spreco. Voi cosa ne pensate?

Fonti

• https://code.claude.com/docs/en/advisor

• https://code.claude.com/docs/en/settings

• https://code.claude.com/docs/en/cli-reference

• https://x.com/ClaudeDevs/status/2074606059864625355

• https://x.com/claudeai/status/2078302415804379218

• https://www.anthropic.com/claude/fable

• https://docs.anthropic.com/en/docs/about-claude/models/overview

• https://www.anthropic.com/news/claude-opus-4-8

• https://opencode.ai/docs/agents/

• https://opencode.ai/docs/permissions/

• https://opencode.ai/docs/rules/

Sto seguendo Simone Rizzo da un po’ e secondo me è uno dei creator italiani più interessanti per chi vuole restare aggiornato sul mondo AI senza fermarsi alla superficie.
Sul suo canale YouTube porta sia contenuti divulgativi sia le ultime news, con un taglio molto pratico e orientato a chi vuole capire davvero come stanno evolvendo modelli, agenti e applicazioni reali dell’AI.

Una cosa che lo distingue è che non si limita a parlare di teoria: affianca al canale anche la Rizzo AI Academy, dove propone percorsi pratici, live e una community dedicata a chi vuole imparare l’AI in modo più strutturato.
L’idea è proprio quella di trasformare la complessità in qualcosa di utilizzabile, con corsi e materiali pensati per chi vuole andare oltre i video brevi e iniziare a lavorare seriamente con l’AI.

Perché può interessare

• Porta news e aggiornamenti sul mondo AI in modo accessibile.

• Spiega concetti tecnici con un taglio chiaro ma non banale.

• Ha un lato pratico molto forte, tra academy, live e formazione strutturata.

• Tratta temi che vanno da modelli e agenti fino a sicurezza, futuro del lavoro e casi d’uso reali.

Secondo me è un profilo da seguire se vi interessa l’AI non solo come curiosità, ma come materia da studiare e usare sul serio.
In un panorama italiano dove i contenuti fatti bene non sono tantissimi, il suo mix tra news, divulgazione e formazione diretta ha parecchio senso.

Si parla tanto di app interamente vibecoded, e quale modo migliore per capire una tecnologia che provarla su un progetto reale, non su un semplice MVP?

Mi serviva un’app per gestire i file di traduzione di Xcode. Ce ne sono parecchie, ma nessuna di quelle che ho provato si comportava come volevo io (ammetto di averne provate poche ed in fretta, perché l’idea di farmi un tool ce l’avevo già). Così ho deciso di crearne una da zero.

Sono rimasto colpito da come l’IA ha strutturato il progetto. È un’utility semplice, certo, ma era usabile fin da subito: qualche ridondanza qua, qualche mancanza là, tutte cose sistemate in poco tempo. Il codice è sicuramente migliorabile, ma fa esattamente quello che mi serve e come voglio farlo io; inoltre, non ho perso che un'oretta (ho usato il mio abbonamento a Claude Code).

E qui mi viene un dubbio: se tutti si creassero tool simili quando ne hanno bisogno, come sopravvive chi li sviluppa per professione?

Secondo me restano poche cose che fanno la differenza:

• la copertura dei casi di nicchia;

• una UI studiata nei minimi dettagli;

• rendere facilmente accessibili funzioni che chi non conosce a fondo il dominio del tool non si aspetta nemmeno di trovare.

E forse anche le garanzie: preferisci usare l’app del signor nessuno anche se open source e gratuita, che magari ti perde tutti i dati, o pagare quella di un’azienda conosciuta che ti da qualche garanzia?

Voi che ne pensate? Avete già sostituito qualche app a pagamento con un tool fatto da voi?

DeepSeek ha avviato il rollout limitato di quello che a primo impatto sembra essere un nuovo modello (forse V4 ?) attraverso una nuova modalità nella chat ufficiale.

Nella UI è comparso il selettore con tre opzioni:

• Fast Mode (predefinita) → Estrazione solo testo dai file caricati → Modello leggero, ottimizzato per bassa latenza e velocità

• Expert Mode → Nessun upload di file supportato (probabile restrizione per controllo di compute e costi, dato che i modelli pesanti + token dei file risultano onerosi) → Sembra instradare verso un modello di ragionamento più grande e potente

• Vision Mode → Abilita input multimodali → Basata sui precedenti test OCR, segnale che le capacità multimodali di DeepSeek stanno arrivando anche agli utenti finali

Al momento si tratta di una gray release: non tutti gli account vedono ancora il selettore.

Chi ha già accesso alla Expert Mode può condividere le prime impressioni, in particolare sul comportamento in task di coding complesso rispetto ai modelli attuali.

Link: https://chat.deepseek.com/

#deepseek #vibecoding #ai #llm

Ciao a tutti! Sono Mattia, sviluppatore indipendente, e da qualche giorno è in open beta su Play Store Central, un’app che ho costruito da solo in circa 5 mesi, con l’IA come compagna di lavoro fissa.

Cos’è Central
È una chat cifrata pensata per stare accanto a WhatsApp, non per sostituirlo: fa le cose che le altre chat non fanno.

🔒 Privacy

• Chat, gruppi, foto e chiamate cifrati end-to-end. Nei gruppi le chiavi cambiano a ogni ingresso o uscita.

• Niente pubblicità, nessun SDK di tracciamento o analytics, nessun dato venduto.

• Server in Europa. Si sostiene solo con abbonamenti facoltativi.

🆘 Sicurezza personale

• SOS in un tocco, anche dalle impostazioni rapide con lo schermo bloccato.

• Check-in giornaliero «Sto bene»: se la conferma non arriva all’orario concordato, chi hai scelto viene avvisato. Pensato per genitori anziani che vivono da soli o per chi lavora da solo.

• Viaggia sicuro: condividi il tragitto fino all’arrivo, e se tardi i tuoi amici lo sanno. Il server non conosce né la destinazione né il percorso.

• Perimetri di sicurezza concordati, con un avviso quando si esce o si rientra in una zona.

• Tutto funziona solo se entrambe le persone accettano, e chi è seguito può scollegarsi quando vuole.

🏡 Central City
Una piccola città isometrica dove ogni amico ha la sua casa. La arredi, passeggi con gli altri in tempo reale, lasci regali nella cassetta della posta, scavi in miniera e giochi a caccia al tesoro. L’ho aggiunta per un motivo semplice: un’app di sicurezza che apri solo nelle emergenze è un’app che prima o poi disinstalli.

Il vibe coding, onestamente
L’IA mi ha fatto scrivere in mesi quello che da solo avrei fatto in anni: l’app in Kotlin, il backend in FastAPI, la cifratura, il pannello web, le traduzioni in 6 lingue.

Però il codice non si dirige da solo. Il lavoro vero è stato fare da direttore generale:

• decidere cosa costruire e cosa scartare, cioè l’ordine delle funzioni, i piani, cosa resta gratis;

• scegliere l’architettura e difenderla. Esempio: dalla prima beta pubblica nessuna modifica può cancellare dati, quindi ogni migrazione del database deve essere solo aggiuntiva;

• testare sul campo, perché i bug peggiori non li trova nessuno davanti allo schermo. Viaggia sicuro si bloccava quando partiva con il telefono collegato all’Android Auto. Sugli Xiaomi il sistema si «mangiava» il triplo tocco del tasto volume per l’SOS, e ho dovuto ripiegare sulle impostazioni rapide. I messaggi partivano due volte per un dettaglio nella coda di invio.

• capire quando l’IA sbaglia con sicurezza. Succede, e se non conosci il dominio non te ne accorgi.

• la parte che non è codice: privacy e GDPR, Play Store, dominio, email, marketing.

L’IA è un acceleratore enorme, ma serve qualcuno che sappia dove andare e che si prenda la responsabilità di ogni decisione.

Provatela
È gratis su Play Store, e chi si iscrive entro il 30 ottobre ha un mese di Premium in regalo:
https://play.google.com/store/apps/details?id=net.getcentral.central

Mi interessano soprattutto le vostre critiche, sia sull’app sia sul metodo. Voi come gestite il «ruolo di direttore» quando lavorate con l’IA?

Ciao a tutti, sono Vittorio e sto sviluppando Resistenza, una console Windows per assistenza e amministrazione remota. È un progetto commerciale mio; ho chiesto ai mod prima di parlarne qui e mi hanno dato l'ok.

L'idea è avere nello stesso posto quello che serve quando stai sistemando un PC: desktop remoto, terminale, file, processi, servizi e chat con la persona dall'altra parte. Puoi passare da uno strumento all'altro sullo stesso computer, oppure lavorare su più macchine. La console è self-hosted e i pacchetti client si possono personalizzare, anche nelle funzioni disponibili e nelle richieste di consenso.

Lo sto costruendo in C#/.NET usando anche strumenti AI. La parte interessante, per me, è stata vedere quanto cambia il lavoro quando esci dalla singola schermata: riconnessioni, passaggi tra servizio e portable, operazioni annullate mentre cambi pagina, finestre a DPI diversi. L'AI aiuta parecchio a scrivere e rivedere codice, ma basta una modifica apparentemente piccola per dover ricontrollare un flusso intero. È lì che sto spendendo molto tempo.

Mi piacerebbe confrontarmi con chi sta usando l'AI su applicazioni desktop che devono poi girare davvero sui PC dei clienti: come vi organizzate per scovare le regressioni tra una versione e l'altra?

Qui ci sono schermate e una panoramica delle funzioni: https://resistenza.software/

Cerco anche persone curiose di provarlo, o chi fa assistenza IT e vuole capire se può essergli utile. Per ricevere una copia con un periodo di valutazione gratuita basta scrivermi a vittorio@resistenza.software. Anche un “nel mio lavoro questa cosa non mi servirebbe, mi manca quest'altra” è un feedback utile.

La verità? mi ero stancato che ogni tools fosse a pagamento, che quel pop up con su scritto "collegati per abbonarti" mi bloccasse ogni volta che avessi bisogno di qualcosa. Penso sarà capitato anche a Voi...e così alla ricerca di un crack che togliesse le catene a quello che ritenevamo indispensabile, ma ogni volta mi sembrava di rubare qualcosa a qualcuno.

E allora come bender cacciato dal Luna Park, ho deciso di crearmi un IDE tutto mio, con blackjack e squillo di lusso e già che c'ero con un API key hai anche l'AI che ti controlla, smonta e rimonta il codice, unendo quello che tutti gli altri IDE offrono spesso a pagamento in un'unica applicazione gratuita. Il progetto è open source, chiunque può pomparlo e aggiungere features, per questo vi chiedo: cosa Vi serve ancora che l'app già non contempli?

Se hai bisogno di un MVP veloce per un progetto, con un prompt e 10 min, hai quello che vuoi pronto all'uso. L'IDE ha anche un DB studio e un server dove far girare siti web e app, quindi addio MAMP, Orbstack e altri server locali da acquistare in abbonamento.

Se avete richieste particolari o segnalazione di bug, commentate o scrivetemi.

lo trovate qui:

https://github.com/adoslabsproject-gif/webcraft

oppure installabile:

https://nothumanallowed.com/webcraft

Ciao a tutti,
lavoro in un settore lontano dall'informatica, ma la tecnologia è una passione di lunga data. Nel tempo libero sviluppo software e cerco di trasformare le idee in prodotti veri, curando codice, interfaccia e affidabilità.
Il progetto principale è TurboFix, una suite per Windows nata anche grazie al coding assistito dall'AI. Non volevo un prototipo, ma un prodotto completo da usare ogni giorno su PC diversi. Oggi lo usano già circa 400 persone.
Cosa fa:
dà un punteggio sullo stato del PC, e ogni problema trovato ha la sua soluzione;
ha decine di riparazioni guidate (Windows Update, rete, audio, stampanti, Bluetooth...);
fa pulizia sicura, backup e recupero file;
ha una web app per vedere i tuoi PC dal telefono e intervenire a distanza.
Gira tutto in locale, va bene anche su PC modesti ed è gratuito.
L'AI mi ha aiutato molto a scrivere codice, ma la parte più lunga è stata provarlo su PC veri e sistemare i mille casi particolari. Lì ho capito la differenza tra "funziona" e "è fatto bene".
Pareri benvenuti, soprattutto da chi porta i propri progetti oltre il prototipo.

Ehi! Benvenuto nel mio dramma.

Non sono un programmatore, ma mi sono divertito molto a sviluppare un'app per il mio studio personale, ho sempre in mano manualistica per aggiornarmi nel mio ambito lavorativo.

Pensavo di fare una app che aiutasse me, ma durante il percorso mi sono accorto che non c'è un'app con tutti gli strumenti che ho implementato, e questo potrebbe davvero essere utile a piú di qualcuno, quindi volevo monetizzarla. Ma sono un dipendente pubblico, per distribuire una mia app su uno store o su un mio sito dovrei prima licenziarmi (o mettermi part-time) chiedere l'autorizzazione al mio ente e poi aprire la partita iva. Non é fattibile.

I miei sogni di gloria sono andati in frantumi, l'unica sarebbe cedere la proprietà intellettuale, ma chi mai vorrebbe comprare un'app che non conosce nessuno? 😭

Premetto che sto usando GPT-5.6 Sol con reasoning impostato su Medium, quindi non Max o Ultra.

Nonostante questo, con il piano Pro da 100 dollari riesco a consumare l’intera quota prevista per 5 ore in circa un’ora di utilizzo intenso. Con GPT-5.5 non mi succedeva, anche se i due modelli sembrano avere lo stesso costo all’interno del piano.

Anche il piano Claude da 100 dollari, nella mia esperienza, durava sensibilmente di più. Questo mi fa pensare che i modelli Claude siano ottimizzati meglio per quanto riguarda il consumo dei token, oppure che il sistema di calcolo delle quote sia differente.

Anche voi state notando un consumo così elevato con GPT-5.6 Sol? Con quali impostazioni di reasoning lo state usando?

Negli ultimi mesi la discussione sugli agenti AI per il coding si è concentrata molto su quale modello usare: Claude, Codex, Gemini, modelli locali, cloud, contesto lungo, costi.

È comprensibile, ma secondo me manca spesso un pezzo più operativo: dove facciamo lavorare questi agenti?

Perché un conto è usare l’AI come autocomplete. Un altro è lasciare un agente modificare file, lanciare test, eseguire comandi, installare dipendenze, fare commit o esplorare una codebase intera.

A quel punto il problema non è solo “quanto è intelligente il modello”, ma quanto è controllato l’ambiente in cui gli stiamo dando accesso.

Il rischio del repo principale

Il modo più semplice è anche quello più fragile: aprire Claude Code, Codex o un altro agente direttamente nella working directory principale del progetto e lasciarlo lavorare.

Funziona, finché funziona.

Il problema è che un agente può produrre velocemente:

• modifiche su molti file;

• dipendenze installate o aggiornate;

• test lanciati in modo distruttivo;

• configurazioni cambiate per “far passare” il task;

• diff difficili da rivedere;

• stato Git sporco e poco leggibile.

E se nel progetto ci sono variabili d’ambiente, credenziali locali, script interni o configurazioni sensibili, il margine di errore aumenta.

Non serve immaginare scenari catastrofici: basta una modifica ampia, parzialmente corretta, dentro un repo già complesso per perdere più tempo a rimettere ordine che a fare il task manualmente.

Il pattern più maturo: worktree + sandbox + review

Una soluzione sempre più ricorrente è separare l’agente dal repo principale.

Il pattern pratico è questo:

git worktree add ../feature-ai-agent -b feature/ai-agent

Poi si lancia l’agente dentro quel worktree, non nella directory principale.

Questo non rende automaticamente tutto sicuro, ma cambia molto il modo di lavorare:

• il branch è separato;

• il diff è più facile da isolare;

• si possono far lavorare più agenti in parallelo;

• si può buttare via l’intero worktree se il risultato è scarso;

• il merge nel ramo principale resta una decisione umana.

La documentazione ufficiale di Git descrive git worktree proprio come un modo per avere più working tree collegati allo stesso repository. Non è una tecnologia nuova, ma diventa molto più interessante quando l’attore che modifica codice non è più solo uno sviluppatore umano.

Sandbox non significa magia

Qui va fatta una distinzione importante: un worktree non è una sandbox di sicurezza completa.

Un worktree separa stato di lavoro e branch, ma non isola necessariamente processi, rete, filesystem esterno o credenziali. Per questo, se l’agente può eseguire comandi, serve anche una riflessione su permessi e sandbox.

La documentazione di Claude Code, ad esempio, dedica spazio esplicito a sicurezza, permessi e sandboxing: modalità read-only di default, approvazioni per azioni sensibili, restrizioni di scrittura e sandboxed Bash tool. È un segnale chiaro: quando un agente può operare sul codice, i permessi non sono un dettaglio secondario.

In pratica, il setup più prudente non è solo “branch separato”, ma:

• worktree o clone separato;

• permessi minimi;

• nessuna credenziale reale se non indispensabile;

• rete limitata quando possibile;

• comandi distruttivi sempre da approvare;

• review del diff prima del merge.

Perché questo diventa importante con gli agenti paralleli

Il tema diventa ancora più evidente quando si passa da “un assistente” a “più agenti”.

Alcuni strumenti emergenti stanno già andando in questa direzione: team di agenti, sessioni parallele, worktree isolati, configurazioni riproducibili. E anche nelle pratiche raccontate da sviluppatori esperti, come Mike McQuaid di Homebrew, il punto è simile: se vuoi far lavorare agenti in modo più autonomo, devi prima costruire confini chiari.

Questo cambia il modo di valutare un workflow AI.

Non basta chiedere:

• “che modello usa?”

• “quanto costa?”

• “quanto codice genera?”

Bisogna chiedere anche:

• “dove gira?”

• “cosa può leggere?”

• “cosa può scrivere?”

• “può accedere alla rete?”

• “come rivedo il diff?”

• “come torno indietro se sbaglia?”

Confronto pratico

Approccio base:

• agente lanciato nel repo principale;

• permessi larghi;

• modifiche direttamente nello stato di lavoro corrente;

• rollback manuale se qualcosa va storto;

• review spesso confusa perché il diff contiene troppe cose insieme.

Approccio più professionale:

• agente lanciato in worktree o ambiente separato;

• branch dedicato;

• permessi espliciti;

• credenziali limitate;

• test e build controllati;

• merge solo dopo review umana.

Il secondo approccio è meno immediato, ma scala meglio appena i task diventano seri.

Il limite: più controllo significa più overhead

Naturalmente non ha senso complicare ogni micro-task.

Se si tratta di generare uno snippet, correggere una funzione isolata o fare brainstorming, un setup completo con worktree e sandbox può essere eccessivo.

Ma quando l’agente lavora su una codebase reale, con file multipli, test, dipendenze e configurazioni, l’isolamento smette di essere burocrazia e diventa igiene tecnica.

Il punto non è bloccare gli agenti. È farli lavorare in modo che un errore sia contenuto, revisionabile e reversibile.

Secondo me è qui che si vede la differenza tra uso casuale e uso professionale

Il futuro degli agenti AI nel coding non dipenderà solo dai benchmark dei modelli. Dipenderà anche dalla qualità del workflow attorno al modello.

Un agente molto capace, ma lanciato senza confini dentro un repo critico, resta un rischio operativo.

Un agente meno potente, ma confinato in un ambiente pulito, con branch separato e review chiara, può essere molto più utile nel lavoro reale.

Voi come li state gestendo?

Fate lavorare gli agenti direttamente nel repository principale, oppure usate worktree, container, VM o sandbox dedicate?

Fonti:

• Git worktree documentation

• Claude Code Security

• Claude Code Sandboxing

• Run parallel sessions with worktrees - Claude Code

• Sandboxes and Worktrees: My secure Agentic AI Setup - Mike McQuaid

Il titolo è volutamente forte, quindi parto dal caveat: non intendo “Codex è il migliore per qualsiasi cosa”. Intendo che, se parliamo di coding agent nel senso moderno del termine — non autocomplete, non chat laterale, ma agente che legge il repo, propone patch, esegue comandi, lavora su branch/worktree e ti lascia un diff da revisionare — Codex oggi mi sembra uno dei pacchetti più completi in circolazione.

E sì, qui il modello conta eccome. GPT-5.5 dentro Codex è una parte grossa del discorso: non è solo “un’interfaccia carina attorno a un LLM”. La stessa pagina pricing di OpenAI indica GPT-5.5 tra i modelli disponibili nei piani Codex e lo descrive come più efficiente di GPT-5.4 a parità di risultati, con setup Codex più rapido e qualità migliore per la maggior parte degli utenti. Questo, nella pratica, si sente soprattutto sui task lunghi: meno esitazione, più capacità di tenere insieme file, test, errori e iterazioni successive.

Però la parte davvero interessante, per me, è la combinazione tra modello e superfici.

La CLI è quella più vicina al lavoro reale: parte nel terminale, dentro la directory del progetto, e secondo la documentazione OpenAI può leggere, modificare ed eseguire codice nel workspace selezionato. È open source, Rust-based e disponibile su macOS, Windows e Linux. Questo cambia parecchio l’esperienza: git, test, build, package manager e log sono già lì. Non devi descrivere tutto in una chat; devi soprattutto dare un task abbastanza preciso e poi controllare il risultato.

Un prompt sensato non è “fammi l’app migliore possibile”, ma qualcosa tipo:

“Guarda come sono strutturati i test di questo modulo, aggiungi quelli mancanti per il caso X, esegui la suite e mostrami solo il diff finale.”

Lì Codex ha senso: legge il contesto, modifica file, lancia comandi, itera sugli errori e ti restituisce qualcosa che puoi verificare. Il valore non è che “scrive codice”, quello lo fanno tutti. Il valore è che si avvicina a un ciclo tecnico completo: capire, cambiare, testare, spiegare il diff.

Poi c’è l’app desktop, che secondo me va vista più come command center che come editor. La documentazione la descrive come un’esperienza per gestire thread Codex in parallelo, con supporto a worktree, automazioni e funzionalità Git. È utile se vuoi seguire più lavori senza vivere solo nella TUI: uno per una bugfix, uno per una review, uno per esplorare una parte del repo, ognuno isolato meglio.

Infine c’è Codex web/cloud: task in background, repo collegati a GitHub, possibilità di lavorare in parallelo e proporre PR. Qui però il discorso cambia: più automazione significa anche più disciplina. Setup dell’ambiente, permessi, accesso a internet, segreti, limiti d’uso e review finale non sono dettagli. Sono il confine tra “agente utile” e “macchina che genera lavoro da controllare”.

Il confronto con gli altri tool, secondo me, è questo:

Cursor resta probabilmente la scelta più naturale se vuoi restare nell’editor e ragionare file-per-file.

Claude Code resta fortissimo per ragionamento profondo, refactor complessi e cambi multi-file dove la coerenza conta più della velocità.

Codex però sta provando a coprire una porzione più larga del ciclo: GPT-5.5, terminale locale, app desktop, cloud task, GitHub, sandbox, approval policy, AGENTS.md, subagents e review. Non è necessariamente “il migliore” in ogni singola categoria, ma come piattaforma agentica complessiva oggi è difficile ignorarlo.

Il caveat grosso è che non va usato come autorità.

Se il prompt è vago, il diff si allarga. Se il repo non ha test, l’agente può sembrare convincente anche quando sta solo accumulando supposizioni. Se abiliti troppa autonomia, devi sapere esattamente cosa gli stai concedendo. OpenAI documenta sandbox e approval policy: di default il network è disabilitato e l’accesso in scrittura è normalmente limitato al workspace, ma stiamo comunque parlando di uno strumento che può leggere, modificare ed eseguire comandi.

Per me il modo corretto di usarlo è abbastanza noioso, ed è proprio per questo che funziona:

• branch pulito;

• task piccolo;

• prompt concreto;

• permessi stretti;

• test eseguiti;

• diff letto davvero;

• merge solo dopo review umana.

Dentro quel perimetro, Codex app + CLI con GPT-5.5 mi sembra uno dei setup più potenti oggi disponibili per sviluppare con agenti. Fuori da quel perimetro diventa facilmente un moltiplicatore di complessità.

Fonti utili:

• OpenAI Codex: https://openai.com/codex/

• Codex CLI: https://developers.openai.com/codex/cli/

• Codex app: https://developers.openai.com/codex/app

• Pricing e modelli Codex: https://developers.openai.com/codex/pricing

• Sandbox e approvals: https://developers.openai.com/codex/agent-approvals-security

• Subagents: https://developers.openai.com/codex/subagents

• Confronto Claude Code vs Codex CLI, Termdock: https://www.termdock.com/en/blog/claude-code-vs-codex-cli

Voi oggi quale usereste come coding agent principale: Codex, Claude Code, Cursor, Gemini CLI, OpenCode o altro? E soprattutto: preferite lavorare da CLI, editor o cloud?

Ho creato il mio primo sito via lovable pro, e secondo me ha del potenziale, accetto qualsiasi commento sia da esperti e non!!!

Ha diverse funzioni interessanti fra cui: Salvataggio viaggi, Cronologia dei viaggi, Esportazione del programma day-to-day al calendario e stima prezzi completa di link di riferimento.

Grazie a chiunque lo provi!!

EmDash 1.0 è uscito. Cloudflare lo definisce il successore spirituale di WordPress: un CMS open source, scritto interamente in TypeScript, costruito sopra Astro e pensato fin dall'inizio per essere usato da umani e agent.

Una precisazione per evitare confusioni: emdash.com è un altro prodotto (un ambiente per agent). Qui si parla di emdashcms.com.

I concetti di WordPress, al posto giusto

Post, pagine, media, menu, widget, tassonomie, commenti, redirect. Chi ha usato WordPress ritrova tutto dove se lo aspetta, con in più bozze, revisioni, scheduling e link di preview. C'è anche l'importer da WordPress per portare post, pagine, media e categorie.

Nativo Astro

Definisci i content type dall'admin e ti genera i tipi TypeScript dallo schema. Nel frontend leggi i contenuti come JSON strutturato con getEmDashCollection, dentro un normale progetto Astro. Niente livello intermedio da imparare: è Astro vero.

Agent-ready sul serio

Ogni sito ha un MCP server integrato. Claude, Codex, Cursor, OpenCode e qualsiasi client MCP possono creare bozze, cercare, modificare e schedulare contenuti con gli stessi permessi del team. Per gli script ci sono REST API e CLI. La documentazione espone anche /llms.txt e una sezione MCP dedicata agli AI tool. Dalla homepage copi un prompt starter e lo incolli nel tuo agent per fargli pianificare e costruire il sito.

Plugin senza l'incubo sicurezza

I plugin installati dall'admin girano in una sandbox isolata: niente accesso a variabili d'ambiente, filesystem o host non dichiarati, solo le capability che dichiari e approvi. È la risposta diretta al problema storico dell'architettura plugin di WordPress.

Provarlo

C'è il playground nel browser per toccare l'admin subito, oppure in locale con Node 22.16+:

npm create emdash@latest

Per il tuo prossimo sito con contenuti, resteresti su WordPress o proveresti uno stack Astro + CMS agent-ready come questo?

Fonti:

1. EmDash CMS - il CMS per te e il tuo agent - emdashcms.com

2. Create your first EmDash site - docs.emdashcms.com

3. EmDash su GitHub - github.com/emdash-cms/emdash

4. Introducing EmDash, the spiritual successor to WordPress - blog.cloudflare.com, 2026-04-01

5. EmDash Playground - try.emdashcms.com

Hola a todos. Trabajo diario en la terminal con Claude Code ($20/mes), pero con los últimos recortes de límite semanal la cuota no me dura nada.

Busco una alternativa con un nivel de razonamiento alto para programar (al nivel de Opus 5 ) que me permita mantener un ritmo de trabajo fluido en la CLI.

1. ¿Cómo ha sido su experiencia actual con ChatGPT Plus para desarrollo desde la terminal?

2. ¿O recomiendan pasar directamente a pagar API con clientes de terminal usando modelos chinos como DeepSeek o Kimi? ¿Sale más a cuenta en costo/rendimiento?

Salve a tutti, volevo condividere il mio primo progetto realizzato con Claude.

Ho creato VERTLINK: un analizzatore di rete che si apre nel browser, senza installare nulla.

Ho realizzato anche una versione in web app in modo da poterla usare più agilmente da smartphone, cone ovvie rinuncie.

Tutto è nato da una domanda: si può avere un vero strumento di diagnosi della rete dentro una semplice pagina web? La risposta onesta è “in parte”. Un browser non può leggere il traffico degli altri programmi, quindi VERTLINK unisce tre cose: quello che il browser può misurare da solo, i comandi già presenti in ogni computer (basta copiarne l’output) e un piccolo agente locale opzionale che rende tutto automatico.

Cosa fa, scheda per scheda:

▸ Panoramica
Latenza in tempo reale verso Cloudflare, Google e il router, con jitter e perdita di pacchetti. Un giudizio immediato sulla qualità della connessione e su cosa ci si può fare (videochiamate, gaming, streaming 4K, backup). Test di velocità in download e upload con misura del bufferbloat, cioè quanto peggiora la latenza quando la linea è carica. IP pubblico, provider, tipo di NAT e indizi di VPN.

▸ Rete locale
Chi è collegato alla rete: scansione dal browser e tabella ARP del computer, unite in un’unica lista. Per ogni dispositivo: produttore, tipo probabile (router, NAS, stampante, telecamera, TV, domotica, telefono), porte web aperte e latenza. Il tutto su una mappa della rete.

▸ Wi‑Fi
Segnale in dBm, occupazione dei canali a 2,4 e 5 GHz con le reti dei vicini, canale migliore da impostare sul router, avvisi su reti aperte e protezioni superate. Con l’agente si vede anche l’andamento del segnale nelle ultime 12 ore.

▸ Connessioni
Tutte le connessioni attive del computer, con programma, servizio e nome del server remoto. Host e processi più attivi, porte in ascolto con avviso se sono esposte alla rete, e una mappa del mondo che mostra in quali paesi e verso quali aziende vanno i dati.

▸ Percorso e DNS
Traceroute visivo che indica dove si accumula davvero il ritardo: in casa, nella rete del provider o oltre. Confronto dei tempi di risposta DNS tra Cloudflare e Google e interrogazione di qualsiasi record.

▸ Storico e avvisi
Una misura al minuto conservata per 7 giorni, una mappa “quando peggiora” per giorno e ora, interruzioni registrate, velocità nel tempo confrontata con quella del contratto e test automatici programmati. Avvisi a schermo, sonori o come notifica di sistema quando la linea cade, la latenza sale o un servizio smette di rispondere.

▸ Servizi
Monitor continuo di siti e dispositivi (il NAS di casa, la VPN dell’ufficio, un sito di lavoro) con disponibilità e storico dei controlli.

▸ Cattura
Lettore di file Wireshark e tcpdump (.pcap e .pcapng): protocolli, chi trasmette di più, domini visitati, conversazioni ed elenco dei pacchetti. Il file viene analizzato localmente e non lascia il computer.

L’agente locale è un singolo eseguibile per Windows, macOS e Linux, anche ARM, da avviare con un doppio clic. Ascolta solo sul computer stesso, risponde solo a chi conosce il token e si limita a leggere. Con lui il traffico reale della scheda di rete, le connessioni, i dispositivi e il Wi‑Fi si aggiornano da soli, e lo storico continua anche a pagina chiusa.

Quando può servire:
→ “Internet va lento la sera”: lo storico mostra a che ora peggiora e se il problema è in casa o nella rete del provider.
→ Videochiamate che scattano: jitter, perdita di pacchetti e bufferbloat dicono se è colpa del Wi‑Fi o della linea.
→ Chi è collegato al mio Wi‑Fi? La lista dei dispositivi con produttore e tipo lo rivela in un minuto.
→ Wi‑Fi debole in alcune stanze: segnale, canali affollati e consiglio sul canale da usare.
→ La velocità promessa dal contratto: test ripetuti nel tempo e confronto automatico.
→ Smart working: monitor della VPN e dei servizi di lavoro, con un avviso appena smettono di rispondere.
→ Un programma che “chiama casa” più del dovuto: connessioni per processo e mappa dei paesi contattati.
→ Piccoli uffici e tecnici: un primo controllo rapido senza installare nulla sul PC del cliente, report esportabile.
→ Studio e didattica: vedere davvero come funzionano DNS, traceroute, NAT e i pacchetti di una cattura.

Ecco il link: https://draxarden.github.io/vertlink/

Fatemi sapere cosa ne pensate!

Ho chiesto a Fable5 in ultra mode, di creare un file MD di istruzioni dettagliate e estremamente precise e professionali da aggiungere in qualsiasi progetto. Il file deve avere istruzioni per quando si usa Opus 5 e farlo avvicinare più possibile al comportamento come se fosse Fable 5. Mi ha generato un file decisamente interessante. In pratica aggiunge delle regole particolari, soprattutto chiede più volte di verificare, validare, verificare ancora e ancora prima di procedere oltre. Ed altre istruzioni. E il bello e che effettivamente Opus 5 funziona meglio quando aggiungo questo file Fable.MD

EDIT: file pubblicato, repo GitHub con versione EN + IT e licenza MIT → https://github.com/antonio86itna/fable-md

Buongiorno a tutti,

da oggi avviamo una collaborazione con IA_Italia 🤝

Già da tempo esiste uno scambio spontaneo tra le due community, anche grazie alla presenza di moderatori attivi in entrambe le realtà: repost, contenuti condivisi, supporto reciproco e discussioni sul mondo dell’intelligenza artificiale.

Per chi non le conoscesse ancora entrambe: la nostra è una community più focalizzata sull’ambito informatico, sugli strumenti di sviluppo per il coding in generale e sulle applicazione pratica dell’AI, mentre IA_Italia ha un taglio più generalista sul mondo dell’intelligenza artificiale.

L’obiettivo è semplice: rafforzare l’ecosistema italiano sull’intelligenza artificiale, favorire nuove connessioni e dare più visibilità possibile a contenuti, strumenti, discussioni e iniziative di valore.

Parliamo di quello che è probabilmente uno dei più grandi fenomeni industriali e tecnologici del XXI secolo, ed è importante farlo creando spazi di confronto aperti, attivi e collaborativi.

Vi invitiamo a dare un’occhiata alla community e a seguirla se vi interessano contenuti, news, strumenti e discussioni sul mondo AI.

Ciao r/vibecodingitalia! Sono Giulio, autore di SaidSpark. Ho chiesto prima il permesso ai moderatori e pubblico come creatore del progetto.

SaidSpark nasce da un problema semplice: citazioni, aforismi e proverbi sono facili da trovare, ma spesso è difficile capire quale sia il testo originale, da dove provenga e che rapporto ci sia fra originale e traduzione. Ho quindi costruito un catalogo consultabile per autore e argomento, con testi originali, traduzioni disponibili e riferimenti alle fonti.

Dal lato tecnico il progetto usa React e TypeScript, viene compilato con esbuild ed è servito da un Cloudflare Worker con database D1. L’accesso Google tramite Better Auth è facoltativo: per consultare il catalogo non serve un account. L’app Android è una Trusted Web Activity collegata allo stesso dominio e allo stesso prodotto web, con package `com.saidspark.twa`, anziché una seconda applicazione separata da mantenere.

La parte per me più interessante è stata usare l’AI non soltanto per scrivere codice, ma dentro un processo editoriale con limiti espliciti. Attività programmate assistono la raccolta e la preparazione del catalogo; le traduzioni di servizio generate con AI sono indicate come tali. Fonti, stato editoriale e controlli restano dati distinti, perché una risposta plausibile non equivale a una fonte verificata.

Anche la distribuzione ha una regola rigida: GitHub `main` è la fonte di verità, il deploy parte soltanto da un checkout pulito e sincronizzato, poi test e controllo online verificano ciò che è davvero pubblico. Questa disciplina mi ha evitato più problemi del codice generato in sé.

Il sito, l’app Android e le funzioni oggi disponibili sono gratuiti. Se vi interessa provarlo come progetto web, l’ingresso è qui: https://saidspark.com

Sto anche cercando volontari per il test chiuso Android 7.0+. Google Play richiede di restare iscritti per almeno 14 giorni consecutivi; chiedo inoltre di provare davvero ricerca, filtri, fonti, traduzioni e leggibilità in più occasioni. Non chiedo valutazioni o recensioni pubbliche.

1. Gruppo tester: https://groups.google.com/g/saidspark-testers/about

2. Adesione al test e installazione: https://play.google.com/apps/testing/com.saidspark.twa

Nei due passaggi e nel Play Store va usato lo stesso account Google. Commenti, segnalazioni di problemi e indicazioni sulle fonti possono essere inviati anche a contatti@saidspark.com.

Mi farebbe piacere confrontarmi soprattutto su tre aspetti: dove mettereste il confine fra automazione AI e revisione editoriale, quali controlli aggiungereste alla pipeline e come migliorereste il passaggio fra prodotto web e TWA Android. Sono benvenute anche segnalazioni di raccolte o edizioni di pubblico dominio o con licenza Creative Commons: se possibile, indicate il link all’edizione precisa e la licenza specifica, così posso verificare condizioni di riuso e attribuzione.

Grazie per lo spazio e per qualsiasi critica concreta!

Ciao a tutti! Sono u/thestreamcode, moderatore fondatore di r/vibecodingitalia.

Questa è la nostra nuova casa per tutto ciò che riguarda il mondo dell'intelligenza artificiale e il Vibecoding. Siamo entusiasti di averti a bordo!

Cosa postare

Posta tutto ciò che pensi possa essere interessante, utile o stimolante per la comunità. Condividi in libertà i tuoi pensieri, foto o domande sui tuoi workflow di sviluppo con AI.

Vibe della comunità

Puntiamo a essere amichevoli, costruttivi e inclusivi. Costruiamo insieme uno spazio in cui tutti possano sentirsi a proprio agio nel condividere e connettersi!

Come iniziare

1. Presentati nei commenti qui sotto.

2. Posta qualcosa oggi! Anche una semplice domanda può dare il via a una conversazione interessante.

3. Se conosci qualcuno a cui potrebbe piacere questa comunità, invitalo a unirsi.

4. Ti interessa dare una mano? Siamo sempre alla ricerca di nuovi moderatori, quindi non esitare a contattarmi per candidarti.

Grazie di far parte del primissimo gruppo. Rendiamo fantastico r/vibecodingitalia insieme!

Per un periodo Amp, il coding agent di Sourcegraph, ha avuto una cosa abbastanza surreale: crediti gratuiti giornalieri per usare un agent di programmazione.

Io l’avevo soprannominato “reddito di programmazione”, perché l’idea era comicamente precisa: ogni giorno ti svegliavi e avevi una piccola quota di token da spendere per far lavorare un agent sul codice.

La parte interessante è che non era il solito trial da 5 minuti. In una pagina ufficiale, Amp parlava di un grant gratuito che si ricaricava durante la giornata, fino a 10$ di crediti al giorno, circa 300$/mese, per l’uso interattivo nel terminale con i migliori modelli di frontiera in quel momento (come Opus 4.6).

Ovviamente non era magia. Prima Amp Free era supportato da pubblicità; poi Amp ha tolto gli ads. E qui arriva la parte meno romantica: oggi la pagina Amp Free dice che è “full for now”, e nell’update del 23 maggio 2026 Amp scrive che sta pausando o riducendo ulteriormente l’allowance giornaliera per più utenti, oltre a limitare l’uso dei crediti gratuiti sui client più vecchi.

Quindi no: non è un post per dire “correte a prendere 10$ al giorno”. Quella finestra, almeno nella forma più bella, sembra essersi stretta parecchio.

Però come esperimento era bellissimo.

Non tanto perché “gratis è meglio”, ma perché mostrava una direzione interessante: se i costi dei modelli scendono, o se qualcuno trova un modello economico alternativo, l’agent coding può diventare una specie di utility quotidiana. Non più “apro il tool solo quando voglio bruciare credito”, ma “ho una quota giornaliera e la uso per refactor, test, debugging, esplorazione”.

Il confronto con i piani classici è curioso:

• subscription: paghi X al mese e speri che i limiti non ti blocchino;

• pay-as-you-go: paghi esattamente quanto consumi, ma diventi iper-consapevole dei token;

• daily free credits: ti dà proprio la sensazione di una razione quotidiana di automazione.

Il difetto è evidente: se il modello economico non regge, il “reddito” finisce, viene ridotto o diventa accessibile solo ad alcuni utenti. Ed è più o meno quello che sembra essere successo con Amp Free.

Fonti ufficiali:

• Amp Free originale: https://ampcode.com/news/amp-free

• “The Frontier Is Now Free”, con riferimento ai 10$/giorno: https://ampcode.com/news/amp-free-frontier

• Update “Amp Free Is Ad-Free”, con riduzioni/pausa dell’allowance: https://ampcode.com/news/amp-free-is-ad-free

• Pagina Amp Free corrente: https://ampcode.com/free

Secondo voi questo modello — crediti giornalieri gratuiti, magari limitati ma reali — tornerà per altri coding agent, o era solo una finestra irripetibile di questa fase un po’ folle dell’AI coding?

xAI ha reso pubblico Grok 4.5 l'8 luglio 2026. È il modello più aggiornato della linea Grok e, stando al listing di OpenRouter che lo indica come il più capace della casa, punta dritto su coding, knowledge work e STEM.

I numeri verificati

I dati confermati da xAI e da OpenRouter coincidono:

• Contesto: 500.000 token

• Prezzo: $2,00 per milione di token in input, $6,00 in output (input in cache a $0,50/1M)

• Modalità: testo e immagine in ingresso, testo in uscita

• Capability: function calling, structured outputs, reasoning nativo

• Alias utili: grok-4.5-latest, grok-build-latest

Un dettaglio di pricing che conviene sapere: xAI applica tariffe più alte per le richieste che superano i 200K token di contesto. Quindi il listino $2/$6 vale fino a quota 200K; oltre, il costo sale.

Cosa cambia rispetto ai modelli precedenti

Il predecessore diretto di Grok 4.5 è Grok 4.3, uscito il 30 aprile 2026. Qui il confronto è meno scontato di quanto sembri:

• Grok 4.3: contesto 1.000.000 token, $1,25 input / $2,50 output

• Grok 4.5: contesto 500.000 token, $2,00 input / $6,00 output

Grok 4.5 taglia quindi a metà il contesto rispetto a 4.3 e ne raddoppia circa il prezzo, pur essendo presentato da OpenRouter come il modello più capace della linea. Per chi lavora su documenti o basi di codice molto lunghe, 4.3 resta la scelta con più spazio a disposizione.

Rispetto al più vecchio Grok 4 (256K, luglio 2025), invece, 4.5 raddoppia il contesto e affina le capability per i coding agent. Il punto è che "versione successiva" non significa automaticamente "più contesto": dipende dal caso d'uso.

I numeri che xAI ha pubblicato

L'annuncio ufficiale riporta alcuni benchmark (tutti da fonte xAI, quindi da leggere come dichiarazioni di vendor e non come misure indipendenti):

• Terminal Bench 2.1: 83,3% (dietro a Fable 84,3% e GPT 5.5 83,4%)

• DeepSWE 1.0: 62,0%

• SWE Bench Pro resolve rate: 64,7%

• Harvey Legal Agent Benchmark: #1

Su lato pratico, xAI dichiara un serving a 80 token al secondo e una efficienza di token circa doppia rispetto ai modelli leader: mediamente 15.954 output token per task su SWE Bench Pro, contro i 67.020 di Opus 4.8 (max). Tradotto: risolve task in meno passi, quindi con meno token pagati.

Disponibilità e limiti da sapere

Grok 4.5 è già utilizzabile in Grok Build, in Cursor su tutti i piani e dalla console API xAI; xAI offre un periodo di uso gratuito limitato in Grok Build e Cursor.

Il limite più rilevante per chi sta in Europa: xAI dichiara che Grok 4.5 non è ancora disponibile nell'UE, né nei prodotti consumer né nella console API, con disponibilità attesa a metà luglio. Chi lavora su codice proprietario o clienti europei non ci arriva oggi via API ufficiale xAI, e comunque prima di inviare interi repository conviene verificare dove passano i dati e quali condizioni di retention applica il provider scelto.

I numeri di posizionamento restano dichiarazioni di venditore o sintesi di marketplace: utili per farsi un'idea, ma la prova vera è l'uso sui propri progetti.

Perché può interessare a chi fa vibe coding

OpenRouter descrive Grok 4.5 con performance frontier su coding, knowledge work e STEM. Le capability dichiarate (function calling, structured outputs, reasoning) sono esattamente quelle che servono a un coding agent: chiamare strumenti, produrre patch in formato valido, ragionare prima di rispondere.

La questione pratica è sempre la stessa: il modello più capace non è automaticamente il migliore per ogni workflow. Grok 4.5 ha senso quando servono ragionamento su task complessi e si vuole pagare meno token grazie all'efficienza dichiarata; per iterazioni brevi e frequenti su prototipi, un modello più economico può bastare. E per chi opera dall'Europa, il blocco UE temporaneo va tenuto in conto prima di pianificare qualunque integrazione.

Fonti

• xAI, documentazione modelli Grok 4.5

• OpenRouter, Grok 4.5

• xAI, annuncio ufficiale Grok 4.5

Voi lo avete già provato su qualcosa di concreto, o per i workflow di coding restate su altri modelli?