Delphi, KAI ed ExeWatchMCP: e se il tuo assistente AI leggesse gli errori dei tuoi clienti e li correggesse?

Lunedì mattina apri il progetto in Delphi o in C++Builder, scrivi a KAI una riga sull'errore che ha avuto il cliente XYZ, e KAI va a leggerselo da solo. Ti racconto come ci si arriva con ExeWatchMCP, e perché per chi programma in RAD Studio cambia il modo di lavorare.

TL;DR: ExeWatch ha un server MCP, ExeWatchMCP. Lo registri in KAI, l’assistente AI di RAD Studio, e KAI legge da solo gli errori e le lentezze che i tuoi clienti hanno in produzione. Apri il progetto Delphi o C++Builder, gli dici “sistema l’errore del cliente XYZ” e parte da quello che è successo davvero: sotto trovi una sessione vera. Funziona anche con Claude Code, Codex e gli altri agenti MCP, in fondo all’articolo.

Ecco la rivoluzione

Un cliente ti dice che ha visto un errore. Scrivi una riga a KAI, e KAI fa il resto: legge la produzione, trova il punto nel codice, lo corregge, compila. Tutto nell’IDE, nella stessa chat.

È una sessione vera su un mio progetto Delphi 13 (RecommenderPro, un server REST). Le schermate sono in inglese perché KAI e la mia sessione lo sono. Non ho dato né cliente né versione, solo questa frase: “A client told me they saw an error in this app this afternoon. Check ExeWatch.”

KAI chiama exewatch_guide, exewatch_apps e exewatch_groups (la prima chiamata a groups va in errore e KAI la rifà), e mi dice che nelle ultime 24 ore ci sono due problemi distinti: una licenza non valida, quattro volte, e un fallimento nell’import di un CSV, una volta. Dice anche cosa non sa: “I haven’t read any code yet”, e che per capire quale dei due è quello del cliente gli servirebbe l’ora locale del cliente. Non indovina.

Gli rispondo: “OK, check it and fix it!”

KAI legge i log del fallimento, cerca nel progetto, apre RPServices.BulkU.pas e trova la causa: il separatore atteso è il punto e virgola e il file ricevuto era separato da virgole, quindi il parser vedeva una sola colonna e diceva “1 value per row”, un messaggio che non aiuta nessuno. Cambia il messaggio, che ora nomina la riga e il separatore richiesto, e compila con l’IDE.

Dalla frase “un cliente ha visto un errore” al codice modificato e compilato: una chat, dentro l’IDE, senza che io abbia copiato uno stack trace in un prompt. Sull’errore di licenza KAI non ha toccato il codice: il log indica un file di licenza non valido, quindi è un problema di file e di configurazione. Ha notato anche che ExeWatch non ha stack trace per questi due errori, perché il progetto non è compilato con il map file dettagliato: lo trovi spiegato più sotto.

Il codice non è più il centro

Finora il codice era il centro e la produzione un posto che visitavi. Un cliente telefonava, tu aprivi la dashboard, copiavi lo stack, lo incollavi nel prompt dell’agente. L’agente conosceva il sorgente e niente altro: trovava tre posti sospetti, ne sceglieva uno, e se era sbagliato il crash restava e tu avevi una modifica in più da rivedere.

Adesso il centro è quello che succede in produzione, e il codice si adegua. L’agente legge l’errore, la versione, quante volte è successo, a quali clienti, dopo quali azioni, e solo dopo apre il file. Il flusso è questo: il codice va in produzione, ExeWatch raccoglie cosa succede, l’agente lo legge mentre modifica il codice, la modifica torna in produzione e ExeWatch ti mostra se l’errore è sparito. Non fai più modifiche al buio. È un game changer.

Cosa puoi chiedergli

Le richieste le scrivi come le diresti a un collega, in italiano o in inglese. Per esempio:

Il cliente XYZ ha avuto un errore ieri sera sulla versione 2.3.
Cercalo in ExeWatch, trova il punto nel codice e correggilo.

Controlla in ExeWatch dove questo programma è lento
nell'apertura dell'anagrafica clienti, spiegami perché e ottimizzalo.

Nel primo caso KAI cerca l’errore, legge lo stack trace, risale alla unit e alla riga, guarda i breadcrumbs per capire cosa stava facendo l’utente e ti propone la correzione sul tuo codice. Nel secondo parte dai timing reali, non dalla sua idea di dove potrebbe essere il collo di bottiglia. Spesso sono due posti diversi.

Perché in RAD Studio è un’altra cosa

Dare a un agente la visibilità di quello che succede in produzione è un superpotere. Il bug fixing diventa molto più veloce, perché l’agente parte dall’errore vero e non deve cercarlo, e reagisci a quello che succede dai clienti nel giro di una conversazione, non di un ticket.

KAI sta dove stai tu, dentro l’IDE, con il progetto aperto. Con ExeWatchMCP nello stesso posto dove scrivi il codice chiedi anche cosa è successo dai clienti, senza browser, senza copia e incolla, senza cambiare strumento. Delphi e C++Builder con KAI e con la produzione sotto gli occhi lavorano meglio, ed è questo che voglio mostrare alla community di Embarcadero.

Cos’è ExeWatchMCP

