Prompts Agendados do Ollama no Claude Code Transformaram Minhas Manhãs
Acordei ontem e meu terminal já tinha feito trinta minutos de trabalho por mim.
Não de um jeito sinistro, tipo Skynet. Mais tipo — abri meu laptop, mudei para minha sessão do Claude Code, e lá estava: um resumo limpo das falhas de CI durante a noite em três projetos, um digest de notícias de IA das últimas 24 horas, e um lembrete de que eu tinha prometido a um cliente uma estimativa de deploy até o meio-dia. Tudo ali, esperando, gerado enquanto eu dormia.
Eu não tinha escrito um cron job. Não tinha configurado algum workflow elaborado no n8n. Não tinha colado com fita três ferramentas SaaS com webhooks. Digitei uma linha na noite anterior — /loop Give me the latest AI news every morning — e o Ollama rodando dentro do Claude Code simplesmente... fez.
Essa é uma daquelas funcionalidades que parece pequena quando você descreve e parece enorme quando você usa. O Ollama agora pode executar prompts agendados diretamente dentro do Claude Code, e depois de uma semana construindo toda a minha rotina matinal em torno disso, estou convencido de que é assim que os ambientes de desenvolvimento vão funcionar daqui pra frente. Não como ferramentas que você pega e larga, mas como sistemas ambientais que trabalham junto com você — às vezes à sua frente.
Aqui está tudo que aprendi configurando isso, o que realmente funciona, o que ainda está cru, e por que acho que isso importa muito mais do que parece.
Como Descobri Isso (e Por Que Quase Perdi)
Eu vinha executando o Ollama localmente havia meses. Principalmente para inferência local rápida — testando prompts offline, rodando modelos menores quando não queria gastar créditos de API, esse tipo de coisa. Útil, mas nada que mudasse fundamentalmente meu fluxo de trabalho.
Aí um colega mencionou, quase de passagem, que o Ollama tinha integrado com o sistema de agendamento do Claude Code. Minha primeira reação foi ceticismo. Agendar prompts soava como um truque — algo que você demonstraria numa conferência mas nunca usaria no dia a dia.
Eu estava errado. Espetacularmente errado.
A integração funciona assim: você lança o Ollama pelo Claude Code usando ollama launch claude, que levanta uma instância do Ollama que conhece seu ambiente do Claude Code — o contexto do seu projeto, seu sistema de arquivos, seus processos em execução. Depois você usa o comando /loop para agendar prompts recorrentes que rodam nos intervalos que você definir.
Essa é a mecânica. A mágica está no que você faz com ela.
Porque uma vez que seu ambiente de desenvolvimento pode executar prompts em um cronograma — sem ser solicitado, em segundo plano, enquanto você faz outras coisas ou nem está na sua mesa — toda a relação entre você e suas ferramentas muda. Você para de pensar em IA como algo que consulta e começa a pensar nela como algo que observa, verifica e reporta. Uma camada ambiental de inteligência sobre o seu fluxo de trabalho.
Mas estou me adiantando. Deixa eu te guiar pela configuração real, porque os detalhes importam mais que o conceito.
Colocando o Ollama para Funcionar Dentro do Claude Code
O pré-requisito é direto: você precisa do Ollama instalado localmente e do Claude Code rodando no seu terminal. Se tem os dois, já está a noventa por cento do caminho.
Passo 1: Lance o Ollama pelo Claude Code.
Abra sua sessão do Claude Code e execute:
ollama launch claude
Isso não é a mesma coisa que rodar ollama serve em um terminal separado. O comando ollama launch claude cria uma ponte entre o motor de modelos local do Ollama e o framework de agentes do Claude Code. Sua instância do Ollama herda consciência de contexto — sabe em qual projeto você está, quais arquivos existem, em qual branch do git você está. Esse contexto é o que torna os prompts agendados realmente úteis em vez de simplesmente genéricos.
Passo 2: Verifique a conexão.
Você deve ver uma confirmação de que o Ollama está rodando dentro do seu ambiente do Claude Code. Teste um prompt rápido para ter certeza de que tudo está conectado:
/loop What time is it? every 5 minutes
Se você vir uma resposta confirmando que o loop está agendado, está tudo certo. Mate esse loop de teste antes que ele polua sua sessão — vamos configurar os de verdade agora.
Passo 3: Entenda a sintaxe do /loop.
O comando /loop segue um padrão de linguagem natural:
/loop [seu prompt] every [intervalo]
Os intervalos podem ser especificados em minutos, horas, ou âncoras de horário do dia. Aqui estão exemplos que realmente funcionam:
/loop Summarize my git diff every 2 hours
/loop Check for failing tests every 30 minutes
/loop Give me a standup summary every morning at 9am
/loop Review open PRs and flag stale ones every day at 3pm
O parsing de linguagem natural é surpreendentemente flexível. Já joguei horários com frases bem estranhas e ele geralmente entende o que eu quero dizer. "Every weekday morning" funciona. "Twice a day" funciona. "Every Monday" funciona.
Aqui está o que torna isso diferente de simplesmente configurar um cron job com um comando curl para uma API. Os prompts rodam dentro do contexto do Claude Code. Eles podem ver os arquivos do seu projeto. Podem ler seu histórico de git. Podem verificar seus processos em execução. Podem referenciar saídas de loops anteriores. Um cron job é sem estado e cego. Um prompt /loop é contextual e consciente.
Essa distinção é tudo, e é o que eu não percebi até começar a construir automações reais em cima disso.
Os Sete Loops Que Realmente Mudaram Meu Fluxo de Trabalho
Experimentei com dezenas de prompts agendados durante a última semana. A maioria foi inútil — experimentos de novidade que não sobreviveram ao segundo dia. Mas sete ficaram, e genuinamente reestruturaram como eu começo, conduzo e termino meu dia de trabalho. Vou percorrer cada um, porque os prompts específicos importam.
Loop 1: O Briefing Matinal
/loop Give me a morning briefing: summarize overnight git commits across all projects in this workspace, list any CI/CD failures, and flag PRs that have been open more than 48 hours. every morning at 8:30am
Esse foi o que me fisgou. Antes de abrir o Slack, antes de checar email, tenho uma imagem clara do que aconteceu durante a noite. Para alguém gerenciando múltiplos projetos — que, se você é desenvolvedor freelancer ou líder de um time pequeno, provavelmente é — isso elimina os primeiros vinte minutos de troca de contexto toda manhã.
A saída não é só um dump bruto do log do git. Como o prompt roda dentro do Claude Code com contexto completo, ele realmente resume o que mudou em termos legíveis para humanos. "O módulo de autenticação recebeu três commits do branch feature — parece que o gerenciamento de sessões foi refatorado" é infinitamente mais útil que uma lista de hashes de commits.
Loop 2: O Vigilante de Testes
/loop Run the test suite and report only failures with a brief diagnosis of what might be wrong. every 2 hours
Eu costumava rodar testes manualmente ou depender do CI para pegar falhas depois que já tinha feito push. Agora meu ambiente local roda a suíte a cada duas horas e me avisa antes que código ruim saia da minha máquina. A parte do "diagnóstico breve" é chave — não diz apenas "test_user_auth falhou", diz "test_user_auth falhou porque o banco de dados mock não está retornando o formato esperado do token de sessão. Parece que a mudança de schema na migration 047 pode não ter sido aplicada localmente."
O diagnóstico está sempre certo? Não. Talvez 70% das vezes acerta em cheio, 20% está na vizinhança certa, e 10% está completamente errado. Mas mesmo um diagnóstico errado me dá um ponto de partida, o que é melhor do que ficar encarando um stack trace do zero.
Loop 3: O Auditor de Dependências
/loop Check package.json and requirements.txt for any dependencies with known vulnerabilities or major version updates available. every day at noon
Higiene de segurança é uma daquelas coisas que todo mundo concorda que é importante e ninguém faz de forma consistente. Esse loop cuida disso passivamente. Uma vez por dia, recebo um relatório rápido: "lodash tem um patch disponível, sem problemas de segurança. O pacote jsonwebtoken está duas versões major atrás e tem um CVE moderado." Posso agir ou anotar para depois, mas pelo menos estou ciente.
Loop 4: O Lembrador de PRs
/loop Check all open pull requests in this repo. For any PR older than 24 hours without a review, remind me and suggest what to prioritize reviewing first based on the diff size and files changed. every day at 2pm
Esse é surpreendentemente eficaz para a dinâmica do time. Sou péssimo em lembrar de revisar PRs prontamente — mergulho no meu próprio trabalho e esqueço. Agora, toda tarde, recebo um aviso com contexto real sobre qual revisão é mais importante. Diff pequeno tocando um arquivo crítico? Marcado como alta prioridade. Refatoração grande sem mudanças nos testes? Marcado como "precisa de revisão cuidadosa."
Loop 5: O Detector de Desvio na Documentação
/loop Compare the current API routes in the codebase with the API documentation file. Flag any endpoints that exist in code but aren't documented, or documented but no longer exist in code. every 3 days
A deterioração da documentação é um problema real em todo projeto em que já trabalhei. Esse loop pega antes que fique grave. A cada três dias, descubro se a documentação ainda corresponde à realidade. O intervalo é longo o suficiente para não ser barulhento, curto o suficiente para que o desvio não se acumule por semanas.
Loop 6: O Resumo de Fim de Dia
/loop Summarize what I worked on today based on git commits, file changes, and terminal history. Format it as bullet points I could paste into a standup message. every weekday at 5:30pm
Isso é pura otimização de preguiça, e eu amo. Odeio escrever atualizações de standup. Detesto. Esse loop gera um primeiro rascunho que é 80% preciso, e gasto trinta segundos ajustando em vez de cinco minutos tentando lembrar o que fiz sete horas atrás.
Loop 7: O Digest de Notícias de IA
/loop Give me the latest AI news and notable releases from the last 24 hours, focused on developer tools, LLM updates, and open-source AI projects. every morning at 8am
Esse foi na verdade o primeiro loop que configurei — o da abertura deste post. Se manter atualizado em IA é genuinamente difícil quando o campo se move tão rápido. Um digest diário que me espera antes de começar a trabalhar significa que nunca estou mais de 24 horas atrasado em algo importante.
A qualidade desses digests depende do corte de conhecimento do modelo e do que ele pode acessar, o que é uma limitação da qual falarei honestamente em algumas seções. Mas mesmo resumos de notícias imperfeitos superam a alternativa, que é fazer doomscrolling no Twitter por trinta minutos tentando descobrir o que aconteceu ontem.
Agora é aqui que fica realmente interessante — porque esses sete loops são apenas os casos de uso óbvios. As implicações arquiteturais vão muito mais fundo.
A Verdadeira Mudança: De Ferramentas Reativas para Inteligência Ambiental
Quero dar um zoom out por um segundo, porque acho que a maioria das coberturas de funcionalidades como essa perde a visão geral.
Durante toda a história do desenvolvimento de software, nossas ferramentas foram reativas. Você abre seu editor — ele espera. Digita um comando — ele executa. Faz uma pergunta — ele responde. A ferramenta não faz nada até você iniciar. Toda interação começa com você.
Prompts agendados quebram esse padrão fundamentalmente.
Seu ambiente de desenvolvimento agora está fazendo coisas sem ser solicitado. Está monitorando, analisando, resumindo e alertando em seu próprio cronograma. Não de um jeito "configure e esqueça" — isso não é um script bash rodando em cron. Os prompts são contextuais, adaptativos e inteligentes. Eles entendem sua base de código. Podem raciocinar sobre o que encontram.
É assim que a inteligência ambiental se parece na prática. Não um assistente holográfico de ficção científica flutuando ao lado da sua mesa. Apenas um terminal que silenciosamente faz trabalho útil em segundo plano enquanto você se concentra nos problemas difíceis.
Pense no que isso significa para um dia de trabalho típico. Antes você começava sua manhã verificando manualmente o status do CI, revisando commits noturnos, procurando PRs abertos e se atualizando sobre o que mudou. São 30-45 minutos de carregamento de contexto antes de escrever uma única linha de código.
Com loops agendados, esse contexto está pré-carregado. Você senta, dá uma olhada nos resumos, e já está orientado. Começa a programar imediatamente, a toda velocidade, com total consciência.
Em uma semana, são 2-4 horas economizadas. Em um mês, é um dia inteiro ou mais. E isso é apenas a economia de tempo — a economia cognitiva é mais difícil de quantificar mas possivelmente mais valiosa. Cada troca de contexto que você elimina é energia mental preservada para a resolução real de problemas.
Tenho pensado nisso em termos do que chamo de "dívida de atenção do desenvolvedor." Cada verificação manual, cada revisão de status, cada "deixa eu ver o que está acontecendo com o build" é uma pequena retirada do seu orçamento diário de atenção. Individualmente trivial. Coletivamente brutal. Prompts agendados pagam essa dívida automaticamente.
Mas — e é aqui que meu entusiasmo é temperado com honestidade — a implementação atual tem limitações reais que você deveria conhecer antes de reconstruir todo o seu fluxo de trabalho em torno disso.
O Que Não Funciona Ainda (Avaliação Honesta)
Eu estaria te fazendo um desserviço se pintasse isso como perfeito. Depois de uma semana de uso intenso, aqui está o que está cru.
O agendamento não é perfeitamente confiável. Os loops ocasionalmente pulam um ciclo, especialmente se sua máquina entra em suspensão ou se a sessão do Claude Code é interrompida. Meu briefing matinal não disparou porque a tampa do meu laptop estava fechada às 8:30 AM. Esse é um modelo de execução local — não há um agendador na nuvem como backup. Se o processo não está rodando, o loop não executa. Você não pode tratá-lo como um cron job do lado do servidor que dispara independentemente.
Prompts longos às vezes produzem saída inconsistente. Meus loops mais complexos — os com instruções de múltiplas partes como o briefing matinal — ocasionalmente focam em uma parte e pulam outra. A verificação de PRs pode ser minuciosa enquanto o resumo de falhas do CI recebe uma única frase. Prompts mais curtos e focados são mais confiáveis que prompts tudo-em-um. Comecei a dividir briefings complexos em dois ou três loops separados em vez de um mega-prompt.
A pressão da janela de contexto é real. Cada execução de loop consome contexto. Se você está rodando seis loops ao longo do dia e também fazendo trabalho de desenvolvimento ativo na mesma sessão do Claude Code, pode atingir os limites de contexto mais rápido do que esperaria. Tive sessões onde meus loops da tarde produziram saída visivelmente pior porque a janela de contexto estava saturada com resultados dos loops da manhã mais meu trabalho real. A solução é gerenciar sua sessão ativamente — limpar o contexto quando fica pesado, ou rodar os loops em uma sessão dedicada separada do seu trabalho de desenvolvimento.
Os limites de conhecimento do modelo se aplicam. O loop do digest de notícias de IA é útil mas inerentemente limitado pelo que o modelo sabe. Ele não pode navegar na internet em tempo real (a menos que você tenha configurado ferramentas de acesso web). Então "últimas notícias de IA" realmente significa "o que posso inferir ou lembrar até meu corte de treinamento, mais o que estiver nos seus arquivos locais." Para notícias verdadeiramente atuais, você precisaria combinar o loop com uma ferramenta de web fetch ou integração RSS. Estou trabalhando nisso, mas ainda não é fluido.
Não há interface de gerenciamento de loops. Não há um painel mostrando seus loops ativos, sua última hora de execução, ou seu histórico de saída. Está tudo no scroll do seu terminal. Se você quer revisar o que um loop reportou três dias atrás, está caçando no histórico do terminal. Comecei a registrar as saídas dos loops em arquivos como solução:
/loop Check for failing tests and append results to ./logs/test-watchdog.log every 2 hours
Funciona mas parece um gambiarra. Uma interface de gerenciamento de loops adequada — listar loops ativos, pausar/retomar, ver histórico de execução — tornaria essa funcionalidade dramaticamente mais útil.
O consumo de recursos se acumula. Cada execução de loop usa computação. Rodar o Ollama localmente significa que sua CPU e RAM estão lidando com a inferência. Seis loops disparando ao longo do dia em um laptop podem fazer os ventiladores girarem e drenar a bateria visivelmente. Aprendi a ser seletivo com a frequência dos loops. Nem tudo precisa rodar a cada 30 minutos. A maioria das coisas está bem em intervalos de 2 horas ou diários.
Esses não são problemas que inviabilizam a adoção. Cada uma dessas limitações é solucionável, e aposto que a maioria será abordada em próximas atualizações. Mas conhecê-las de antemão te poupa a frustração de descobri-las no meio do fluxo de trabalho, que é exatamente a frustração pela qual eu passei para que você não precise.
As limitações são reais, mas não mudam a proposta de valor fundamental. O que me leva à parte que mais me empolga.
Construindo um Fluxo de Trabalho Ambiental Completo: Minha Configuração Atual
Depois de uma semana de iteração, aqui está minha configuração completa de loops. Compartilho os prompts exatos porque a redação específica importa — prompts vagos produzem resultados vagos.
Sessão 1: Ambiente de Desenvolvimento (sessão principal do Claude Code)
/loop Run the test suite for the current project, report failures only with one-line explanations. every 2 hours
/loop Scan the current git diff and warn me if I'm about to commit any hardcoded secrets, API keys, or credentials. every 30 minutes
Mantenho a sessão de desenvolvimento enxuta — apenas dois loops diretamente relevantes ao que estou construindo ativamente. Só o scanner de segredos já me salvou duas vezes de commitar um valor de .env que se infiltrou em um arquivo de configuração.
Sessão 2: Operações do Projeto (sessão separada do Claude Code, roda em uma aba de terminal em segundo plano)
/loop Morning briefing: overnight commits summary, CI status, stale PRs. every weekday at 8:30am
/loop Scan dependencies for known CVEs and available security patches. every day at noon
/loop End-of-day summary: what changed today in bullet point format. every weekday at 5:30pm
Essa sessão cuida da carga operacional. Dou uma olhada algumas vezes por dia, mas não compete por contexto com meu trabalho real de programação.
Sessão 3: Aprendizado e Consciência (terceira sessão, leve)
/loop AI development news and tool releases from the last 24 hours. every morning at 8am
Um loop, um propósito. Manter a sessão de aprendizado separada significa que nunca desloca o contexto de trabalho.
Três sessões, seis loops no total. Minha CPU lida bem em um MacBook M-series, embora eu note os ventiladores se as três sessões estão ativas e também estou rodando Docker. O consumo de recursos é gerenciável mas não negligenciável.
Veja como se desenrola em uma terça-feira típica:
8:00 AM — O digest de notícias de IA está esperando. Leio por cima enquanto o café fica pronto. Dois minutos.
8:30 AM — O briefing matinal chega. Sei que o CI está verde, há dois PRs abertos (um de ontem, um noturno), e o branch de refatoração de auth recebeu três commits de um colaborador. Cinco minutos de leitura, e estou completamente orientado.
9:00 AM — Começo a programar com total consciência do projeto. Sem tempo de aquecimento. Sem "espera, no que eu estava trabalhando ontem?" Sem verificar o CI manualmente. Eu simplesmente... começo.
10:30 AM — O scanner de segredos roda. Nada marcado. Bom. Nem quebro meu fluxo.
11:00 AM — O vigilante de testes dispara. Dois testes falhando — ambos relacionados a um mock que esqueci de atualizar depois da mudança de schema de ontem. O diagnóstico é preciso. Corrijo ambos em dez minutos.
12:00 PM — A auditoria de dependências chega na sessão de operações. Um CVE de baixa severidade em uma dependência transitiva. Anoto para o ciclo de atualização semanal.
1:00 PM — O vigilante de testes dispara novamente. Tudo verde. Confiança de que minhas correções da manhã se mantiveram.
2:00 PM — O lembrador de PRs (adicionei à sessão de operações depois do terceiro dia). Um PR de um colaborador está aberto há 36 horas — é um diff pequeno tocando o módulo de pagamentos. Reviso imediatamente. Quinze minutos bem gastos.
3:00 PM — Vigilante de testes. Tudo verde. Scanner de segredos. Limpo.
5:30 PM — O resumo de fim de dia é gerado. Copio, ajusto dois pontos, colo no Slack do time. Pronto em menos de um minuto.
Tempo total gasto com carga operacional: aproximadamente 35 minutos, espalhados ao longo do dia em interações pequenas e de baixa fricção. Compare com minha rotina pré-loops onde gastava mais de 30 minutos só no carregamento de contexto matinal, mais outros 20-30 minutos ao longo do dia em verificações manuais e revisões de status.
As economias se acumulam. E mais importante, a carga cognitiva caiu drasticamente. Não estou carregando "verifiquei o CI?" ou "tem PRs que estou ignorando?" no fundo da minha mente. O sistema cuida disso.
Essa é a verdadeira descoberta — não a economia de tempo, embora seja real, mas a economia de atenção. Meu cérebro tem menos abas abertas.
Padrões Avançados Que Estou Explorando
Os loops básicos cobrem os casos de uso óbvios. Mas comecei a experimentar com padrões mais sofisticados que indicam para onde isso está indo.
Loops Encadeados. Usar a saída de um loop como entrada para outro. Por exemplo, o vigilante de testes detecta uma falha e escreve em um arquivo de log. Um segundo loop monitora esse arquivo de log e, quando detecta uma nova entrada, tenta uma correção automatizada e roda os testes novamente. Consegui fazer isso funcionar para casos simples — imports faltando, colchetes não fechados, atualizações de mock esquecidas. A taxa de sucesso nas correções automáticas é talvez 40%, mas quando funciona, um teste falhando é corrigido sem eu tocar no teclado.
/loop If ./logs/test-watchdog.log has new failures in the last 2 hours, attempt to fix them and re-run the affected tests. Report what you tried and whether it worked. every 2 hours offset by 15 minutes
O "offset de 15 minutos" dá tempo para o vigilante de testes escrever seus resultados antes que o corretor automático os leia. Coordenação rudimentar, mas funciona.
Loops Condicionais. Prompts que só produzem saída quando algo interessante acontece. Meu scanner de segredos é tecnicamente um loop condicional — só me alerta quando encontra algo. Mas você pode aplicar esse padrão amplamente:
/loop Check if any new issues have been opened in this repo. Only tell me if there are new ones since the last check. every 4 hours
Silêncio significa que está tudo bem. Saída significa que algo precisa de atenção. Isso inverte o padrão — em vez de você procurar atualizações, as atualizações se anunciam sozinhas.
Loops Reflexivos. Esse é experimental e honestamente um pouco estranho, mas me fascina. Um loop que revisa seu código recente e oferece sugestões arquiteturais não solicitadas:
/loop Review the last 3 hours of git commits in this project. If you notice any patterns that suggest emerging technical debt, architectural drift, or inconsistency with the existing codebase patterns, flag them. Be specific and give suggestions. every day at 4pm
A saída varia de genuinamente perspicaz ("Você adicionou quatro padrões diferentes de tratamento de erros nesses commits — considere padronizar com o padrão do tipo Result que usou no módulo de autenticação") a completamente inútil ("Seu código está bom, nenhum problema detectado"). Aproximadamente uma em cada três execuções produz algo em que eu realmente ajo. Essa taxa de acerto é baixa, mas os insights são valiosos o suficiente para manter.
Esses padrões são toscos. Precisam de ferramentas melhores, mecanismos de encadeamento melhores, melhor gerenciamento de estado entre loops. Mas esboçam um futuro onde seu ambiente de desenvolvimento não é apenas passivamente útil — está participando ativamente na qualidade do código, gerenciamento de projeto e coerência arquitetural.
O Que Isso Significa para a Produtividade do Desenvolvedor (O Argumento Maior)
Quero fazer uma afirmação que pode soar hiperbólica, então deixa eu construí-la com cuidado.
Os desenvolvedores mais produtivos que conheço não são os que programam mais rápido. São os que têm os melhores sistemas. Têm painéis que trazem problemas à tona cedo, hábitos que previnem troca de contexto, rotinas que carregam a consciência desde o início. Gastam menos tempo se perguntando "no que devo trabalhar?" e mais tempo realmente trabalhando.
Prompts agendados são uma melhoria a nível de sistema na produtividade do desenvolvedor. Não porque um único loop seja transformador, mas porque o efeito agregado de seis ou sete loops bem projetados elimina uma categoria inteira de fricção do seu dia de trabalho. A categoria que eu chamaria de "consciência operacional" — saber o que está acontecendo nos seus projetos, no seu time, nas suas dependências, no seu pipeline.
A maioria dos desenvolvedores lida com consciência operacional através de uma combinação de verificações manuais, notificações do Slack, alertas por email e alternância entre painéis. É disperso, reativo e interruptivo. Loops agendados consolidam isso em um fluxo único, silencioso e contextual que espera por você quando você quer e não te interrompe quando você não quer.
Aqui está minha afirmação maior: estamos vendo o ambiente de desenvolvimento evoluir de uma ferramenta para um colega de equipe. Não um colega que escreve código por você — essa é a conversa atual de IA, e é importante, mas é só metade da história. Um colega que cuida da periferia operacional. Que vigia as coisas que você esqueceria de verificar. Que nota padrões que você perderia porque está muito imerso nos detalhes de implementação.
O comando /loop é uma funcionalidade pequena. O paradigma que ele habilita é enorme.
Pense para onde isso vai em doze meses. Loops que se coordenam entre os ambientes dos membros do time. Loops que aprendem seus padrões e ajustam sua frequência. Loops que escalam baseado na severidade — uma atualização menor de dependência é registrada silenciosamente, um CVE crítico dispara um alerta imediato. Loops que interagem com serviços externos — sua ferramenta de gerenciamento de projetos, seu stack de monitoramento, seus canais de comunicação.
Seu terminal se torna um centro de comando, não uma linha de comando.
Isso não é uma previsão. É uma extrapolação do que já funciona hoje, apenas com arestas mais brutas. E se você começar a construir o hábito agora — começar a configurar loops, começar a pensar no seu fluxo de trabalho como algo que pode ser parcialmente automatizado e continuamente monitorado — estará posicionado para aproveitar cada melhoria conforme for lançada.
O Desafio de Uma Hora
Se você leu até aqui, já entende o valor. Então aqui está o que eu faria se fosse você, hoje, na próxima hora.
Abra o Claude Code. Execute ollama launch claude. Configure exatamente dois loops:
/loop Summarize my git activity for the day in bullet points. every weekday at 5pm
/loop Check for any failing tests and explain what's wrong. every 3 hours
Dois loops. Simples. Baixo comprometimento. Rode por uma semana.
Aposto que no terceiro dia, você vai começar a pensar em novos loops. No quinto dia, vai se perguntar como se virava sem eles. No final da semana, vai estar construindo o tipo de fluxo de trabalho ambiental que descrevi — não porque eu mandei, mas porque uma vez que você experimenta um ambiente de desenvolvimento que trabalha para você em segundo plano, voltar para uma configuração puramente reativa parece como dirigir sem espelhos.
Seu terminal já está aberto. Sua IA já está rodando. A única pergunta é se ela está trabalhando enquanto você trabalha — ou só quando você lembra de perguntar.
Let's Work Together
Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.
- Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise solutions): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (security services): xcybersecurity.io
