Este é o primeiro post no blog do Bob. É escrito pela equipe que está construindo o Bob, para os desenvolvedores que o usam. Vamos usá-lo para explicar decisões de engenharia, compartilhar o que aprendemos ao entregar um parceiro de desenvolvimento de IA dentro de bases de código reais, e ocasionalmente argumentar uma posição. Não é documentação e não é marketing — se você quiser qualquer um dos dois, vamos direcioná-lo para o lugar certo.

Para nosso primeiro post, em vez de percorrer tudo o que o Bob faz, queremos fazer três coisas:

Olhar para algumas das capacidades centrais do Bob.
Compartilhar um conjunto de dicas práticas para configurar um repositório para que o Bob faça seu melhor trabalho.
Explicar como abordamos a segurança em uma ferramenta que tem esse tipo de acesso ao seu código.

1. No que os desenvolvedores realmente gastam seu tempo

Um assistente de IA moderno pode escrever uma função a partir de uma descrição. Isso é verdade há algum tempo, e não é mais a questão interessante. A questão interessante é o que acontece quando o trabalho não é "produzir novo código", mas "modificar um sistema que já existe" — encontrar o lugar certo para fazer uma mudança, entender as convenções em que uma equipe se estabeleceu, manter o comportamento consistente em arquivos que vêm crescendo há anos. É assim que se parece a maior parte do desenvolvimento de software profissional. Bob é construído para esse tipo de trabalho, e as escolhas de design que descrevemos no resto deste post seguem desse foco.

1.1. Modos: dizendo ao Bob que tipo de trabalho você está fazendo

Bob não é uma única interação "faça algo útil". O modo em que você inicia uma sessão diz ao Bob que tipo de trabalho você está prestes a fazer, quais ferramentas ele pode alcançar e quão proativo ele deve ser.

Ask — somente leitura. Perfeito para a "fase de exploração". Bob explica arquitetura e lógica sem fazer mudanças. Use isso ao mergulhar em um sistema legado ou realizar uma verificação de sanidade em um pedaço de lógica que você não escreveu.
Plan — Bob produz um plano para uma mudança que você está prestes a fazer: arquivos a tocar, casos extremos a considerar, ordem sugerida de trabalho. A saída é um plano, não código.
Code — para realmente fazer mudanças. Bob lê, escreve e testa dentro do seu projeto, seguindo as convenções e regras que você definiu.
Advanced — estende o modo Code através do Model Context Protocol (MCP), dando ao Bob acesso às ferramentas e serviços específicos da sua organização: APIs internas, bancos de dados, ferramentas proprietárias.
Orchestrator — para trabalho de múltiplas etapas que cruza modos. Bob alterna entre modos por si mesmo com base no que a etapa atual exige, e é a escolha certa para pedaços maiores de trabalho que misturam exploração, planejamento e execução.

Escolher o modo certo no início de uma sessão é uma das alavancas mais baratas disponíveis para obter melhor saída. Um bom hábito, particularmente em uma base de código que você não conhece bem ou para uma mudança com qualquer área de superfície real, é começar em Ask ou Plan e só mudar para Code uma vez que você tenha uma imagem clara do trabalho. Ir direto para Code parece mais rápido no momento, mas é aí que as suposições tendem a escorregar como mudanças reais e começam a se acumular como dívida técnica.

1.2. Bob tips: métricas de complexidade, em tempo real

Todos nós já estivemos lá: você está profundo na "zona", aninhando um último condicional para lidar com um caso extremo, e de repente uma única função cresceu para um labirinto de trinta linhas. Em um fluxo de trabalho típico, esse labirinto não é desembaraçado até que um colega de equipe aponte isso em um pull request horas depois. Bob Tips muda a narrativa ao oferecer uma proposta de refatoração enquanto a lógica ainda está fresca em sua mente. Enquanto você digita, a análise estática contínua monitora silenciosamente seus arquivos abertos. Quando uma função cruza a linha para alta complexidade ciclomática ou se torna difícil de manter, Bob imediatamente a sinaliza com um sublinhado roxo. Um linter tradicional apenas diz que você fez algo errado; Bob Tips fornece a saída. O foco da ferramenta está inteiramente em fornecer propostas de refatoração acionáveis:

Inteligência Contextual: Passar o mouse sobre o sublinhado roxo não apenas exibe um aviso—oferece uma estratégia específica gerada por IA para desembaraçar a lógica ali mesmo. Execução Perfeita: Clicar em Fix with Bob abre instantaneamente um chat dedicado. A IA já possui o contexto da função e está pronta para executar a limpeza ao seu lado.

As métricas rodando em segundo plano são apenas o encanamento. A parte valiosa é que um sinal de qualidade de código de longa data agora impulsiona uma sugestão de IA no momento em que o desenvolvedor está no arquivo, em vez de surgir em uma revisão de código três dias depois.

1.3. Modo Review: revisão de código, com o sistema lendo junto

A revisão de código fez tanto pela qualidade do software quanto qualquer prática nas últimas duas décadas, e também é onde as equipes perdem impulso. Bob não substitui a revisão humana. Ele faz as partes que são mecânicas, para que possam se concentrar em arquitetura de alto nível e intenção em vez de caçar bugs "fáceis".

As revisões são executadas a partir do Review Panel na barra lateral ou via /review no chat. Existem dois modos:

Comparação de branch. Este modo lida com o diff "clássico". Use /review para auditar trabalho não commitado contra seu head atual, ou /review <branch> para mirar em um remote específico. É um ataque preventivo contra os "nitpicks" que geralmente entopem threads de revisão.
Cobertura de issue. /review <issue-url> --issue-coverage valida que suas mudanças locais realmente abordam o que uma issue do GitHub pede. Este é o modo que os desenvolvedores nos dizem que não perceberam que queriam até experimentarem. Os achados aparecem em um painel dedicado, para que você possa revisá-los e decidir corrigi-los com Bob. É uma verificação de sanidade que confirma que você não apenas escreveu bom código, mas o código certo.

1.4. Literate coding: intenção, escrita ao lado do código

Quando você está profundo em um recurso complexo, referenciar múltiplos arquivos em uma janela de chat é uma tarefa árdua. Você se encontra digitando "Olhe a interface em types.ts e o serviço em api.ts, depois atualize a lógica aqui..." Bob inverte essa dinâmica. Ao mover a interação diretamente para o arquivo fonte através do Literate Coding, o próprio editor se torna a interface. Isso não é apenas sobre evitar um painel lateral; é sobre fornecer à IA um mapa sofisticado de múltiplos arquivos da sua intenção.

Expresse Intenção Naturalmente: Alterne o modo com Cmd+M e escreva sua lógica em linguagem simples ou pseudocódigo. Suas instruções aparecem no editor em azul, vivendo exatamente onde a implementação pertence.
Além da Linha Única: Enquanto o chat tradicional frequentemente perde o "fio" de um projeto complexo, o literate coding do Bob está evoluindo para preencher a lacuna entre arquivos. Os desenvolvedores agora podem fornecer contexto através de múltiplos módulos, garantindo que uma mudança em um modelo de dados seja refletida com precisão no controlador associado.
Verificação Imediata: Pressione Cmd+Enter e Bob gera a implementação no local. Como o resultado é mostrado como um diff inline, você pode auditar a lógica contra o código circundante antes de se comprometer com a mudança.

O benefício é direto: o prompt vive onde o código vive, com o arquivo circundante já servindo como contexto. O escopo atual é de arquivo único; suporte multi-arquivo está no roadmap.

1.5. Bob no terminal

Bob Shell traz as capacidades do Bob para a linha de comando, e há duas maneiras de usá-lo que achamos particularmente valiosas.

O Terminal como Espaço de Trabalho: Trabalhar com um assistente de desenvolvimento de IA dentro do shell emergiu como um fator de forma popular por si só — combina naturalmente com como muitos desenvolvedores já conduzem Git, builds e testes, e se tornou parte do fluxo de trabalho diário para muitas equipes. É a maneira mais confiável de trazer IA para servidores remotos ou ambientes onde uma integração IDE nativa não está disponível: Onde quer que você tenha um terminal, você pode ter Bob.
De Determinístico para Automação Adaptativa: Bob Shell brilha em sessões não interativas como trabalhos agendados e scripts de implantação em pipelines CI/CD. Onde quer que um script hoje delegue para uma ferramenta determinística, ele pode delegar para Bob com contexto completo do repositório circundante — e a automação que sai do outro lado é mais adaptativa do que um pipeline fixo.