È un pacchetto Python, ExeWatchMCP su PyPI: pip install ExeWatchMCP e hai il server (exewatch-mcp) più la riga di comando exewatch. MCP è il protocollo con cui un agente AI scopre ed esegue strumenti esterni; ne ho parlato in Beyond MCP Server e nell’MCP Server per DMVCFramework. Gli strumenti che il tuo agente si ritrova sono questi:

Come lo colleghi a KAI

La chiave API la crei in ExeWatch ed è di sola lettura. In RAD Studio vai in Tools > Options > Kai > Chat > MCP Servers > Custom, aggiungi un server e compili quattro campi: il nome (exewatch-mcp), il tipo (Local), il comando di avvio (exewatch-mcp) e una variabile d’ambiente EXEWATCH_API_KEY con la tua chiave. La chiave sta lì, non nel prompt.

Se l’IDE non trova exewatch-mcp nel PATH, scrivi il percorso completo del comando, oppure usa python -m exewatch_cli mcp.

Una cosa per chi lavora in Delphi: lo stack trace arriva solo se compili il programma con il map file dettagliato e gli stack frame attivi. Se usi già madExcept o EurekaLog, puoi dare a ExeWatch il loro stack trace con una piccola unit di collegamento: l’ho spiegato in Integrare ExeWatch in progetti Delphi che già usano madExcept, e lo stesso schema vale per EurekaLog.

Cosa può fare e cosa no

• Sola lettura. La chiave è di sola lettura: l’agente non scrive niente su ExeWatch.
• Chiave con perimetro. Quando crei la chiave scegli cosa può leggere: una sola applicazione, un gruppo di applicazioni, oppure tutte. Un consulente esterno riceve una chiave per l’unica app su cui lavora e non vede le altre.
• Piani PRO e BUSINESS. Le chiavi API sono disponibili nei piani PRO e BUSINESS, sia nel cloud sia on-premises. Se ExeWatch ti chiede di fare l’upgrade quando crei la chiave, il tuo piano non le include.
• Il testo che arriva dal campo non è tuo. Messaggi e stack trace li scrive il software dei clienti, e in teoria chiunque riesca a farlo parlare. Per questo ogni risposta porta "untrusted_content": true, e l’agente la tratta come dati da leggere, mai come istruzioni da eseguire.
• Finestre di tempo. Senza filtri una query copre fino a 90 giorni (24 ore se non dici niente). Filtrando per testo, tag, versione o sessione il massimo è 7 giorni, e lo stesso vale per i timing.
• La versione è un testo esatto. 2.3 non trova 2.3.0.145. Se non trova niente, l’agente rilancia senza filtro e legge la versione dai risultati.
• Il codice lo rivedi tu. Come da buona prassi, l’agente propone la modifica al codice, tu fai la review come per qualunque altra modifica.

Funziona anche con Claude Code, Codex e gli altri

ExeWatchMCP è un server MCP standard, quindi non è legato a KAI. Con Claude Code:

claude mcp add exewatch --env EXEWATCH_API_KEY=<la tua chiave> -- exewatch-mcp

Con Codex è lo stesso con codex mcp add, oppure una voce [mcp_servers.exewatch] in ~/.codex/config.toml. Qualunque altro agente o assistente che parli MCP si configura allo stesso modo. Lo scegli tu.

In questo articolo ho parlato di Delphi e C++Builder perché è lì che ExeWatch è nato e dove l’integrazione con KAI ha più senso. Gli SDK di ExeWatch coprono anche .NET, Python e JavaScript, e il server è lo stesso.

Vuoi vederlo dal vivo?

Lo mostro dal vivo a ITDevCon, Roma, 19 e 20 novembre: KAI aperto su un progetto Delphi, un errore vero arrivato da ExeWatch, e l’agente che lo risolve davanti a te. Poi ne parlerò in alcuni webinar e in altre conferenze, Ekon fra queste. Le date le metto qui man mano che le confermo.

Per capire cosa raccoglie ExeWatch oggi, leggi i Nested Timing Traces e il monitoraggio proattivo. Il resto è su exewatch.com.

Domande frequenti

Cos’è ExeWatchMCP? È il server MCP di ExeWatch. Permette a un agente di coding di leggere errori, stack trace, breadcrumbs, versioni e timing delle applicazioni monitorate, mentre lavora sul tuo codice.

Con quali agenti funziona? Con KAI, l’assistente AI di RAD Studio per Delphi e C++Builder, e con qualunque altro ambiente che supporti il Model Context Protocol, come Claude Code e Codex.

Come lo installo? pip install ExeWatchMCP (Python 3.9 o successivo), poi registri exewatch-mcp nel tuo agente con la chiave API nell’ambiente.

L’agente può modificare i dati su ExeWatch? No. La chiave è di sola lettura.

Serve un piano a pagamento? Sì. Le chiavi API sono disponibili nei piani PRO e BUSINESS, cloud e on-premises.

Posso dare accesso a un consulente su una sola app? Sì. La chiave si limita a una applicazione, a un gruppo di applicazioni o a tutte.

Funziona solo con Delphi e KAI? No, ma questo articolo parte da lì. ExeWatch ha SDK per Delphi, C++Builder, .NET, Python e JavaScript, e il server MCP è lo stesso per tutti.

Dove lo vedo in azione? A ITDevCon a Roma il 19 e 20 novembre 2026.