Dies ist der erste Beitrag im Bob-Blog. Er wurde vom Team geschrieben, das Bob entwickelt, für die Entwickler, die es nutzen. Wir werden ihn nutzen, um technische Entscheidungen zu erklären, zu teilen, was wir beim Ausliefern eines KI-Entwicklungspartners in echten Codebasen gelernt haben, und gelegentlich eine Position zu vertreten. Dies ist keine Dokumentation und kein Marketing – wenn du eines von beiden möchtest, verlinken wir dich an die richtige Stelle.

Für unseren ersten Beitrag möchten wir, anstatt alles durchzugehen, was Bob macht, drei Dinge tun:

Einen Blick auf einige der Kernfähigkeiten von Bob werfen.
Eine Reihe praktischer Tipps teilen, wie du ein Repository einrichtest, damit Bob seine beste Arbeit leistet.
Erklären, wie wir Sicherheit in einem Tool angehen, das diese Art von Zugriff auf deinen Code hat.

1. Womit Entwickler tatsächlich ihre Zeit verbringen

Ein moderner KI-Assistent kann eine Funktion aus einer Beschreibung schreiben. Das ist schon eine Weile wahr, und es ist nicht mehr die interessante Frage. Die interessante Frage ist, was passiert, wenn die Arbeit nicht "neuen Code produzieren" ist, sondern "ein System modifizieren, das bereits existiert" – die richtige Stelle für eine Änderung finden, die Konventionen verstehen, auf die sich ein Team geeinigt hat, das Verhalten über Dateien hinweg konsistent halten, die seit Jahren wachsen. Das ist das meiste, wonach professionelle Softwareentwicklung aussieht. Bob ist für diese Art von Arbeit gebaut, und die Design-Entscheidungen, die wir im Rest dieses Beitrags beschreiben, folgen aus diesem Fokus.

1.1. Modi: Bob sagen, welche Art von Arbeit du machst

Bob ist keine einzelne "mach etwas Nützliches"-Interaktion. Der Modus, in dem du eine Session startest, sagt Bob, welche Art von Arbeit du gleich machen wirst, welche Tools es erreichen kann und wie proaktiv es sein sollte.

Ask – nur lesend. Perfekt für die "Explorationsphase". Bob erklärt Architektur und Logik, ohne Änderungen vorzunehmen. Nutze dies, wenn du in ein Legacy-System eintauchst oder einen Sanity-Check auf einem Stück Logik durchführst, das du nicht geschrieben hast.
Plan – Bob erstellt einen Plan für eine Änderung, die du vornehmen wirst: Dateien zum Anfassen, Edge Cases zu berücksichtigen, vorgeschlagene Reihenfolge der Arbeit. Die Ausgabe ist ein Plan, kein Code.
Code – um tatsächlich Änderungen vorzunehmen. Bob liest, schreibt und testet innerhalb deines Projekts und folgt den Konventionen und Regeln, die du festgelegt hast.
Advanced – erweitert den Code-Modus durch das Model Context Protocol (MCP) und gibt Bob Zugriff auf die spezifischen Tools und Services deiner Organisation: interne APIs, Datenbanken, proprietäre Tools.
Orchestrator – für mehrstufige Arbeit, die Modi überschreitet. Bob wechselt selbst zwischen Modi basierend darauf, was der aktuelle Schritt erfordert, und ist die richtige Wahl für größere Arbeitsstücke, die Exploration, Planung und Ausführung mischen.

Den richtigen Modus am Anfang einer Session zu wählen, ist einer der günstigsten Hebel, um bessere Ausgaben zu erhalten. Eine gute Gewohnheit, besonders bei einer Codebasis, die du nicht gut kennst, oder für eine Änderung mit echter Oberfläche, ist, in Ask oder Plan zu starten und erst zu Code zu wechseln, wenn du ein klares Bild der Arbeit hast. Direkt zu Code zu gehen, fühlt sich im Moment schneller an, aber dort neigen Annahmen dazu, als tatsächliche Änderungen durchzurutschen und sich als technische Schulden anzusammeln.

