DEV Community: Tiago Vilas Boas (Montanha)

Indexar o código fora do repo: como economizar tokens sem jogar o projeto no contexto

Tiago Vilas Boas (Montanha) — Thu, 27 Aug 2026 18:41:59 +0000

Pessoal, o agent precisava achar um símbolo. Trabalho de um minuto. Na prática, ele abria arquivo atrás de arquivo, colava dump de teste no papo e a janela sumia. Às vezes a fatura também.

Não era o modelo burro. Era eu pagando o monorepo inteiro pra responder a pergunta errada.

A pergunta mudou. Deixei de ser “qual tool faz o agent entender o repo?” e virei: o que é memória de domínio, e o que é só custo de ler código nesta sessão?

Tem um segundo motivo, e ele não é economia. Um índice de símbolos é um mapa do seu sistema: quem chama o quê, onde está o fluxo crítico. Se esse mapa mora no git, no cache de CI ou num serviço que o agent também escreve, o blast radius não é só token. É superfície.

Duas contas, um prompt

Memória de domínio é política. O que pode ser lembrado, por qual porta se entra, o que é canônico. Notas, contratos, “onde a gente decide X”. Indexer de código não resolve isso.

Code-read barato é custo de sessão. Achar caller e símbolo sem despejar o working tree no prompt. Isso não deveria virar a sua base de conhecimento.

Eu misturava. O indexer virava KB. O vault virava grep sem porta. Os dois falhavam, e a sessão inchava igual.

Economizar token aqui não é trocar de modelo da semana. É separar camada. E decidir onde o mapa vive.

O que eu mudei na mesa

O mapa de símbolos saiu do working tree. Cache local, fora do repo, fora do git. Reindex é operação de máquina, não de PR. O agent consulta o índice; não precisa reler o monorepo pra “quem chama essa função?”.

Quatro perguntas que eu faço antes de indexar um repo (vale colar no README do setup):

O índice vive na minha máquina ou sai dela (cloud, CI, cache compartilhado)?
Entra em contexto de agent que também tem tool de escrita?
Como eu apago e revogo?
Quem mais lê isso?

Índice ≠ fonte de verdade versionada. Least privilege no que entra no contexto continua valendo.

Depois, parei de mandar firehose de CLI cru. test, build, git status viram novela. Aquilo no contexto é fogo amigo. Output barulhento: comprimo com um wrapper de CLI, ou faço Read cirúrgico. Incidente que precisa da linha exata do log: aí sim firehose.

Por último: um code-read por sessão. Empilhar dois indexers dilui ROI e confunde o agent. Escolhe um. Se não servir, troca. Não some.

Índice também envelhece. Sintoma: o agent cita símbolo que não existe mais, com confiança. Aí reindexa. Sem isso, você só mudou o tipo de alucinação.

O que isso ainda não é

Isso não substitui contrato de memória. Hubs, scopes, “não responda só com grep” são outra conversa.

E uma honestidade: eu não tenho “economizei X% de tokens”. Sem medição, sem %. O que eu tenho é sessão menos inchada e um mapa que não vai parar no PR por acidente.

Artefato

## Token layers (coding agent)

1. Memória de domínio tem dono próprio. Indexer não é KB.
2. Índice de símbolos: fora do repo, fora do git.
3. Antes de indexar: onde vive, quem lê, o agent escreve, como revoga.
4. Um code-read por sessão. Não empilhe indexers.
5. CLI barulhento: comprime ou lê o trecho. Firehose só se a linha importa.
6. Índice velho: reindexa quando o agent citar o que não existe mais.

Regra de bolso: se a sessão está cara e você não sabe qual camada inchou, nomeie a camada antes de plugar mais tool.

Pergunta pra comunidade

No seu setup o índice é local (reindex chato, mapa em casa) ou hospedado (mais rápido, mapa fora da sua máquina)?

O que você não abre mão — e o que você cortaria primeiro: índice, dump de CLI, ou memória misturada com code-read?

Ownership não é o PR. É não deixar o problema só na sua cabeça

Tiago Vilas Boas (Montanha) — Thu, 27 Aug 2026 18:01:31 +0000

Pessoal, tem um padrão que eu vi demais em time que já sabe entregar.

O erro está no board de observabilidade há meses. Alguém já comentou no canal. Suporte eventualmente reclama. Nunca virou card. Um dia vira incidente.

Aí a pergunta aparece, desconfortável: de quem era a responsabilidade?

Eu costumava responder errado. Ownership, pra mim, era pegar o código. Se eu vi, eu conserto. Ou o contrário: se não tem task, não é comigo.

Os dois lados quebram o time. Um vira herói e gargalo. O outro normaliza o problema até ele explodir.

O que mudou foi uma distinção chata e útil: ver um problema não te obriga a implementá-lo. Obriga você a não fingir que não viu.

Quatro posturas (nenhuma é “errada” sozinha)

O salto não é de júnior pra Staff. É de pergunta.

