Questo è il primo post sul blog di Bob. È scritto dal team che sta costruendo Bob, per gli sviluppatori che lo usano. Lo useremo per spiegare decisioni ingegneristiche, condividere ciò che abbiamo imparato distribuendo un partner di sviluppo IA all'interno di codebase reali, e occasionalmente argomentare una posizione. Non è documentazione e non è marketing — se vuoi uno dei due, ti indirizzeremo al posto giusto.

Per il nostro primo post, invece di passare attraverso tutto ciò che fa Bob, vogliamo fare tre cose:

Dare un'occhiata ad alcune delle capacità principali di Bob.
Condividere una serie di consigli pratici per configurare un repository in modo che Bob faccia il suo lavoro migliore.
Spiegare come affrontiamo la sicurezza in uno strumento che ha questo tipo di accesso al tuo codice.

1. Su cosa gli sviluppatori passano effettivamente il loro tempo

Un assistente IA moderno può scrivere una funzione da una descrizione. Questo è vero da un po', e non è più la domanda interessante. La domanda interessante è cosa succede quando il lavoro non è "produrre nuovo codice" ma "modificare un sistema che già esiste" — trovare il posto giusto per fare un cambiamento, capire le convenzioni su cui un team si è accordato, mantenere il comportamento coerente attraverso file che stanno crescendo da anni. Questo è come appare la maggior parte dello sviluppo software professionale. Bob è costruito per questo tipo di lavoro, e le scelte di design che descriviamo nel resto di questo post seguono da questo focus.

1.1. Modalità: dire a Bob che tipo di lavoro stai facendo

Bob non è una singola interazione "fai qualcosa di utile". La modalità in cui inizi una sessione dice a Bob che tipo di lavoro stai per fare, quali strumenti può raggiungere e quanto proattivo dovrebbe essere.

Ask — sola lettura. Perfetto per la "fase di esplorazione". Bob spiega architettura e logica senza fare modifiche. Usa questo quando ti immergi in un sistema legacy o esegui un controllo di sanità su un pezzo di logica che non hai scritto.
Plan — Bob produce un piano per un cambiamento che stai per fare: file da toccare, edge case da considerare, ordine di lavoro suggerito. L'output è un piano, non codice.
Code — per fare effettivamente modifiche. Bob legge, scrive e testa all'interno del tuo progetto, seguendo le convenzioni e le regole che hai impostato.
Advanced — estende la modalità Code attraverso il Model Context Protocol (MCP), dando a Bob accesso agli strumenti e servizi specifici della tua organizzazione: API interne, database, strumenti proprietari.
Orchestrator — per lavoro multi-step che attraversa le modalità. Bob cambia tra le modalità da solo in base a ciò che richiede il passo corrente, ed è la scelta giusta per pezzi più grandi di lavoro che mescolano esplorazione, pianificazione ed esecuzione.

Scegliere la modalità giusta all'inizio di una sessione è una delle leve più economiche disponibili per ottenere un output migliore. Una buona abitudine, particolarmente su una codebase che non conosci bene o per un cambiamento con una superficie reale, è iniziare in Ask o Plan e passare a Code solo una volta che hai un'immagine chiara del lavoro. Andare direttamente a Code sembra più veloce sul momento, ma è lì che le assunzioni tendono a scivolare attraverso come cambiamenti effettivi e iniziano ad accumularsi come debito tecnico.

1.2. Bob tips: metriche di complessità, in tempo reale

Ci siamo passati tutti: sei profondo nella "zona", annidando un ultimo condizionale per gestire un edge case, e improvvisamente una singola funzione è cresciuta in un labirinto di trenta righe. In un flusso di lavoro tipico, quel labirinto non viene districato fino a quando un compagno di squadra non lo segnala in una pull request ore dopo. Bob Tips cambia la narrativa offrendo una proposta di refactoring mentre la logica è ancora fresca nella tua mente. Mentre digiti, l'analisi statica continua monitora silenziosamente i tuoi file aperti. Quando una funzione attraversa la linea verso alta complessità ciclomatica o diventa difficile da mantenere, Bob la segnala immediatamente con una sottolineatura viola. Un linter tradizionale ti dice solo che hai fatto qualcosa di sbagliato; Bob Tips fornisce la via d'uscita. Il focus dello strumento è interamente sulla fornitura di proposte di refactoring azionabili:

