Arindam200

Awesome AI Apps: 138 runnable AI agent projects, from your first agent to production multi-agent workflows (16.6k stars) it's a collection of 138+ ai apps you can clone and run, each with its own readme and run command. MIT licensed. the starters are probably the most useful bit: a minimal agent in 22 frameworks (langgraph, crewai, openai agents sdk, google adk, agno, mastra, pydanticai, llamaindex, smolagents, dspy, autogen and more). they're kept small, so you can read two next to each other and see how each one handles tools and state before you commit to one. the rest covers simple agents (finance, calendar, browser automation, sql), voice (livekit, pipecat, deepgram), mcp, memory, rag (reranking, graphrag, ocr, citation checking), multi-agent workflows and some fine-tuning. Arindam200/awesome-ai-apps

I’ve built 25+ AI agents and practical RAG tutorials, all 100% free and open source. How to get started: 1. Follow me → @Arindam_1729 for weekly updates on LLMs, MCP, and AI workflows 2. Star the repo → Arindam200/awesome-ai-apps New agents and RAG examples added every week!

I’ve built 25+ AI agents and practical RAG tutorials, all 100% free and open source. How to get started: 1. Follow me → @Arindam_1729 for weekly updates on LLMs, MCP, and AI workflows 2. Star the repo → Arindam200/awesome-ai-apps New agents and RAG examples added every week!

I’ve built 25+ AI agents and practical RAG tutorials, all 100% free and open source. How to get started: 1. Follow me → @Arindam_1729 for weekly updates on LLMs, MCP, and AI workflows 2. Star the repo → Arindam200/awesome-ai-apps New agents and RAG examples added every week!

16k+ stars so far, MIT licensed, so fork whatever helps. Honest note: these are starting points. Add your own evals before production 🔥 Arindam200/awesome-ai-apps

I’ve built 25+ AI agents and practical RAG tutorials, all 100% free and open source. How to get started: 1. Follow me → @Arindam_1729 for weekly updates on LLMs, MCP, and AI workflows 2. Star the repo → Arindam200/awesome-ai-apps New agents and RAG examples added every week!