Postura	Pergunta que guia	Sinal
Task	“Está done?”	Fecha o card sem olhar comportamento em produção
Delivery	“Está em produção?”	Acompanha o deploy, não o resultado
Outcome	“Resolveu o problema do usuário?”	Olha métrica depois do merge
Ownership	“O que mais está errado aqui?”	Percebe o adjacente sem esperar task

O problema não é alguém estar em task. É o time inteiro parar ali e ninguém carregar visão de sistema.

See it, own it — o que isso não é

Não é: “vi, então agora é minha sprint.”

É: “vi, então sou responsável por isso existir fora da minha cabeça.”

Na prática eu uso quatro passos. Nomes feios de propósito, pra não virar poster.

SEE          percebi algo estranho
UNDERSTAND   isso importa? recorrente? quem se ferrar?
EXPOSE       o problema precisa de dado, não de feeling
OWN          existe decisão ou dono — mesmo que a decisão seja “aceitamos o risco”

OWN não significa CODE.

Pode ser um card com contexto de verdade. Uma conversa com quem prioriza. Um parágrafo escrito. Uma investigação com prazo. Inclusive: “vamos conviver com isso por enquanto” — desde que isso seja decisão, não esquecimento.

Se ownership virar “quem viu implementa”, o Senior/TL vira o único adulto da sala. Isso não escala. E queima gente boa.

A heurística que muda a conversa

“Corrigimos um bug” é output.

O que costuma destravar priorização é outra frase:

Problema → evidência → impacto → ação → (depois) resultado.

Exemplo sintético, de propósito:

Uma API crítica seguia respondendo 200. Em três semanas o P95 foi de ~400 ms para quase 2 s. Ninguém tinha aberto incidente porque “ainda funciona”. Alguém colocou o gráfico no canal e perguntou o que tinha mudado. Aí deixou de ser feeling.

Sem número, o problema compete com o backlog e perde. Com número, ele vira escolha consciente.

DORA coloca o dedo nisso há anos: time de alto desempenho não é só o que mergeia rápido. É o que detecta e responde. Achar tarde custa mais — a indústria de qualidade (incluindo trabalhos associados ao NIST) repete isso em variações. O ponto prático pra mim não é o fator exato. É que “ainda está 200” não é saúde.

O que eu não estou pedindo

Ownership não é:

resolver tudo que passar na sua timeline;
furar priorização porque você ficou inquieto;
trabalhar fora do horário pra “provar” que é dono;
caçar culpado no post-mortem.

Se o framework criar ansiedade, ele falhou. O objetivo é sistema mais saudável, não indivíduo exausto.

Artefato: três perguntas, três saídas

Dá pra usar numa retro, num 1:1 ou sozinho no fim da semana.

Que problema você viu nas últimas duas semanas que ninguém está tratando?
Se continuar um mês, o que piora (usuário, on-call, lead time)?
Quem deveria ser o owner — ou quem decide que não tem owner agora?

Cada item sai com um status, sem teatro:

ignorar com consciência (risco aceito, data pra rever);
investigar (hipótese + evidência);
abrir card (com as duas linhas de cima, não “olhar depois”).

Se a mesma coisa aparecer toda quinzena, o problema não é o card. É o sistema que ensinou o time a esperar o card.

A frase que eu deixei no material interno, e que ainda seguro em público:

Seu trabalho não termina quando o código funciona. Termina quando o problema deixa de existir — ou quando você garante que alguém é responsável por fazê-lo deixar de existir.

Onde o seu time para?

Não preciso do seu pior incidente. Quero a postura.

No último problema chato que todo mundo já via: vocês ignoraram com consciência, investigaram ou abriram card? E o que impediu a opção que vocês não escolheram?

Referências

O framework SEE → UNDERSTAND → EXPOSE → OWN e a distinção OWN ≠ CODE são síntese minha. Os links abaixo são o contexto público que usei pra amarrar “detectar tarde custa” e “entrega ≠ resultado”:

Accelerate State of DevOps Report 2023 (DORA)
DORA — capacidades e four keys
NIST — The Economic Impacts of Inadequate Infrastructure for Software Testing (2002; o “quanto mais tarde, mais caro” que o mercado cita)
Stripe — The Developer Coefficient (tempo gasto em legado / débito; leitura complementar)

Por que um Staff Engineer está estudando AI Security

Tiago Vilas Boas (Montanha) — Mon, 03 Aug 2026 07:15:17 +0000

Pessoal, deixa eu ser sincero desde o começo.

Eu não estou escrevendo isto como expert em AI Security. Estou escrevendo no ponto em que a pergunta do meu trabalho mudou.

Eu passo o dia em cima de sistema sob pressão: confiabilidade, observabilidade, incidente, decisão que precisa continuar fazendo sentido quando eu saio da sala. Nos últimos tempos, passei a operar de verdade com LLM, agente, MCP e memória/RAG.

