To jest pierwszy post na blogu Bob. Jest napisany przez zespół budujący Boba, dla programistów, którzy go używają. Będziemy go używać do wyjaśniania decyzji inżynieryjnych, dzielenia się tym, czego nauczyliśmy się dostarczając AI development partner wewnątrz rzeczywistych baz kodu, i czasami argumentowania stanowiska. To nie jest dokumentacja i to nie jest marketing — jeśli chcesz któregokolwiek z nich, przekierujemy cię we właściwe miejsce.

W naszym pierwszym poście, zamiast przechodzić przez wszystko, co robi Bob, chcemy zrobić trzy rzeczy:

Przyjrzeć się kilku podstawowym możliwościom Boba.
Podzielić się zestawem praktycznych wskazówek dotyczących konfigurowania repozytorium, aby Bob wykonywał swoją najlepszą pracę.
Wyjaśnić, jak podchodzimy do bezpieczeństwa w narzędziu, które ma tego rodzaju dostęp do twojego kodu.

1. Na czym programiści faktycznie spędzają swój czas

Nowoczesny asystent AI może napisać funkcję z opisu. To jest prawdą od jakiegoś czasu i nie jest już interesującym pytaniem. Interesującym pytaniem jest to, co się dzieje, gdy praca nie polega na "produkowaniu nowego kodu", ale "modyfikowaniu systemu, który już istnieje" — znalezieniu właściwego miejsca na wprowadzenie zmiany, zrozumieniu konwencji, na które zespół się zgodził, utrzymaniu spójnego zachowania w plikach, które rosną od lat. Tak wygląda większość profesjonalnego rozwoju oprogramowania. Bob jest zbudowany dla tego rodzaju pracy, a wybory projektowe, które opisujemy w pozostałej części tego posta, wynikają z tego skupienia.

1.1. Tryby: mówienie Bobowi, jaki rodzaj pracy wykonujesz

Bob to nie pojedyncza interakcja "zrób coś użytecznego". Tryb, w którym rozpoczynasz sesję, mówi Bobowi, jaki rodzaj pracy zamierzasz wykonać, do jakich narzędzi może sięgnąć i jak proaktywny powinien być.

Ask — tylko do odczytu. Idealny do "fazy eksploracji". Bob wyjaśnia architekturę i logikę bez wprowadzania zmian. Użyj tego, gdy zanurzasz się w systemie legacy lub wykonujesz sprawdzenie poprawności fragmentu logiki, którego nie napisałeś.
Plan — Bob tworzy plan zmiany, którą zamierzasz wprowadzić: pliki do dotknięcia, edge cases do rozważenia, sugerowana kolejność pracy. Wyjściem jest plan, a nie kod.
Code — do faktycznego wprowadzania zmian. Bob czyta, pisze i testuje w twoim projekcie, przestrzegając konwencji i zasad, które ustaliłeś.
Advanced — rozszerza tryb Code poprzez Model Context Protocol (MCP), dając Bobowi dostęp do specyficznych narzędzi i usług twojej organizacji: wewnętrzne API, bazy danych, zastrzeżone narzędzia.
Orchestrator — dla wieloetapowej pracy, która przekracza tryby. Bob sam przełącza się między trybami w zależności od tego, czego wymaga bieżący krok, i jest właściwym wyborem dla większych fragmentów pracy, które łączą eksplorację, planowanie i wykonanie.

Wybór właściwego trybu na początku sesji to jedna z najtańszych dźwigni dostępnych do uzyskania lepszego wyniku. Dobrym nawykiem, szczególnie w bazie kodu, której nie znasz dobrze, lub dla zmiany z jakąkolwiek rzeczywistą powierzchnią, jest rozpoczęcie w Ask lub Plan i przełączenie się na Code dopiero wtedy, gdy masz jasny obraz pracy. Przejście bezpośrednio do Code wydaje się szybsze w danym momencie, ale to tam założenia mają tendencję do prześlizgiwania się jako rzeczywiste zmiany i zaczynają się gromadzić jako dług techniczny.

1.2. Bob tips: metryki złożoności w czasie rzeczywistym

Wszyscy tam byliśmy: jesteś głęboko w "strefie", zagnieżdżając ostatni warunek do obsługi edge case, i nagle pojedyncza funkcja urosła do trzydziestoliniowego labiryntu. W typowym przepływie pracy ten labirynt nie zostaje rozplątany, dopóki członek zespołu nie wskaże go w pull request godziny później. Bob Tips zmienia narrację, oferując propozycję refaktoryzacji, gdy logika jest jeszcze świeża w twojej głowie. Podczas pisania ciągła analiza statyczna cicho monitoruje twoje otwarte pliki. Gdy funkcja przekracza granicę wysokiej złożoności cyklomatycznej lub staje się trudna do utrzymania, Bob natychmiast oznacza ją fioletowym podkreśleniem. Tradycyjny linter tylko mówi ci, że zrobiłeś coś źle; Bob Tips zapewnia wyjście. Skupienie narzędzia jest całkowicie na dostarczaniu wykonalnych propozycji refaktoryzacji:

Kontekstowa Inteligencja: Najechanie na fioletowe podkreślenie nie tylko wyświetla ostrzeżenie — oferuje konkretną, wygenerowaną przez AI strategię rozplątania logiki właśnie tam. Płynne Wykonanie: Kliknięcie Fix with Bob natychmiast otwiera dedykowany czat. AI już posiada kontekst funkcji i jest gotowe do wykonania czyszczenia obok ciebie.

Metryki działające w tle to tylko instalacja. Wartościową częścią jest to, że długotrwały sygnał jakości kodu teraz napędza sugestię AI w momencie, gdy programista jest w pliku, zamiast pojawiać się w code review trzy dni później.

1.3. Tryb Review: code review, z systemem czytającym razem

Code review zrobiło tyle dla jakości oprogramowania, co każda praktyka w ciągu ostatnich dwóch dekad, i jest również miejscem, gdzie zespoły tracą impet. Bob nie zastępuje ludzkiego review. Wykonuje części, które są mechaniczne, więc mogą skupić się na architekturze wysokiego poziomu i intencji zamiast polowania na "łatwe" błędy.

Review uruchamiają się z Review Panel na pasku bocznym lub przez /review w czacie. Są dwa tryby:

Porównanie branch. Ten tryb obsługuje "klasyczny" diff. Użyj /review do audytu niezacommitowanej pracy względem twojego bieżącego head, lub /review <branch> do celowania w konkretny remote. To prewencyjny atak na "nitpicks", które zwykle zapychają wątki review.
Pokrycie issue. /review <issue-url> --issue-coverage waliduje, że twoje lokalne zmiany faktycznie adresują to, o co prosi GitHub issue. To jest tryb, o którym programiści mówią nam, że nie zdawali sobie sprawy, że chcą, dopóki go nie wypróbowali. Wyniki pojawiają się w dedykowanym panelu, więc możesz je przejrzeć i zdecydować się naprawić je z Bobem. To sprawdzenie poprawności, które potwierdza, że nie tylko napisałeś dobry kod, ale właściwy kod.

1.4. Literate coding: intencja, napisana obok kodu

Gdy jesteś głęboko w złożonej funkcji, odwoływanie się do wielu plików w oknie czatu to harówka. Znajdujesz się wpisując "Spójrz na interfejs w types.ts i serwis w api.ts, następnie zaktualizuj logikę tutaj..." Bob odwraca tę dynamikę. Przenosząc interakcję bezpośrednio do pliku źródłowego poprzez Literate Coding, sam edytor staje się interfejsem. To nie chodzi tylko o unikanie panelu bocznego; chodzi o dostarczenie AI wyrafinowanej, wieloplikowej mapy twojej intencji.

Wyrażaj Intencję Naturalnie: Przełącz tryb za pomocą Cmd+M i napisz swoją logikę w prostym języku lub pseudokodzie. Twoje instrukcje pojawiają się w edytorze na niebiesko, żyjąc dokładnie tam, gdzie należy implementacja.
Poza Pojedynczą Linią: Podczas gdy tradycyjny czat często traci "wątek" złożonego projektu, literate coding Boba ewoluuje, aby wypełnić lukę między plikami. Programiści mogą teraz dostarczać kontekst w wielu modułach, zapewniając, że zmiana w modelu danych jest dokładnie odzwierciedlona w powiązanym kontrolerze.
Natychmiastowa Weryfikacja: Naciśnij Cmd+Enter, a Bob generuje implementację in-place. Ponieważ wynik jest pokazywany jako inline diff, możesz audytować logikę względem otaczającego kodu przed zatwierdzeniem zmiany.

Korzyść jest prosta: prompt żyje tam, gdzie żyje kod, z otaczającym plikiem już służącym jako kontekst. Obecny zakres to single-file; wsparcie multi-file jest na roadmap.

1.5. Bob w terminalu

Bob Shell przynosi możliwości Boba do linii poleceń, i są dwa sposoby jego używania, które uważamy za szczególnie wartościowe.

Terminal jako Workspace: Praca z AI development assistant wewnątrz shella wyłoniła się jako popularny form factor sam w sobie — naturalnie łączy się z tym, jak wielu programistów już steruje Git, buildami i testami, i stał się częścią codziennego przepływu pracy dla wielu zespołów. To najbardziej niezawodny sposób na przyniesienie AI do zdalnych serwerów lub środowisk, gdzie natywna integracja IDE nie jest dostępna: Gdziekolwiek masz terminal, możesz mieć Boba.
Od Deterministycznego do Adaptacyjnej Automatyzacji: Bob Shell świeci w sesjach nieinteraktywnych, takich jak zaplanowane zadania i skrypty wdrożeniowe w pipeline'ach CI/CD. Gdziekolwiek skrypt dzisiaj deleguje do deterministycznego narzędzia, może delegować do Boba z pełnym kontekstem otaczającego repozytorium — a automatyzacja, która wychodzi z drugiej strony, jest bardziej adaptacyjna niż stały pipeline.