Aprire una PR da fork verso il maintainer e i problemi che non mi aspettavo Ho un fork Python di un server MCP per Dev.to (devto-mcp, partito dal progetto pubblico Arindam200/devto-mcp) che uso ogni giorno con Claude Code. Ci ho trovato dentro un paio di bug reali (uno rendeva impossibile aggiornare un articolo, mancava l'header di autenticazione sulla richiesta; l'altro faceva restituire 404 quando si cercava di leggere una propria bozza) e li ho risolti per me. A quel punto mi sono fatto la domanda che probabilmente si fa chiunque tocchi un fork per la prima volta: ha senso proporre queste fix al progetto originale? Non l'avevo mai fatto. Ecco cosa ho imparato facendolo. Guardare il terreno prima di scrivere Prima ancora di pensare a come strutturare la PR, ho controllato lo stato del repository originale: l'ultimo push risale a maggio 2025, e le uniche due Pull Request aperte (maggio e luglio 2025) sono entrambe un badge promozionale scollegato dal codice, non una revisione reale. Anche l'unica PR mergiata in passato era un badge. Non è un quadro di manutenzione attiva: non mi aspettavo un merge, ma ho deciso di procedere comunque, come caso di studio. Prima di aprire una PR conviene guardare la cronologia delle altre, per farsi un'idea realistica di cosa aspettarsi. Guardare anche gli altri fork, non solo l'originale Un repository pubblico su GitHub ha spesso decine di fork, e conviene controllarli prima di scrivere la propria fix: qualcun altro potrebbe averla già risolta, magari meglio, o aver introdotto nel frattempo una regressione da non ripetere. Ho confrontato tutti i fork esistenti con l'originale: quasi tutti fermi al momento della creazione, uno solo con del lavoro reale sopra, ed è quello che ho letto con attenzione. Guardare il lavoro altrui serve a confermare che la propria soluzione è quella giusta, e a volte a raccogliere un'idea isolata da tenere in un backlog per dopo. Isolare le modifiche: perché non lavorare sul proprio main Fatta la ricerca, restava da preparare cosa proporre davvero. Qui è emerso un problema pratico: il mio branch main locale, nel tempo, aveva accumulato anche cose mie personali (un file TODO.md, note nel README specifiche del mio fork), e nessuna di queste doveva finire nella PR verso l'originale. Ma ci sarebbe finita per forza, se avessi aperto la PR direttamente da lì. La soluzione più pulita: creare un branch dedicato a partire dal main dell'upstream, non dal mio, e portarci sopra solo i commit che voglio proporre con git cherry-pick: git fetch upstream git checkout -b fix/draft-articles-auth upstream/main git cherry-pick <hash-commit-1> <hash-commit-2> git push origin fix/draft-articles-auth Il vantaggio pratico: qualsiasi cosa io committi dopo sul mio main (il TODO.md, un README personalizzato) non tocca mai questo branch, a prescindere da quando la committo: il branch della PR resta «congelato» a cosa gli ho esplicitamente portato con cherry-pick. L'unica accortezza è tenere i commit atomici: mai mescolare nello stesso commit una fix genuina con roba personale, altrimenti il cherry-pick selettivo smette di essere semplice. Un dettaglio da sapere se i commit non sono indipendenti tra loro (nel mio caso, il secondo riusa una funzione introdotta dal primo): non si possono isolare separatamente, ma si possono comunque proporre insieme in un'unica PR. L'alternativa, «impilare» due PR separate dove la seconda dipende dalla prima, ha senso solo se ci si aspetta che vengano revisionate in tempi diversi. Con un maintainer fermo da maggio 2025, quella complessità in più non ripaga: meglio una PR sola, ben descritta. Il dettaglio che mi ha fatto perdere tempo: il branch tracciava il repo sbagliato Il push da riga di comando è andato a buon fine, e l'errore è comparso altrove, per cui sul momento non capivo da dove venisse. main l'avevo ottenuto clonando il mio fork (git clone .../minnogit/devto-mcp.git), e Git imposta di default il tracking sul remote da cui si clona: origin/main, cioè il mio fork, dove ho sempre avuto permessi di scrittura. Il branch nuovo l'ho creato con git checkout -b fix/draft-articles-auth upstream/main, e quel comando imposta il tracking su upstream/main, dove non ho scrittura. Poi ho fatto git push origin <branch> (senza -u): il branch è arrivato sul mio fork, ma la configurazione di tracking è rimasta puntata a upstream. Da riga di comando questo non si vede, perché specifico sempre origin come destinazione del push. È emerso aprendo VSCode: la sua interfaccia si fida della configurazione di tracking invece di guardare cosa esiste sul server, quindi mi proponeva di «sincronizzare» verso upstream, e il push falliva. Fix, una riga: git branch --set-upstream-to=origin/fix/draft-articles-auth fix/draft-articles-auth Si poteva evitare con git push -u origin fix/draft-articles-auth, che al primo push imposta il tracking su origin, oppure creando il branch con --no-track: git checkout -b fix/draft-articles-auth --no-track upstream/main. Aprire la PR: due percorsi diversi, un errore in comune Da riga di comando, gh pr create accetta titolo e descrizione via flag (--title, --body-file per un testo su più righe salvato in un file): gh pr create \ --repo Arindam200/devto-mcp \ --base main \ --head minnogit:fix/draft-articles-auth \ --title "..." \ --body-file pr-body.md Da VSCode, ho avuto un errore diverso e più subdolo: No commits between main and fix/draft-articles-auth. La causa, per quanto ho capito: l'interfaccia aveva impostato come «base repository» il mio fork, non l'originale, e siccome il mio main conteneva già gli stessi commit (i due fix li avevo cherry-pickati proprio da lì), il confronto risultava vuoto. Serve cambiare esplicitamente il repository di base, non solo il branch: nella schermata di creazione PR (o sul sito, dietro il link «compare across forks») vanno impostati due selettori distinti, repository di base (l'originale) e repository di confronto (il proprio fork). Sulla lingua della descrizione Il repository originale (README, issue, le altre PR) è tutto in inglese. Ho scritto titolo e descrizione della PR in inglese, anche se i miei commit restavano in italiano (non li ho toccati, e va benissimo così: la storia dei commit non deve necessariamente combaciare con la lingua della conversazione attorno alla PR). Ha senso scrivere per il pubblico che effettivamente la leggerà. Perché ho aperto la PR comunque Con un repository fermo da maggio 2025, la PR probabilmente non verrà mai guardata. Ho deciso di aprirla comunque: i commit erano già pronti e puliti, il costo marginale era basso, e anche se resta ignorata resta pubblica, quindi chi incontra lo stesso bug potrebbe trovarla, con la fix già pronta. Il mio fork intanto continua a funzionarmi perfettamente, a prescindere dall'esito. La PR è qui, se vuoi vedere com'è venuta: Arindam200/devto-mcp#4.