1.2. Bob Tips: Komplexitätsmetriken in Echtzeit

Wir alle kennen das: Du bist tief in der "Zone", verschachtelst ein letztes Conditional, um einen Edge Case zu behandeln, und plötzlich ist eine einzelne Funktion zu einem dreißigzeiligen Labyrinth gewachsen. In einem typischen Workflow wird dieses Labyrinth erst entwirrt, wenn ein Teamkollege Stunden später in einem Pull Request darauf hinweist. Bob Tips ändert die Erzählung, indem es einen Refactoring-Vorschlag anbietet, während die Logik noch warm in deinem Kopf ist. Während du tippst, überwacht kontinuierliche statische Analyse leise deine offenen Dateien. Wenn eine Funktion die Grenze zu hoher zyklomatischer Komplexität überschreitet oder schwer zu warten wird, markiert Bob sie sofort mit einer lila Unterstreichung. Ein traditioneller Linter sagt dir nur, dass du etwas falsch gemacht hast; Bob Tips bietet den Ausweg. Der Fokus des Tools liegt vollständig darauf, umsetzbare Refactoring-Vorschläge zu liefern:

Kontextuelle Intelligenz: Das Hovern über die lila Unterstreichung zeigt nicht nur eine Warnung an – es bietet eine spezifische, KI-generierte Strategie, um die Logik genau dort zu entwirren. Nahtlose Ausführung: Ein Klick auf Fix with Bob öffnet sofort einen dedizierten Chat. Die KI hält bereits den Kontext der Funktion und ist bereit, das Cleanup neben dir auszuführen.

Die Metriken, die im Hintergrund laufen, sind nur die Rohrleitungen. Der wertvolle Teil ist, dass ein langjähriges Code-Qualitätssignal jetzt einen KI-Vorschlag in dem Moment antreibt, in dem der Entwickler in der Datei ist, anstatt drei Tage später in einem Code-Review aufzutauchen.

1.3. Review-Modus: Code-Review, mit dem System, das mitliest

Code-Review hat in den letzten zwei Jahrzehnten genauso viel für Softwarequalität getan wie jede andere Praxis, und es ist auch dort, wo Teams an Schwung verlieren. Bob ersetzt kein menschliches Review. Es macht die Teile, die mechanisch sind, damit sie sich auf High-Level-Architektur und Absicht konzentrieren können, anstatt nach "low-hanging" Bugs zu jagen.

Reviews laufen vom Review Panel in der Sidebar oder über /review im Chat. Es gibt zwei Modi:

Branch-Vergleich. Dieser Modus behandelt den "klassischen" Diff. Nutze /review, um uncommitted Work gegen deinen aktuellen Head zu prüfen, oder /review <branch>, um einen spezifischen Remote anzuvisieren. Es ist ein präventiver Schlag gegen die "Nitpicks", die normalerweise Review-Threads verstopfen.
Issue-Abdeckung. /review <issue-url> --issue-coverage validiert, dass deine lokalen Änderungen tatsächlich adressieren, was ein GitHub-Issue verlangt. Dies ist der Modus, von dem Entwickler uns sagen, dass sie nicht wussten, dass sie ihn wollten, bis sie ihn ausprobiert haben. Findings erscheinen in einem dedizierten Panel, sodass du sie überprüfen und entscheiden kannst, sie mit Bob zu fixen. Es ist ein Sanity-Check, der bestätigt, dass du nicht nur guten Code geschrieben hast, sondern den richtigen Code.

1.4. Literate Coding: Absicht, neben dem Code geschrieben

Wenn du tief in einem komplexen Feature bist, ist das Referenzieren mehrerer Dateien in einem Chat-Fenster eine Plackerei. Du findest dich dabei, "Schau dir das Interface in types.ts und den Service in api.ts an, dann aktualisiere die Logik hier..." zu tippen. Bob dreht diese Dynamik um. Indem die Interaktion direkt in die Quelldatei durch Literate Coding verschoben wird, wird der Editor selbst zum Interface. Dies geht nicht nur darum, ein Side-Panel zu vermeiden; es geht darum, der KI eine ausgeklügelte, Multi-File-Karte deiner Absicht zu geben.