Nos últimos meses, percebi que eu já estava ajudando times a acelerar uso de agentes, MCPs e automações, mas ainda não tinha a mesma segurança pra revisar permissões, superfícies de ataque e fluxo de dados. Eu sabia avaliar arquitetura e operação; precisava ampliar essa lente pra segurança de sistemas agentic.

Aí a pergunta na minha cabeça virou outra.

Antes:

Como eu faço esse agente entregar mais rápido?

Agora:

Se esse agente tem ferramenta, o que ele pode quebrar, e quem assume o risco?

É sobre isso que eu quero estudar em público. Com uma trava de bolso que você já pode usar amanhã.

O reflexo chato (e útil) do Staff

Staff, pra mim, nunca foi aparecer em tudo.

Foi construir condições para que as squads tomem boas decisões sem depender da minha memória.

Isso cria um reflexo meio chato: olhar pra demo bonita e perguntar pelo modo de falha.

O webhook falha como?
O retry duplica o quê?
Essa métrica explica impacto ou só joga stacktrace na tela?
Tem kill switch ou a gente só torce?

Agora esse mesmo reflexo precisa olhar pra prompt, ferramenta, memória e permissão de agente. Não porque eu mudei de carreira da noite pro dia. Porque a unidade de risco mudou.

Texto errado é uma coisa. Ação indevida é outra.

Quando o modelo só gera texto, o estrago costuma ser contido: chato, caro às vezes, mas contido: alucinação, vazamento por descuido, resposta ruim.

Quando o mesmo modelo ganha ferramenta: ler arquivo, chamar API, abrir PR, mexer em dado, acionar automation, o jogo muda.

Aí o risco deixa de ser só “falou besteira”. Passa a ser:

fez uma ação irreversível com confiança alta demais;
tinha permissão bem maior do que o trabalho pedia;
puxou pro contexto uma informação que não deveria sair dali;
conectou um MCP/skill poderoso sem auditoria decente.

Isso não é paranoia de blog. É o tipo de coisa que a indústria já tenta organizar em mapa público. Eu uso como âncora de estudo:

A leitura de Staff que eu carrego é bem direta:

Acelerar agente sem olhar permissão é otimizar velocidade com o cinto solto.

Um cenário sintético (pra ficar concreto)

Imagina um agente de coding com:

shell no repo;
token de API “amplo pra não travar”;
memória/RAG misturando nota interna com contexto do ticket.

Você pede: “limpa os arquivos temporários da pasta de build”.

O modelo interpreta “temporários” com generosidade demais. Sem allowlist de path, sem dry-run, sem confirmação humana pra rm… ele pode ir bem além do que você imaginou.

Isso não é case de empresa. É um exemplo sintético do tipo de falha que aparece quando a gente otimiza fluidez e esquece freio.

Se eu tivesse passado o checklist abaixo antes de dar shell + token amplo, pelo menos três perguntas teriam travado o desenho: ação irreversível, menor escopo, e o que impede o dano se a intenção for alucinada.

Artefato: 7 perguntas antes de dar ferramenta a um agente

Copia, cola no PR da automação, e não segue em frente sem responder.

## Tool access gate (agente)

1. Qual é a ação irreversível mais cara que essa tool permite?
   (apagar, pagar, publicar, exfiltrar, merge, deploy)
2. Qual é o menor escopo de permissão que ainda resolve o trabalho?
3. O agente precisa de escrita, ou leitura bastaria na maior parte do tempo?
4. O que entra no contexto (RAG/memória) que não deveria sair dali?
5. Como eu detecto abuso ou erro? (log, audit trail, alerta, dry-run)
6. Qual é o kill switch? (revogar token, desligar tool, pausar automation)
7. Se o modelo alucinar a intenção, o que ainda impede o dano?
   (allowlist, HITL, confirmação humana, sandbox)

No fundo, as sete perguntas tentam aplicar princípios antigos: menor privilégio, redução de blast radius, auditabilidade e defesa em profundidade a uma interface nova: o agente. Capability boundaries e human-in-the-loop entram aí sem drama.

Regra de bolso:

Se alguma resposta ficar vaga, a tool não entra no agente.

É a trava mínima pra gente não confundir produtividade com negligência.

O que vem a seguir

Este é o primeiro texto da minha jornada pública em AI Security. Nos próximos, quero documentar labs, threat models de agentes, MCPs, RAG, permissões e os erros que aparecerem no caminho.

Filtro pessoal que eu tô usando:

Isso me aproxima de ser alguém confiável em arquitetura segura de agentes, ou só me distrai com ferramenta nova?

Privacidade e anonimização vêm antes da vontade de postar rápido. Se você é forte em engenharia, cético com hype e curioso com risco de agente, essa conversa é pra gente.

Pergunta pra comunidade

Você já viu um agente receber mais permissão do que precisava? O que colocaria como primeira trava: allowlist, sandbox, aprovação humana ou token restrito?

Se tiver um caso concreto, ainda melhor: o que a tool podia fazer e qual guarda você colocou depois. 🤝