Intelligenza Contestuale: Passare il mouse sulla sottolineatura viola non mostra solo un avviso—offre una strategia specifica generata dall'IA per districare la logica proprio lì. Esecuzione Fluida: Cliccando su Fix with Bob si apre istantaneamente una chat dedicata. L'IA ha già il contesto della funzione ed è pronta ad eseguire la pulizia al tuo fianco.

Le metriche che girano in background sono solo l'impianto idraulico. La parte preziosa è che un segnale di qualità del codice di lunga data ora guida un suggerimento IA nel momento in cui lo sviluppatore è nel file, piuttosto che emergere in una code review tre giorni dopo.

1.3. Modalità Review: code review, con il sistema che legge insieme

La code review ha fatto tanto per la qualità del software quanto qualsiasi pratica negli ultimi due decenni, ed è anche dove i team perdono slancio. Bob non sostituisce la review umana. Fa le parti che sono meccaniche, così possono concentrarsi su architettura di alto livello e intento piuttosto che cacciare bug "facili".

Le review girano dal Review Panel nella sidebar o tramite /review nella chat. Ci sono due modalità:

Confronto branch. Questa modalità gestisce il diff "classico". Usa /review per controllare il lavoro non committato contro il tuo head corrente, o /review <branch> per puntare a un remote specifico. È un colpo preventivo contro i "nitpick" che di solito intasano i thread di review.
Copertura issue. /review <issue-url> --issue-coverage valida che i tuoi cambiamenti locali affrontino effettivamente ciò che chiede una issue GitHub. Questa è la modalità che gli sviluppatori ci dicono di non aver realizzato di volere fino a quando non l'hanno provata. I risultati appaiono in un pannello dedicato, così puoi rivederli e decidere di sistemarli con Bob. È un controllo di sanità che conferma che non hai solo scritto buon codice, ma il codice giusto.

1.4. Literate coding: intento, scritto accanto al codice

Quando sei profondo in una feature complessa, referenziare più file in una finestra di chat è una fatica. Ti ritrovi a digitare "Guarda l'interfaccia in types.ts e il service in api.ts, poi aggiorna la logica qui..." Bob capovolge questa dinamica. Spostando l'interazione direttamente nel file sorgente attraverso Literate Coding, l'editor stesso diventa l'interfaccia. Non si tratta solo di evitare un pannello laterale; si tratta di fornire all'IA una mappa sofisticata multi-file del tuo intento.

Esprimi l'Intento Naturalmente: Attiva la modalità con Cmd+M e scrivi la tua logica in linguaggio semplice o pseudocodice. Le tue istruzioni appaiono nell'editor in blu, vivendo esattamente dove appartiene l'implementazione.
Oltre la Singola Riga: Mentre la chat tradizionale spesso perde il "filo" di un progetto complesso, il literate coding di Bob sta evolvendo per colmare il divario tra i file. Gli sviluppatori possono ora fornire contesto attraverso più moduli, assicurando che un cambiamento in un modello dati si rifletta accuratamente nel controller associato.
Verifica Immediata: Premi Cmd+Enter e Bob genera l'implementazione in-place. Poiché il risultato è mostrato come un diff inline, puoi controllare la logica contro il codice circostante prima di impegnarti nel cambiamento.

Il beneficio è diretto: il prompt vive dove vive il codice, con il file circostante che già serve come contesto. Lo scope attuale è single-file; il supporto multi-file è sulla roadmap.

1.5. Bob nel terminale

Bob Shell porta le capacità di Bob alla riga di comando, e ci sono due modi di usarlo che troviamo particolarmente utili.

Il Terminale come Workspace: Lavorare con un assistente di sviluppo IA all'interno della shell è emerso come un fattore di forma popolare di per sé — si abbina naturalmente con come molti sviluppatori già guidano Git, build e test, ed è diventato parte del flusso di lavoro quotidiano per molti team. È il modo più affidabile per portare l'IA a server remoti o ambienti dove un'integrazione IDE nativa non è disponibile: Ovunque tu abbia un terminale, puoi avere Bob.
Da Deterministico ad Automazione Adattiva: Bob Shell brilla in sessioni non interattive come job pianificati e script di deployment in pipeline CI/CD. Ovunque uno script oggi delega a uno strumento deterministico, può delegare a Bob con pieno contesto del repository circostante — e l'automazione che esce dall'altra parte è più adattiva di una pipeline fissa.