Absicht natürlich ausdrücken: Schalte den Modus mit Cmd+M um und schreibe deine Logik in einfacher Sprache oder Pseudocode. Deine Anweisungen erscheinen im Editor in Blau und leben genau dort, wo die Implementierung hingehört.
Über die einzelne Zeile hinaus: Während traditioneller Chat oft den "Thread" eines komplexen Projekts verliert, entwickelt sich Bobs Literate Coding weiter, um die Lücke zwischen Dateien zu überbrücken. Entwickler können jetzt Kontext über mehrere Module hinweg bereitstellen und sicherstellen, dass eine Änderung in einem Datenmodell genau im zugehörigen Controller reflektiert wird.
Sofortige Verifikation: Drücke Cmd+Enter und Bob generiert die Implementierung in-place. Da das Ergebnis als Inline-Diff gezeigt wird, kannst du die Logik gegen den umgebenden Code prüfen, bevor du dich zur Änderung verpflichtest.

Der Vorteil ist unkompliziert: Der Prompt lebt dort, wo der Code lebt, wobei die umgebende Datei bereits als Kontext dient. Der aktuelle Scope ist Single-File; Multi-File-Support ist auf der Roadmap.

1.5. Bob im Terminal

Bob Shell bringt Bobs Fähigkeiten zur Kommandozeile, und es gibt zwei Arten, es zu nutzen, die wir besonders lohnenswert finden.

Das Terminal als Workspace: Mit einem KI-Entwicklungsassistenten in der Shell zu arbeiten, hat sich als beliebter Formfaktor an sich herausgestellt – es passt natürlich dazu, wie viele Entwickler bereits Git, Builds und Tests steuern, und ist Teil des täglichen Workflows für viele Teams geworden. Es ist der zuverlässigste Weg, KI zu Remote-Servern oder Umgebungen zu bringen, wo eine native IDE-Integration nicht verfügbar ist: Überall, wo du ein Terminal hast, kannst du Bob haben.
Von deterministisch zu adaptiver Automatisierung: Bob Shell glänzt in nicht-interaktiven Sessions wie geplanten Jobs und Deployment-Skripten in CI/CD-Pipelines. Überall, wo ein Skript heute zu einem deterministischen Tool auslagert, kann es zu Bob mit vollem Kontext des umgebenden Repositorys auslagern – und die Automatisierung, die auf der anderen Seite herauskommt, ist adaptiver als eine feste Pipeline.

Wir werden einen Follow-up-Beitrag darüber veröffentlichen, was wir gelernt haben, Bob nicht-interaktiv in CI laufen zu lassen: die Muster, die in der Praxis gut funktionieren, einschließlich PR-Zusammenfassungen, Risiko-Flagging und Integration in bestehende Automatisierung.

2. Mach dein Repository Bob-ready

Die Repositories, in denen Bob seine beste Arbeit leistet, teilen einige Eigenschaften. Keine davon ist KI-spezifisch – es sind die gleichen Dinge, die ein Repository für jeden Entwickler angenehm machen – aber jede von ihnen gibt Bob mehr, womit es arbeiten kann.

Schnelle, zuverlässige Tests. Wenn npm test (oder dein Äquivalent) fünf Minuten dauert oder intermittierend flakt, verlangsamt sich die Iterationsschleife zu einem Kriechen und das Feedback-Signal degradiert. Tests unter einer Minute sind ein Multiplikator für jeden Entwickler; für einen KI-Assistenten, der in engen Zyklen arbeitet, sind sie essenziell.

Dokumentierte Build- und Test-Befehle. Ein Makefile, eine Top-Level-Scripts-Sektion in package.json oder ein README-Block – irgendwo kann Bob "wie führe ich das aus" finden. Ohne es muss Bob inferieren, und Inferenz ist, wo Fehler eintreten.