Vamos publicar um post de acompanhamento sobre o que aprendemos executando Bob de forma não interativa em CI: os padrões que funcionam bem na prática, incluindo resumos de PR, sinalização de riscos e integração em automação existente.

2. Torne seu repositório Bob-ready

Os repositórios onde Bob produz seu melhor trabalho compartilham alguns traços em comum. Nenhum deles é específico de IA — são as mesmas coisas que tornam um repositório agradável de trabalhar para qualquer desenvolvedor — mas cada um deles dá ao Bob mais com que trabalhar.

Testes rápidos e confiáveis. Se npm test (ou seu equivalente) leva cinco minutos ou falha intermitentemente, o loop de iteração desacelera para um rastejamento e o sinal de feedback degrada. Testes abaixo de um minuto são um multiplicador para qualquer desenvolvedor; para um assistente de IA trabalhando em ciclos apertados, eles são essenciais.

Comandos de build e teste documentados. Um Makefile, uma seção de scripts de nível superior em package.json, ou um bloco README — em algum lugar Bob pode encontrar "como eu executo isso". Sem isso, Bob tem que inferir, e inferência é onde os erros entram.

Estilo executável. Linters e formatadores que rodam ao salvar ou em CI. Bob pega suas convenções destes. Regras explícitas e verificáveis por máquina superam convenções implícitas toda vez.

Um agents.md na raiz do repositório. Estrutura do projeto, arquivos-chave, padrões de codificação, o que fazer e o que não fazer. Este é o arquivo de maior alavancagem que você pode adicionar para assistência de IA. A maneira certa de pensar sobre isso é como um CONTRIBUTING.md escrito para um LLM em vez de para um novo contratado.

Documentação de arquitetura em markdown, ao lado do código. Até documentos curtos ajudam. Um docs/architecture.md que descreve módulos e seus limites permite que Bob responda "onde isso vai?" sem re-derivar o design de imports.

Algumas coisas que aprendemos ao longo do caminho:

Arquivos de regras grandes reduzem o sinal. Passando algumas centenas de linhas, o desempenho do modelo degrada. Divida regras por área — agents.md na raiz do repositório, readme.md com escopo por pacote — em vez de concentrar tudo em um arquivo.
Componha sua engenharia. Quando você terminar uma tarefa, peça ao Bob para destilar os aprendizados relevantes de volta para o arquivo de regras ou em uma habilidade. O repositório se torna um ambiente mais produtivo à medida que você o usa.
Itere, não faça one-shot. Uma conversa de múltiplas rodadas que aterrissa a mudança certa consistentemente supera um único prompt longo que aterrissa oitenta por cento dela.

3. Segurança e controle

Bob tem várias camadas de proteção que trabalham juntas em vez de qualquer guardrail único fazendo todo o trabalho. A versão curta, adequada para um primeiro post:

Aprove manualmente cada ação, ou aprove automaticamente por classe de ferramenta (somente leitura versus escrita) uma vez que você confie no fluxo de trabalho.
.bobignore mantém Bob longe de arquivos que ele não deve ler — credenciais, artefatos gerados, qualquer coisa sensível.
Regras personalizadas aplicam padrões de codificação no Bob da mesma forma que os aplicam nos desenvolvedores.
Pontos de verificação automáticos tornam a recuperação de uma mudança indesejada uma ação de um clique.
Seus prompts não são usados como dados de treinamento!

A aprovação automática, em particular, vale a pena ser deliberado sobre. É um dos principais controles que você tem sobre quanto Bob pode fazer entre pontos de verificação com você, e ampliá-lo é um ganho de produtividade que também pede um pouco mais de você ao decidir o que cai dentro desse envelope e o que não cai. Um padrão sensato para a maioria dos desenvolvedores é aprovar automaticamente ferramentas somente leitura, deixar ações de escrita em aprovação manual por pelo menos as primeiras semanas, e ser especialmente considerado com qualquer coisa que execute comandos shell ou alcance sistemas além da sua árvore de trabalho local. Os outros controles na lista — .bobignore, regras personalizadas, pontos de verificação — são projetados para compor com aprovação automática em vez de substituí-la.

4. Começar

Instale o IBM Bob do nosso site, ou instale Bob Shell através do seu terminal de escolha.
Revise nosso guia de melhores práticas e consulte nossas diretrizes de segurança.
Comece com uma tarefa real — Você aprende melhor quando Bob está ajudando com problemas reais.

Links