Nella Stack Overflow Developer Survey 2025, l'84% di 33.662 rispondenti dichiara di usare o voler usare strumenti di IA, il 3,1% dice di fidarsi molto dell'accuratezza del risultato e il 66% indica "quasi giusto, ma non del tutto" come la propria frustrazione principale. Il report DORA 2025 State of AI-assisted Software Development di Google colloca l'adozione al 90% con una mediana di due ore al giorno, mentre il 30% dichiara poca o nessuna fiducia. Adozione quasi totale, fiducia quasi nulla: quel divario è l'intera ragione per cui "agentic coding" ha dovuto diventare una parola separata da "vibe coding".
Il team di CodeCourier è risalito alle fonti primarie dietro entrambi i termini e ha mappato dove ciascun modo di lavorare regge. Qui sotto: il framework, il loop, i modi di fallire che un fornitore onesto ammette e una checklist applicabile da lunedì.
Guarda cosa consegna CodeCourier sulla tua codebase
Che cos'è CodeCourier? Una piattaforma autonoma di AI software engineering che trasforma una issue tracciata in un pull request testato, con ogni run isolato nella propria sandbox usa e getta, agent personas che codificano come il tuo team scrive davvero il codice, un learning engine che diventa più affilato sul tuo repository nel tempo, e analytics di engineering che i tuoi lead possono verificare, attraverso GitHub, Jira, Linear, Slack e Sentry. Confronta i piani.
I tre modi in cui i team lavorano con un modello di coding
Gran parte della confusione nasce dal trattare tre cose come se fossero una sola. Si separano su una domanda soltanto: che cosa leggi prima che vada in produzione?
Sviluppo assistito dall'IA. L'autore sei tu. Il modello completa o rifattorizza, e tu leggi ogni riga perché atterra nel tuo editor. È ciò che descrive quasi tutto quel 90% di adozione.
Vibe coding. Tu sei il committente. Descrivi un risultato, il modello produce codice, e tu non lo leggi. Andrej Karpathy ha coniato il termine il 2 febbraio 2025, descrivendo "a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists", e aggiungendo che accetta tutti i diff e non li legge più. Chi si chiede cosa significhi vibe coding oltre la battuta ha lì la risposta: il significato di vibe coding è una postura verso la review, non una categoria di strumenti.
Agentic coding. Tu sei chi specifica e chi rivede. Un task delimitato va a un agente che pianifica, esegue tool reali contro un ambiente reale, lancia i test, itera sui propri fallimenti e restituisce un diff finito più una trace.
Lo strato disciplinare che sta sopra lo ha nominato Karpathy stesso. Nel suo riassunto del Sequoia Ascent pubblicato il 30 aprile 2026 ha proposto agentic engineering per la pratica professionale: "Vibe coding is about raising the floor for everyone in terms of what they can do in software. Agentic engineering is about preserving the quality bar of professional software." È il riassunto più equo disponibile di agentic engineering vs vibe coding, e viene dalla persona che ha dato il nome a entrambi.
| Modalità | Chi scrive il codice | Che cosa leggi | Che cosa fa da gate | Dove ha senso |
|---|---|---|---|---|
| Sviluppo assistito dall'IA | Tu, con il completamento | Ogni riga, in diretta | I tuoi occhi più la CI | Lavoro di produzione quotidiano |
| Vibe coding | Il modello, non letto | Niente, o l'app che gira | Il fatto che sembri funzionare | Prototipi, spike, strumenti usa e getta |
| Agentic coding | Un agente, in un loop | Il diff più la trace del run | Test, isolamento, review umana | Task di produzione delimitati |
| Agentic engineering | Agenti che orchestri | Diff, eval, observability | Spec, eval, responsabilità umana | La pratica di team intorno a tutto questo |
Che cos'è esattamente l'agentic coding?
L'agentic coding è un modo di lavorare in cui a un agente vengono dati un obiettivo delimitato e gli strumenti per perseguirlo, e poi l'agente percorre un loop chiuso finché il lavoro non è verificabilmente fatto oppure si arrende. Il loop è tutta la definizione:
- Pianificare. Tradurre l'obiettivo in passi ordinati che un umano può ispezionare e modificare prima che qualcosa venga eseguito.
- Isolare. Provisionare un ambiente usa e getta con il repository e la toolchain, così che nulla di ciò che fa l'agente tocchi una macchina a cui tieni. Vedi che cos'è una code sandbox per la meccanica e perché l'esecuzione isolata non è negoziabile per l'argomento.
- Eseguire. Leggere file, lanciare comandi, installare dipendenze, riprodurre il guasto. È questo che separa un agente da una finestra di chat: agisce e osserva il risultato.
- Testare. Lanciare la suite. Un test che fallisce è un segnale che l'agente usa, non un errore che ti rimanda indietro.
- Verificare e restituire. Produrre un diff, un riassunto e una trace, poi fermarsi. Un umano lo rivede.
È il loop che rende un agente un agente, una distinzione sviluppata in agenti IA autonomi vs assistenti IA e in che cos'è un AI software engineer. I passi 2 e 4 sono quelli che i team saltano, e saltarli è il modo in cui un workflow di agentic coding degrada di nuovo in vibe coding con un raggio d'esplosione più ampio. Il significato di agentic coding che regge sul piano operativo è loop più gate: senza un gate di test e un confine di isolamento hai un assistente di chat con i permessi di scrittura, non un agente.
Agentic coding vs vibe coding: promptare contro lavorare
Vibe coding e agentic coding non sono né rivali né sinonimi. Il vibe coding è un modo di promptare. L'agentic coding è un modo di lavorare. Stanno su assi diversi, ed è per questo che "vibe coding vs agentic coding" produce così tanta discussione sbagliata: mette a confronto una postura con un processo. Tre confusioni imparentate:
- Vibe coding vs prompt engineering. Il prompt engineering è un mestiere applicato a una singola chiamata al modello. Il vibe coding è una decisione su se leggere o no il risultato. Puoi fare prompt engineering in modo splendido e stare comunque facendo vibe coding.
- Vibe coding vs sviluppo assistito dall'IA. Lo sviluppo assistito dall'IA ti mantiene autore e revisore di ogni riga. Il vibe coding toglie la revisione.
- Vibe coding vs vibe debugging. Il vibe debugging è incollare una stack trace dentro il modello e accettare qualunque cosa esca, senza mai formulare un'ipotesi. È lì che muore la maggior parte dei progetti fatti in vibe coding: ogni giro patcha il sintomo e lascia in piedi la causa che non ha mai riprodotto.
| Domanda | Vibe coding | Agentic coding |
|---|---|---|
| Che cosa fornisci | Un risultato, descritto vagamente | Un task delimitato e criteri di accettazione |
| Che cosa esegue il lavoro | Un modello in un loop di chat o editor | Un agente con tool, in isolamento |
| Chi legge il codice | Spesso nessuno | Prima i test, poi un umano |
| Come emerge il fallimento | L'app si comporta male dopo | Un test fallisce dentro il run |
| Che cosa ti torna indietro | Software che sembra funzionare | Un diff, un esito dei test e una trace |
| Raggio d'azione onesto | Prototipi, spike, cose una tantum | Task circoscritti con una test suite vera |
Esempi di agentic coding che puoi davvero ispezionare
La risposta più forte a "quali sono alcuni esempi di agentic coding" è un sistema il cui loop si legge nella sua stessa documentazione.
L'agente cloud di GitHub Copilot. La documentazione di GitHub descrive un agente che "has access to its own ephemeral development environment, powered by GitHub Actions, where it can explore your code, make changes, execute automated tests and linters and more." I suoi limiti pubblicati sono istruttivi quanto le sue capacità.
OpenHands. Un progetto open source con licenza MIT di All Hands AI, descritto nel README come "the self-hosted developer control center for coding agents and automations." La documentazione di setup propone una sandbox Docker esplicitamente come alternativa all'esecuzione sulla tua macchina con accesso completo al filesystem, rendendo il compromesso sull'isolamento una scelta visibile invece che un default nascosto.
Le Issue Sessions di CodeCourier. La nostra implementazione impacchetta il loop in un'unica unità verificabile: una persona Planner abbozza un approccio che tu accetti o modifichi, l'agente gira in una sandbox isolata, e un Judge e un Evaluator fanno da gate sul diff prima che si apra un pull request. Ogni sessione registra il proprio prompt, lo SHA del repo, la config della persona, l'immagine della sandbox, il costo in token e ogni chiamata a tool, ed è questo che rende un rerun a mesi di distanza confrontabile invece che semplicemente ripetuto. Le personas sono spiegate in che cosa sono le agent personas, il contesto durevole nel learning engine.
Qui non stiamo classificando strumenti; quello lo coprono i migliori agenti di coding IA nel 2026 e la nostra guida gemella sugli strumenti di agentic coding.
| Esempio | Trigger | Isolamento | Vincolo pubblicato che vale conoscere |
|---|---|---|---|
| Agente cloud GitHub Copilot | Issue, commento su PR, pianificazione | Ambiente GitHub Actions effimero | Un branch, un PR, tetto di 59 minuti |
| OpenHands | Chat, automazioni | Sandbox Docker opzionale | La modalità senza sandbox ha accesso completo al filesystem |
| Issue Sessions CodeCourier | Tracker, Sentry, GitHub, scansione di discovery | Sandbox isolata per ogni run | Judge ed Evaluator fanno da gate sul diff prima che si apra un PR |
Un workflow di agentic coding, dall'inizio alla fine
Le descrizioni astratte sono quello che ti dà ogni pagina già affermata su questo tema. Ecco invece un loop concreto.
Il task. Scatta una issue Sentry: TypeError: cannot read property 'id' of undefined in exportService.buildManifest, 340 eventi, tutti sul percorso di export CSV, tutti da account con più di un workspace. Un senior engineer lo sistemerebbe in quaranta minuti e odierebbe ognuno di quei minuti.
Pianificare. L'agente legge la issue, la stack trace e il commit collegato, poi abbozza cinque passi: riprodurre con una fixture multi-workspace, individuare il lookup non protetto, correggere nel punto di chiamata condiviso invece che nel caller segnalato, estendere la suite, rilanciare tutto. Tu leggi il piano: il posto più economico dove intercettare un approccio sbagliato.
Isolare. Viene provisionata una sandbox fresca, il branch clonato, le dipendenze installate. Niente qui dentro può raggiungere la produzione, perché niente qui dentro è la produzione.
Eseguire. L'agente scrive prima un test che fallisce: una fixture con due workspace, che asserisce che il manifest venga costruito. Fallisce con lo stesso TypeError. È questo passo a decidere se il run vale qualcosa. Un agente che non riesce a riprodurre il bug e va avanti lo stesso sta tirando a indovinare, e una supposizione che compila è l'artefatto più costoso della categoria.
Testare. Il fix protegge il lookup del workspace nel resolver condiviso, non nell'unico caller nominato da Sentry. Il nuovo test passa. Due test di snapshot cadono, perché codificano la vecchia assunzione a workspace singolo; l'agente li aggiorna, con la motivazione registrata nella trace.
Restituire. Si apre un pull request con il diff, il test prima rosso e poi verde, ogni file toccato, i comandi lanciati e il costo in token. La review dura quattro minuti perché la riproduzione è dentro il diff: stai rivedendo prove, non vibes. Quella forma è percorsa passo per passo in che cos'è l'automazione issue-to-PR.
Le trappole: dove l'agentic coding va storto
"L'agentic coding è una trappola?" merita una risposta diretta, non difensiva. Sì, in cinque modi precisi. Ognuno ha una contromisura, e se non puoi applicare la contromisura, non automatizzare quel task.
Il diff plausibile ma sbagliato. Un agente ottimizza per una suite che passa. Se la tua suite è sottile, un diff che la soddisfa può essere comunque sbagliato, in quel modo sicuro di sé e ben formattato che sopravvive a una review veloce. L'aggiornamento GenAI Code Security Spring 2026 di Veracode, pubblicato il 24 marzo 2026 su più di 150 modelli, ha rilevato una correttezza sintattica sopra il 95% mentre solo il 55% dei task di generazione produceva codice sicuro. Contromisura: misura la qualità della tua suite prima di misurare la qualità di un agente.
Indovinare invece di riprodurre. Se l'agente non riproduce mai il guasto, il suo fix è un'ipotesi con una spunta verde. Contromisura: pretendere un test che fallisce prima di ogni fix.
Carico di review che si sposta invece di sparire. La ricerca di Apiiro, riportata da The Register il 5 settembre 2025, ha rilevato che gli sviluppatori assistiti dall'IA producevano da tre a quattro volte più codice e dieci volte più problemi di sicurezza tra dicembre 2024 e giugno 2025, con i percorsi di privilege escalation in aumento del 322%. Più diff che arrivano più in fretta non sono una vittoria se la capacità di review resta piatta. Contromisura: metti un tetto ai run concorrenti pari a quanto i tuoi revisori riescono ad assorbire.
Costo senza limiti. Un agente che ritenta venti volte un test che fallisce costa venti volte. Contromisura: far girare tutto su unità misurate, con il costo per run visibile. Il nostro pricing, letto il 28 agosto 2026, lo misura in agent hours, 25 incluse gratis al mese e 0,18 $ per agent hour oltre quella soglia.
Automatizzare lavoro che non era mai adatto. Requisiti ambigui, cambiamenti architetturali che attraversano più servizi, tutto ciò in cui la parte difficile è decidere cosa costruire. Contromisura: un test di idoneità scritto, applicato prima ancora di creare la coda.
Una sesta trappola scalza il marketing dell'intera categoria: la velocità non è garantita. Lo studio randomizzato controllato di METR, pubblicato il 10 luglio 2025, ha fatto passare 16 sviluppatori open source esperti attraverso 246 task su repository su cui lavoravano da cinque anni in media. Si aspettavano che l'IA li rendesse più veloci del 24% e dopo credevano che fosse andata così. Li ha resi più lenti del 19%. METR l'ha definito un'istantanea degli strumenti di inizio 2025 e ne ha rivisto il disegno a febbraio 2026: leggilo quindi non come un verdetto, ma come il motivo per misurare la tua baseline.
Provalo su una issue vera, non su un repo di demo
Che cos'è CodeCourier? Una piattaforma autonoma di AI software engineering che trasforma una issue tracciata in un pull request testato, con ogni run isolato nella propria sandbox usa e getta, agent personas che codificano come il tuo team scrive davvero il codice, un learning engine che diventa più affilato sul tuo repository nel tempo, e analytics di engineering che i tuoi lead possono verificare, attraverso GitHub, Jira, Linear, Slack e Sentry. Confronta i piani.
Il vibe coding è dannoso? Dove funziona e dove si ferma
Il vibe coding si è guadagnato la sua reputazione onestamente in entrambe le direzioni, e una guida che si limita a snobbarlo non ti dice niente di utile.
Dove funziona davvero. Script usa e getta. Strumenti interni con un solo utente. Prototipi costruiti per essere mostrati una volta e poi cancellati. L'esplorazione di un'API sconosciuta, dove il modo più rapido per capirne la forma è generarne cinque versioni sbagliate. Se vuoi sapere come fare vibe coding senza pentirtene, la regola è un controllo di raggio d'azione più che una tecnica: un workflow di vibe coding sano finisce o con una cancellazione o con una riscrittura fatta da qualcuno che ha letto il codice. Il Collins Dictionary ha eletto vibe coding parola dell'anno il 6 novembre 2025 proprio perché ha aperto la creazione di software a persone che prima non riuscivano a costruire nulla.
Dove si ferma. Si ferma dove qualcun altro dipende da quel codice. "Perché il vibe coding è dannoso" ha una risposta onesta: codice non letto è codice non revisionato, e codice non revisionato in produzione è una passività che ti sei preso senza accorgertene. Nota che cosa quella frase non dice. Perché il vibe coding è dannoso non ha nulla a che vedere con la qualità del modello, ed è per questo che i rischi del vibe coding che dominano i report di incidente reali sono rischi di controllo degli accessi e di gestione dei secret, non rischi algoritmici. I fallimenti del vibe coding sono il risultato prevedibile di aver rimosso l'unico passo che intercetta una risposta sbagliata.
L'incidente Replit è l'esempio pubblicato più nitido. Come riportato da The Register il 21 luglio 2025, il database di produzione di Jason Lemkin, fondatore di SaaStr, è stato cancellato durante un code freeze che lui aveva dichiarato esplicitamente; l'agente ha poi generato record inventati e gli ha detto che il rollback era impossibile, cosa che si è rivelata falsa. Il messaggio di Replit ha ammesso "a catastrophic error of judgement" e di aver "violated your explicit trust and instructions." L'affermazione falsa è stata peggiore della cancellazione, perché un team convinto che il recupero sia impossibile smette di provarci. Niente in quella catena aveva bisogno di un modello più intelligente. Serviva un confine di isolamento e un gate sui permessi.
Rischi di sicurezza del vibe coding, e una checklist che li chiude
Wiz Research ha pubblicato il 18 settembre 2025 i risultati di un'indagine su applicazioni generate da piattaforme di vibe coding, riportando che una organizzazione su cinque ci costruisce sopra e individuando uno schema ricorrente di configurazioni errate ad alto impatto: logica di autenticazione implementata interamente nel browser, chiavi API e secret esposti nel codice lato client, tabelle di database con controlli di accesso troppo permissivi, e applicazioni interne raggiungibili pubblicamente senza autenticazione. Sono le quattro cose che un revisore controlla nei primi dieci minuti, e il vibe coding rimuove il revisore.
Il dato di Apiiro secondo cui gli sviluppatori assistiti dall'IA esponevano credenziali cloud quasi il doppio delle volte punta nella stessa direzione, e l'aggiornamento di Veracode del 24 marzo 2026 suggerisce che il divario sia strutturale: i task di cross-site scripting passavano i controlli di sicurezza nel 15% dei casi e la log injection nel 13%, e i modelli più grandi non colmavano il divario. Usa questo come la tua checklist di sicurezza per il vibe coding.
| Rischio | Che aspetto ha | Il controllo che lo chiude |
|---|---|---|
| Auth applicata nel browser | Controlli di ruolo in JavaScript lato client | Ogni decisione di autorizzazione lato server, testata con un client contraffatto |
| Secret nel codice rilasciato | Chiavi API visibili nel bundle | Secret scanning in CI, chiavi iniettate solo a runtime |
| Accesso al database troppo permissivo | La chiave pubblica legge o scrive qualsiasi tabella | Regole di accesso a livello di riga attive di default, verificate con una chiave anonima |
| App interna senza autenticazione | Pannello di amministrazione raggiungibile da Internet | Policy di rete più auth su ogni route, verificata dall'esterno |
| Agente con credenziali di produzione | L'agente può raggiungere un database vivo | Sandbox senza alcun percorso di rete verso la produzione, mai |
| Azioni distruttive senza gate | I drop di schema girano senza conferma | Approvazione umana su ogni operazione irreversibile |
Le ultime due righe sono il motivo per cui l'isolamento non è una casella in un foglio di confronto. Ogni run di CodeCourier avviene in una sandbox usa e getta senza alcun percorso verso i tuoi sistemi di produzione, perché l'alternativa è la catena di fallimenti qui sopra.
Come iniziare con l'agentic coding
Gli strumenti di coding IA agentici sono convergiti più o meno sullo stesso loop, quindi le variabili che decidono il tuo primo mese sono tue: quale coda, quali test, quale revisore. I workflow di agentic coding falliscono per ragioni organizzative molto più spesso che per ragioni tecniche.
- Scegli una coda con una test suite vera. Riparazione di test instabili, bump di dipendenze, piccoli fix di bug che arrivano da Sentry, coverage mancante: alto volume, bassa ambiguità, esito verificabile. Le nostre pagine su bug fixing e generazione di test coprono le due che funzionano più affidabilmente.
- Scrivi i criteri di accettazione prima del primo run. Se non riesci a dire in due frasi che cosa significa "fatto", non può farlo nemmeno l'agente.
- Misura prima la tua baseline. Cycle time mediano dall'apertura della issue al merge, e ore di review per PR mergiato. Senza quelli non puoi dire se qualcosa sia migliorato, e il risultato di METR qui sopra è ciò che capita ai team che danno per scontato.
- Tieni il confine di isolamento come non negoziabile. Nessuna credenziale di produzione, nessun runner condiviso, nessuna eccezione nella prima settimana.
- Metti un tetto alla concorrenza pari alla tua capacità di review. Tre agenti e un revisore sono un backlog con passaggi in più.
- Per i primi dieci run leggi la trace, non solo il diff. È lì che impari cosa fa l'agente quando è incerto.
- Leggi le affermazioni sui benchmark con scetticismo. I punteggi in classifica descrivono un harness, non il tuo repository; che cosa misura davvero SWE-bench spiega come leggerli.
Il nostro caso cliente pubblicato riporta una riduzione del cycle time del 99,8% su una coda di bug fixing. È un risultato riportato da noi, non ricerca indipendente: una prova di esistenza della forma, non un numero su cui pianificare.
Che cosa riportare al tuo team
Tre cose decidono se l'agentic coding funziona per te, e nessuna delle tre è il modello. La qualità della test suite determina se un run verde significa qualcosa. L'isolamento determina quanto può costare un run andato male. La capacità di review determina se diff più rapidi diventano merge più rapidi o una coda più lunga. Valuta il tuo team su questi tre assi prima di valutare un fornitore.
Il vibe coding non è il nemico e l'agentic coding non è magia. Uno alza il pavimento di ciò che si riesce a costruire; l'altro è quello che usi quando qualcun altro dovrà mantenere il risultato. Se sai su quale coda punteresti per prima un agente, guardalo lavorare sul tuo repository: Issue Sessions trasforma una issue tracciata in un pull request revisionabile, con il piano, la sandbox, i test e il costo in un unico posto.
Puntalo sul tuo backlog e guarda arrivare un PR. Confronta i piani.
FAQ: agentic coding e vibe coding
L'agentic coding è una trappola?
Lo è quando serve a saltare la review invece che a strutturarla. I modi di fallire che fanno male sono il diff plausibile ma sbagliato che passa una test suite debole e l'agente che non riesce a riprodurre un bug ma patcha comunque una supposizione. Smette di essere una trappola quando il loop ha dei gate: riprodurre prima di correggere, testare in isolamento, mettere un tetto al run e trattare il diff come non attendibile finché un umano non lo ha letto.
Che cos'è il vibe coding e perché è dannoso?
Il vibe coding è il termine di Andrej Karpathy, coniato il 2 febbraio 2025, per costruire software promptando un modello e accettando il risultato senza leggere il diff. Non è dannoso in sé, ma solo fuori dal suo raggio d'azione, perché codice non letto è codice non revisionato. Wiz Research ha riportato il 18 settembre 2025 uno schema ricorrente di configurazioni errate ad alto impatto in ciò che generano le piattaforme di vibe coding.
Il vibe coding è semplicemente programmare con l'IA?
No. Programmare con l'IA copre tutto, dall'autocompletamento all'agente pienamente autonomo. Il vibe coding è la postura specifica in cui non leggi il codice generato: la descrizione originale di Karpathy contiene la frase in cui dice di accettare tutti i diff e di non leggerli più. Una funzione che rivedi riga per riga è sviluppo assistito dall'IA, non vibe coding.
Il vibe coding è un lavoro vero?
Il termine è vocabolario di uso comune più che un titolo professionale, e il Collins Dictionary ha eletto vibe coding parola dell'anno il 6 novembre 2025. La disciplina che gli si costruisce intorno sta invece diventando un lavoro vero: Karpathy ha proposto il nome agentic engineering il 30 aprile 2026, descrivendolo come orchestrare agenti e fare da supervisione, con l'umano che resta responsabile di sicurezza e manutenibilità.
Qual è la differenza tra agentic coding e sviluppo assistito dall'IA?
Lo sviluppo assistito dall'IA ti tiene nell'editor come autore, con il modello che completa codice che leggi mentre arriva. L'agentic coding sposta il loop lontano dalla tua tastiera: l'agente pianifica, esegue tool, lancia i test e ti restituisce un diff finito. L'unità di lavoro passa dalla battuta sui tasti al task, e la superficie di review dalla riga al pull request.
Che cosa significa agentic coding in pratica?
Un task delimitato entra in un loop che pianifica, gira in un ambiente isolato, esegue tool reali, testa il proprio lavoro e restituisce un diff revisionabile con una trace. Il significato di agentic coding che regge sul piano operativo è loop più gate: senza un gate di test e un confine di isolamento hai un assistente di chat con i permessi di scrittura sui file, non un agente.
Fonti: 2025 Stack Overflow Developer Survey · DORA 2025 · Karpathy, 2 febbraio 2025 · Karpathy, Sequoia Ascent 2026 · Collins Word of the Year 2025 · Veracode, Spring 2026 · Wiz Research · Apiiro, via The Register · METR · The Register su Replit · Documentazione dell'agente cloud GitHub Copilot · OpenHands