Ausführbarer Stil. Linters und Formatter, die beim Speichern oder in CI laufen. Bob nimmt deine Konventionen von diesen auf. Explizite, maschinell überprüfbare Regeln übertreffen implizite Konventionen jedes Mal.

Ein agents.md im Repository-Root. Projektstruktur, Schlüsseldateien, Coding-Standards, Do's und Don'ts. Dies ist die einzelne Datei mit dem höchsten Hebel, die du für KI-Unterstützung hinzufügen kannst. Der richtige Weg, darüber nachzudenken, ist als CONTRIBUTING.md, geschrieben für ein LLM statt für einen neuen Mitarbeiter.

Architektur-Dokumentation in Markdown, neben dem Code. Selbst kurze Dokumente helfen. Ein docs/architecture.md, das Module und ihre Grenzen beschreibt, lässt Bob "wo gehört das hin?" beantworten, ohne Design aus Imports neu abzuleiten.

Ein paar Dinge, die wir unterwegs gelernt haben:

Große Regeldateien reduzieren das Signal. Nach ein paar hundert Zeilen degradiert die Modell-Performance. Teile Regeln nach Bereich auf – agents.md im Repository-Root, scoped readme.md pro Package – anstatt alles in einer Datei zu konzentrieren.
Compound your engineering. Wenn du eine Aufgabe beendest, bitte Bob, die relevanten Learnings zurück in die Regeldatei oder in eine Skill zu destillieren. Das Repository wird zu einer produktiveren Umgebung, während du es nutzt.
Iteriere, nicht one-shot. Eine Multi-Turn-Konversation, die die richtige Änderung konsistent landet, übertrifft einen einzelnen langen Prompt, der achtzig Prozent davon landet.

3. Sicherheit und Kontrolle

Bob hat mehrere Schutzschichten, die zusammenarbeiten, anstatt dass ein einzelnes Guardrail die ganze Arbeit macht. Die Kurzversion, passend für einen ersten Beitrag:

Genehmige jede Aktion manuell oder auto-genehmige nach Tool-Klasse (read-only versus write), sobald du dem Workflow vertraust.
.bobignore hält Bob von Dateien fern, die es nicht lesen sollte – Credentials, generierte Artefakte, alles Sensible.
Custom Rules erzwingen Coding-Standards auf Bob genauso, wie sie sie auf Entwickler erzwingen.
Automatische Checkpoints machen die Wiederherstellung von einer unerwünschten Änderung zu einer Ein-Klick-Aktion.
Deine Prompts werden nicht als Trainingsdaten verwendet!

Auto-Genehmigung ist insbesondere wert, darüber bewusst zu sein. Es ist eine der Hauptkontrollen, die du darüber hast, wie viel Bob zwischen Checkpoints mit dir machen kann, und es zu erweitern ist ein Produktivitätsgewinn, der auch ein bisschen mehr von dir verlangt, zu entscheiden, was in diesen Umschlag fällt und was nicht. Ein vernünftiger Standard für die meisten Entwickler ist, read-only Tools auto-zu-genehmigen, Write-Aktionen für mindestens die ersten paar Wochen auf manueller Genehmigung zu lassen und besonders überlegt mit allem zu sein, was Shell-Befehle ausführt oder Systeme jenseits deines lokalen Working Tree erreicht. Die anderen Kontrollen in der Liste – .bobignore, Custom Rules, Checkpoints – sind so konzipiert, dass sie mit Auto-Genehmigung komponieren, anstatt sie zu ersetzen.

4. Loslegen

Installiere IBM Bob von unserer Website oder installiere Bob Shell über dein Terminal deiner Wahl.
Lies unseren Best-Practices-Leitfaden und konsultiere unsere Sicherheitsrichtlinien.
Starte mit einer echten Aufgabe – Du lernst am besten, wenn Bob bei echten Problemen hilft.

Links