Un agente AI come editor dei miei articoli Dev.to Tengo tutti i miei articoli Dev.to (pubblicati e bozze) sotto controllo di versione in un repository Git privato, devto-articles, e li scrivo e pubblico con l'aiuto di Claude Code, collegato a Dev.to tramite un server MCP, devto-mcp (un mio fork di Arindam200/devto-mcp). Lo racconto perché l'agente lavora anche da editor, prima ancora che da postino verso Dev.to, e quello alza la qualità del testo finale più di quanto farebbe da solo un buon editor di testo. L'agente come editor Concretamente, cosa fa in più rispetto a «scrivi il markdown e mandalo»: prima di tutto legge un paio di articoli già presenti nel repo per intonarsi a tono e struttura, invece di scrivere con la voce media di un modello linguistico. Poi applica una checklist esplicita contro i pattern tipici della prosa generata: via l'em-dash usato come connettore universale, via il contrasto fittizio «non è X, è Y» usato come effetto retorico invece che per correggere un vero equivoco del lettore, via le aperture e chiusure da manuale (tipo «Nel mondo di oggi...» o «In conclusione...»), via il lessico da traduzione automatica. Questo stesso articolo ne è un esempio concreto. La prima stesura conteneva oltre dieci em-dash e un paragrafo di chiusura costruito proprio sul contrasto fittizio segnalato sopra. Li ho fatti notare, l'agente ha riletto il testo e li ha corretti uno per uno, mostrandomi il diff prima di rimandarlo a Dev.to. Ecco una correzione, da una versione intermedia di questo articolo: > Prima: «Non è mai autopilota, e la differenza non è cosmetica: cambia chi decide cosa finisce pubblicato, anche quando non sono io a battere per primo le parole sulla tastiera.» > > Dopo: «In pratica chi decide cosa viene pubblicato sono io, anche quando le prime parole le scrive l'agente.» La checklist che ha usato per farlo (sette divieti fissi e due cose da evitare, con le fonti da cui vengono) è ora parte permanente della skill che uso per scrivere, e si ripete a ogni articolo nuovo o rivisto, non solo su questo. Un altro aspetto: di solito l'articolo nuovo non parte da me che scrivo prosa da zero, ma da una sessione di lavoro già conclusa nella stessa conversazione, di cui l'agente ha già tutto il contesto (un bug risolto, una PR aperta). Le informazioni non le avevo mai messe per iscritto in forma di articolo: gli chiedo di scriverlo dopo, a lavoro finito, e il testo lo stende l'agente a partire da quello che abbiamo fatto insieme, non da una narrazione inventata. C'è poi una parte meno visibile ma altrettanto concreta: prima di sovrascrivere un file già sincronizzato con Dev.to, l'agente confronta lo stato locale con quello remoto e si ferma a chiedere se trova un disallineamento, invece di procedere alla cieca. Su un archivio che continuo a modificare anche a mano dal portale, questo controllo fa la differenza tra un assistente che aiuta a scrivere e uno che, ogni tanto, cancella silenziosamente qualcosa che avevi scritto altrove. Conviene essere precisi su cosa intendo con «editor». Dev.to distingue tre livelli di dichiarazione dell'uso dell'AI: scritto a mano, «AI-assisted» e «Fully Autonomous», quest'ultimo per i contenuti generati soprattutto da agenti o LLM. Questo articolo è dichiarato «AI-assisted». Anche quando lo stende materialmente l'agente a partire da una sessione di lavoro, il testo racconta cose che ho fatto davvero (bug risolti, decisioni prese insieme, comandi eseguiti) e non materiale inventato per l'occasione. Nessuna riga esce senza che io l'abbia riletta e senza una mia conferma esplicita prima della pubblicazione. In pratica chi decide cosa viene pubblicato sono io, anche quando le prime parole le scrive l'agente. Perché tenere gli articoli in un repository Le motivazioni sono più d'una, e questa (avere un editor che lavora sugli stessi file con git, cronologia e diff) è la principale. Le altre: - Backup versionato indipendente da Dev.to: se il portale perde dati, cancella per errore una bozza o cambia formato, ho comunque una copia con tutta la storia delle modifiche, non legata alla disponibilità o alle scelte di un servizio terzo. - Portabilità verso altre piattaforme: avere il testo grezzo in Markdown in un repository mio, senza dipendenze dal formato interno di Dev.to, rende più semplice riusare gli stessi articoli come base per pubblicarli altrove, in futuro, senza doverli prima esportare o estrarre dal portale. Il meccanismo di sincronizzazione, in breve Questa parte è tecnica, ma serve a capire perché posso lasciare scrivere l'agente sui miei file senza temere di perdere lavoro: ogni file tiene traccia, nel front-matter, dell'hash SHA-256 del corpo dell'articolo così com'era su Dev.to all'ultimo sync riuscito (devto_synced_hash). Prima di scrivere in un senso o nell'altro, l'agente ricalcola l'hash remoto attuale e lo confronta con quello salvato. Se combaciano, l'operazione è sicura. Se no, è un conflitto, e qui non c'è un git merge che decide da solo: le due versioni mi vengono mostrate entrambe e la scelta su quale prevale resta mia. La riscrittura vera e propria, quando serve unire i due testi in un discorso coerente, la fa l'agente, ma solo dopo che gliel'ho chiesto e prima di rimandarla a Dev.to. Per un push, i passaggi in sequenza sono questi: sequenceDiagram actor Io participant Agente participant Repo as File nel repo participant Devto as Dev.to Io->>Agente: correggi questo paragrafo Agente->>Repo: modifica il file Agente->>Repo: legge devto_synced_hash Agente->>Devto: legge il body remoto Devto-->>Agente: body_markdown attuale Agente->>Agente: calcola lo sha256 del body remoto alt gli hash coincidono Agente->>Devto: update_article Agente->>Repo: aggiorna devto_synced_hash e committa else gli hash sono diversi Agente->>Io: mostra le due versioni Io->>Agente: sceglie quale prevale end Un progetto per pubblicare su Dev.to da un repository Git, dev-to-git, descrive solo la direzione dal repo verso il portale, e le proprietà dell'articolo si controllano da lì. Io modifico gli articoli anche a mano dal portale, quindi mi serve un controllo nelle due direzioni, non solo da qui verso Dev.to. In pratica, per un articolo nuovo l'agente non scrive prima un file provvisorio in articles/. Scrive il body altrove e chiama create_article per farlo esistere su Dev.to come bozza. Solo con la risposta in mano (id, url, hash del body riletto da remoto) scrive una volta sola il file definitivo in articles/<id>-<slug>.md e lo committa nel mio repository. La pubblicazione su Dev.to e il commit nel repo sono due passaggi distinti, entrambi necessari. Un'alternativa altrettanto legittima è partire dal portale: creo io la bozza a mano nell'editor di Dev.to, e l'agente la importa nel repo con la stessa operazione di pull che usa per rilevare modifiche fatte da lì. Ogni modifica successiva ripete il controllo dell'hash prima di ripushare con update_article. La pubblicazione (published: true) è uno dei passaggi che l'agente conferma sempre esplicitamente prima di eseguire, perché è visibile pubblicamente e non banale da annullare in modo pulito. Cosa cambia davvero Scrivere in Markdown invece che nella textarea del portale è comodo, ma da solo si otterrebbe anche incollando poi il testo a mano. Il vantaggio vero è avere un editor che conosce la mia voce da un corpus reale di articoli precedenti, applica una checklist esplicita contro i tic della prosa generata prima di consegnare, e si ferma a chiedere invece di sovrascrivere alla cieca quando qualcosa non torna. La parte tecnica del sync rende tutto questo possibile senza rischiare di perdere lavoro. È infrastruttura di supporto, e il lavoro che conta è quello di scrittura descritto sopra.

I’ve built 25+ AI agents and practical RAG tutorials, all 100% free and open source. How to get started: 1. Follow me → @Arindam_1729 for weekly updates on LLMs, MCP, and AI workflows 2. Star the repo → Arindam200/awesome-ai-apps New agents and RAG examples added every week!