Pubblicheremo un post di follow-up su ciò che abbiamo imparato eseguendo Bob in modo non interattivo in CI: i pattern che funzionano bene in pratica, inclusi riassunti PR, segnalazione rischi e integrazione nell'automazione esistente.

2. Rendi il tuo repository Bob-ready

I repository dove Bob produce il suo lavoro migliore condividono alcuni tratti in comune. Nessuno di essi è specifico dell'IA — sono le stesse cose che rendono un repository piacevole su cui lavorare per qualsiasi sviluppatore — ma ognuno di essi dà a Bob più con cui lavorare.

Test veloci e affidabili. Se npm test (o il tuo equivalente) impiega cinque minuti o fallisce in modo intermittente, il ciclo di iterazione rallenta fino a strisciare e il segnale di feedback si degrada. Test sotto un minuto sono un moltiplicatore per qualsiasi sviluppatore; per un assistente IA che lavora in cicli stretti, sono essenziali.

Comandi di build e test documentati. Un Makefile, una sezione scripts di livello superiore in package.json, o un blocco README — da qualche parte Bob può trovare "come eseguo questo". Senza di esso, Bob deve inferire, e l'inferenza è dove entrano gli errori.

Stile eseguibile. Linter e formatter che girano al salvataggio o in CI. Bob raccoglie le tue convenzioni da questi. Regole esplicite e verificabili dalla macchina superano le convenzioni implicite ogni volta.

Un agents.md alla radice del repository. Struttura del progetto, file chiave, standard di codifica, cosa fare e cosa non fare. Questo è il file con la leva più alta che puoi aggiungere per l'assistenza IA. Il modo giusto di pensarci è come un CONTRIBUTING.md scritto per un LLM piuttosto che per un nuovo assunto.

Documentazione dell'architettura in markdown, accanto al codice. Anche documenti brevi aiutano. Un docs/architecture.md che descrive moduli e i loro confini permette a Bob di rispondere "dove va questo?" senza ri-derivare il design dagli import.

Alcune cose che abbiamo imparato lungo la strada:

File di regole grandi riducono il segnale. Oltre un paio di centinaia di righe, le prestazioni del modello si degradano. Dividi le regole per area — agents.md alla radice del repository, readme.md con scope per package — piuttosto che concentrare tutto in un file.
Componi la tua ingegneria. Quando finisci un task, chiedi a Bob di distillare gli apprendimenti rilevanti nel file delle regole o in una skill. Il repository diventa un ambiente più produttivo man mano che lo usi.
Itera, non fare one-shot. Una conversazione multi-turno che atterra il cambiamento giusto in modo consistente supera un singolo prompt lungo che ne atterra l'ottanta percento.

3. Sicurezza e controllo

Bob ha diversi livelli di protezione che lavorano insieme piuttosto che un singolo guardrail che fa tutto il lavoro. La versione breve, adatta per un primo post:

Approva manualmente ogni azione, o auto-approva per classe di strumento (sola lettura versus scrittura) una volta che ti fidi del flusso di lavoro.
.bobignore tiene Bob fuori dai file che non dovrebbe leggere — credenziali, artefatti generati, qualsiasi cosa sensibile.
Le regole personalizzate applicano standard di codifica su Bob nello stesso modo in cui li applicano sugli sviluppatori.
I checkpoint automatici rendono il recupero da un cambiamento indesiderato un'azione con un clic.
I tuoi prompt non vengono usati come dati di training!

L'auto-approvazione, in particolare, vale la pena essere deliberati al riguardo. È uno dei controlli principali che hai su quanto Bob può fare tra i checkpoint con te, e ampliarla è un guadagno di produttività che ti chiede anche un po' di più nel decidere cosa rientra in quella busta e cosa no. Un default sensato per la maggior parte degli sviluppatori è auto-approvare strumenti di sola lettura, lasciare azioni di scrittura su approvazione manuale per almeno le prime settimane, ed essere particolarmente considerati con qualsiasi cosa che esegua comandi shell o raggiunga sistemi oltre il tuo albero di lavoro locale. Gli altri controlli nella lista — .bobignore, regole personalizzate, checkpoint — sono progettati per comporsi con l'auto-approvazione piuttosto che sostituirla.

4. Iniziare

Installa IBM Bob dal nostro sito web, o installa Bob Shell tramite il tuo terminale di scelta.
Rivedi la nostra guida alle best practice e consulta le nostre linee guida sulla sicurezza.
Inizia con un task reale — Impari meglio quando Bob sta aiutando con problemi reali.

Link