Por que agentes de codificação de IA precisam de uma espinha de tarefas

Eu tenho programado em par com Claude desde o primeiro dia — muito antes de Claude Code existir, antes de MCP existir, quando "assistente de codificação AI" ainda significava conclusão de tabulação. A configuração ficou razoavelmente boa. Então eu percebi que continuava reexplicando as mesmas coisas.

Eu, terça-feira: "Escolhemos Postgres para este projeto, não MongoDB. Use JSONB para a coluna de metadados."

Eu, sexta-feira: "Escolhemos Postgres para este projeto, não MongoDB. Use JSONB para a coluna de metadados."

Eu, segunda-feira: "Espere, por que você sugeriu MongoDB?"

O agente é brilhante em qualquer sessão única. Ao longo das sessões, ele tem a memória de um peixe dourado. Cada conversa começa do zero. Cada decisão que pensei que já tínhamos resolvido precisa ser reavaliada.

Se você também já passou por isso, este post é para você.

A forma do problema

Três coisas que deveriam persistir entre as sessões do agente, e não persistem:

1. Em que estamos trabalhando? A lista de tarefas. Seu status. Quem reivindicou qual (você? o agente? um agente diferente no outro laptop?).

2. O que decidimos? As escolhas arquitetônicas / de biblioteca / de padrão que já fizemos — e por que. Não para que o agente possa repeti-las; para que ele possa construir sobre elas em vez de reavaliar.

3. O que já tentamos? Os becos sem saída. As percepções de "já tentamos isso e a razão pela qual não funcionou foi X" que são as mais caras de rederivar.

A memória de chamadas de ferramentas dentro de uma única sessão é ótima. A recuperação vetorial sobre seu código é ótima. Nenhuma das duas resolve o estado do projeto.

As soluções ingênuas que não funcionam

Um README. Eu tentei. O agente nem sempre o lê. Quando lê, não consegue atualizá-lo sem sobrescrever sua formatação. Quando dois agentes o editam simultaneamente, você tem conflitos.

Um quadro Notion / Linear / Jira. O agente pode chamar sua API se você configurar a integração. Mas: é lento (cada leitura é uma viagem de rede), é barulhento (atrasos de sincronização), e o esquema não se encaixa no que os agentes realmente se importam (você não precisa de um Kanban com atribuições e planejamento de sprints; você precisa de "esta tarefa está concluída? o que está bloqueando? que decisões tocam este caminho de código?").

Arquivos Markdown em .claude/ ou .cursor/. Mais próximo. Agora os dados estão locais. Mas é texto simples — sem consultas, sem FTS, sem relações.

O que eu realmente queria

Três coisas, nenhuma das quais existia:

1. Um servidor MCP que o agente pode chamar para reivindicar/concluir tarefas, registrar decisões, registrar becos sem saída e recuperar qualquer um deles depois — sem sair da conversa.

2. Um armazenamento local SQLite que mantém tudo isso. Consultas. FTS. Barato.

3. Um painel que posso abrir no navegador para ver em que estado o projeto está, quais decisões estão pendentes, o que o agente está fazendo agora. Apenas olhe para ele — não preciso perguntar ao agente.

Então eu construí. Chama-se Shinobi. É um único CLI:

npm install -g @shinobiapps/shinobi
cd /seu/projeto
shinobi init
shinobi dashboard

init coloca um .mcp.json no diretório atual que aponta para o servidor local Shinobi MCP. Reinicie Claude Code (ou Cursor) e ele carrega automaticamente create_project, claim_task, log_decision, recall, e amigos.

Agora, da próxima vez que eu começar uma sessão:

> Leia o contexto do projeto. Em que estamos trabalhando?

[claude chama recall, lê a espinha do projeto, lê o registro de decisões]

Estamos construindo o fluxo de autenticação para $project. Decisões registradas:
- 2026-06-12: Postgres + JSONB para metadados de sessão (não MongoDB —
  devido à restrição de que o resto do aplicativo já usa Postgres)
- 2026-06-14: NextAuth.js em vez de desenvolver o nosso próprio (configuração de 3 linhas vs.
  semanas de correção de cookies/CSRF)

Becos sem saída descartados:
- 2026-06-13: Tentamos passar sessões como strings de consulta de URL; foi
  sinalizado pela regra de linting e quebra o compartilhamento de favoritos.

Próxima tarefa: subtarefa #7, "conectar o callback OAuth". Quer que eu a reivindique?

Sim. Sim, eu quero. E já economizamos dez minutos de "lembra quando decidimos...".

Por que isso importa mais do que parece

O gargalo no desenvolvimento assistido por IA é não a esperteza de turno único do modelo. O modelo já é mais inteligente do que precisa ser para 90% das tarefas. O gargalo é obter o contexto certo na frente dele sem que você, o humano, se torne o gargalo.

Um README é um registro de chat. Uma espinha de tarefas é um banco de dados. O agente pode ler, escrever e consultar um banco de dados sem você digitando. Essa é a chave.

O que vem a seguir nesta série

• Parte 2: Aprovações de push móvel — como request_approval permite que você se afaste do laptop enquanto o agente executa e responda pelo seu telefone quando ele atinge uma bifurcação.

• Parte 3: Sincronização em tempo real de múltiplos agentes — desktop e laptop, ou você e um colega, trabalhando no mesmo espaço de trabalho sem puxar manualmente do git.

• Parte 4: Por que os dados permanecem locais (SQLite + sincronização git opcional) e o que o SaaS hospedado adiciona em cima — a promessa explícita de "sem bloqueio".

Se você quiser experimentar o Shinobi agora: https://github.com/numbererikson/shinobi. Licença MIT, auto-hospedado para sempre.