Opublikujemy post kontynuacyjny o tym, czego nauczyliśmy się uruchamiając Boba nieinteraktywnie w CI: wzorce, które działają dobrze w praktyce, w tym podsumowania PR, flagowanie ryzyka i integracja z istniejącą automatyzacją.

2. Przygotuj swoje repozytorium na Boba

Repozytoria, w których Bob produkuje swoją najlepszą pracę, dzielą kilka wspólnych cech. Żadna z nich nie jest specyficzna dla AI — są to te same rzeczy, które sprawiają, że repozytorium jest przyjemne do pracy dla każdego programisty — ale każda z nich daje Bobowi więcej do pracy.

Szybkie, niezawodne testy. Jeśli npm test (lub twój odpowiednik) zajmuje pięć minut lub zawodzi sporadycznie, pętla iteracji zwalnia do pełzania, a sygnał feedbacku degraduje. Testy poniżej minuty są mnożnikiem dla każdego programisty; dla asystenta AI pracującego w ciasnych cyklach są niezbędne.

Udokumentowane polecenia build i test. Makefile, sekcja scripts najwyższego poziomu w package.json, lub blok README — gdzieś Bob może znaleźć "jak to uruchomić". Bez tego Bob musi wnioskować, a wnioskowanie jest miejscem, gdzie wchodzą błędy.

Wykonywalny styl. Lintery i formattery, które działają przy zapisie lub w CI. Bob pobiera twoje konwencje z nich. Jawne, maszynowo sprawdzalne reguły przewyższają niejawne konwencje za każdym razem.

agents.md w katalogu głównym repozytorium. Struktura projektu, kluczowe pliki, standardy kodowania, co robić i czego nie robić. To jest pojedynczy plik o najwyższej dźwigni, który możesz dodać dla pomocy AI. Właściwym sposobem myślenia o nim jest jako o CONTRIBUTING.md napisanym dla LLM, a nie dla nowego pracownika.

Dokumentacja architektury w markdown, obok kodu. Nawet krótkie dokumenty pomagają. docs/architecture.md, który opisuje moduły i ich granice, pozwala Bobowi odpowiedzieć "gdzie to idzie?" bez ponownego wyprowadzania projektu z importów.

Kilka rzeczy, których nauczyliśmy się po drodze:

Duże pliki reguł redukują sygnał. Po kilkuset liniach wydajność modelu degraduje. Podziel reguły według obszaru — agents.md w katalogu głównym repozytorium, scoped readme.md na pakiet — zamiast koncentrować wszystko w jednym pliku.
Komponuj swoją inżynierię. Gdy kończysz zadanie, poproś Boba o destylację odpowiednich nauk z powrotem do pliku reguł lub do umiejętności. Repozytorium staje się bardziej produktywnym środowiskiem w miarę jego używania.
Iteruj, nie rób one-shot. Wieloturowa konwersacja, która konsekwentnie ląduje właściwą zmianą, przewyższa pojedynczy długi prompt, który ląduje osiemdziesiąt procent z niej.

3. Bezpieczeństwo i kontrola

Bob ma kilka warstw ochrony, które współpracują, zamiast pojedynczego guardrail wykonującego całą pracę. Krótka wersja, odpowiednia dla pierwszego posta:

Zatwierdzaj ręcznie każdą akcję lub auto-zatwierdzaj według klasy narzędzia (tylko odczyt versus zapis), gdy zaufasz przepływowi pracy.
.bobignore trzyma Boba z dala od plików, których nie powinien czytać — poświadczenia, wygenerowane artefakty, cokolwiek wrażliwego.
Niestandardowe reguły egzekwują standardy kodowania na Bobie w ten sam sposób, w jaki egzekwują je na programistach.
Automatyczne punkty kontrolne sprawiają, że odzyskiwanie z niepożądanej zmiany jest akcją jednego kliknięcia.
Twoje prompty nie są używane jako dane treningowe!

Auto-zatwierdzanie, w szczególności, warto być świadomym. To jedna z głównych kontroli, które masz nad tym, ile Bob może zrobić między punktami kontrolnymi z tobą, a jej poszerzenie jest zyskiem produktywności, który również wymaga od ciebie trochę więcej w decydowaniu, co mieści się w tej kopercie, a co nie. Rozsądnym domyślnym dla większości programistów jest auto-zatwierdzanie narzędzi tylko do odczytu, pozostawienie akcji zapisu na ręcznym zatwierdzaniu przez co najmniej pierwsze kilka tygodni i bycie szczególnie rozważnym z czymkolwiek, co uruchamia polecenia shell lub sięga systemów poza twoje lokalne drzewo robocze. Inne kontrole na liście — .bobignore, niestandardowe reguły, punkty kontrolne — są zaprojektowane do komponowania z auto-zatwierdzaniem, a nie zastępowania go.

4. Rozpocznij

Zainstaluj IBM Bob z naszej strony internetowej lub zainstaluj Bob Shell przez swój terminal wyboru.
Przejrzyj nasz przewodnik najlepszych praktyk i zapoznaj się z naszymi wytycznymi bezpieczeństwa.
Zacznij od prawdziwego zadania — Uczysz się najlepiej, gdy Bob pomaga w rzeczywistych problemach.

Linki