Um dev subir um branch e rodar a aplicação é trivial. Vários agentes, cada um com seu branch, cada um com seu banco, sua porta e sua stack completa — tudo na mesma máquina, sem conflito — é onde a coisa complicava. O Lich, mostrado no Show HN de 6 de junho de 2026 com 6 pontos, ataca exatamente esse ponto. E a ideia é simples o suficiente para você entender em cinco minutos.
A resposta direta
Lich é um CLI que lê um lich.yaml no seu repositório e sobe uma cópia isolada e completa do seu dev stack por worktree do Git. Dois branches? Duas cópias da aplicação, dois bancos, duas portas, dois URLs. Sem editar package.json, sem gambiarra de .env, sem kill no processo da outra pessoa. Um lich up por branch. O projeto é open source (MIT), escrito em TypeScript/Bun, e vem com skills para Claude e outros coding agents instrumentarem seu repositório automaticamente.
Pronto. Isso é o produto. O resto do artigo é o porquê isso importa.
O que é e por que importa agora
O fluxo "branch + PR + revisar" funciona para times humanos. Cada dev tem a própria máquina, sobe a stack local, e vida que segue. Quando você joga coding agents (Claude Code, Cursor, Codex, Aider) no meio, o jogo muda. Cada agente trabalha em uma branch. Cada branch precisa de:
- um banco de dados separado
- uma porta disponível
- variáveis de ambiente certas
- um seed/migração rodada
- um servidor HTTP respondendo
Sem isolamento, dois agentes trabalhando em paralelo quebram um ao outro. Port 3000 já está em uso. O banco do agente A está no estado que o agente B precisa. O node_modules está conflitando. E o humano, que queria acelerar o trabalho, vira zelador de processo. Lich mata isso. Ele detecta o worktree ativo, aloca portas dinamicamente, sobe um Docker por serviço com nomes únicos, e devolve uma URL limpa que funciona no navegador.
O timing não é coincidência. Em 2026, a maioria dos engenheiros sêniores roda pelo menos um coding agent em paralelo com o trabalho manual. Times inteiros estão operando com 2 a 5 agentes simultâneos. O gargalo real não é mais "a IA sabe programar" — é "a IA sabe programar sem quebrar meu ambiente". Ferramentas que resolvem o segundo problema estão onde a indústria põe dinheiro agora.
Como funciona (sem jargão)
Você define uma vez como seu dev stack é. Em lich.yaml:
version: 1
services:
postgres:
image: postgres:16
ports:
- { container_port: 5432, published_env: POSTGRES_HOST_PORT }
environment:
POSTGRES_PASSWORD: dev
owned:
api:
cwd: apps/api
cmd: pnpm dev
port: { published_env: PORT }
env:
DATABASE_URL: "postgres://postgres:dev@localhost:${services.postgres.host_port}/app"
Sobe a stack com lich up. Lich cuida do resto. Quando você cria um novo worktree (git worktree add ../repo-feature -b feature) e roda lich up de novo, ele sobe uma segunda instância isolada — outro Postgres em outra porta, outra API em outra porta, outro DATABASE_URL calculado automaticamente. O comando lich stacks lista tudo que está rodando:
WORKTREE STATUS UPTIME SERVICES URL
repo up 00:02:15 2/2 http://web.repo.lich.localhost:3300/
repo-feature up 00:00:08 2/2 http://web.repo-feature.lich.localhost:3300/
Para limpar tudo, lich nuke. Para seguir o log de um stack específico, lich logs. Para desligar um só, lich down. A CLI inteira é uma dúzia de comandos. O trabalho de orquestração que era colar script no README do projeto agora é declarativo.
O pulo do gato é a skill lich-instrument. Em vez de você escrever o lich.yaml à mão, você instala a skill no Claude (ou outro agente) e roda /lich-instrument. O agente lê seu repositório, identifica os serviços, escreve o YAML, ajusta env vars, e te entrega um dev stack reproduzível. O trabalho de "configurar dev stack para IA trabalhar bem" deixa de ser projeto e vira prompt.
Comparativo rápido: antes vs agora
| Situação | Sem Lich | Com Lich |
|---|---|---|
| Subir a aplicação em um branch | pnpm install && pnpm dev | lich up |
| Rodar dois branches em paralelo | Editar .env, mudar porta, rezar | git worktree add + lich up no novo path |
| Banco por branch | Provisionar manualmente, lembrar de derrubar | Automático, em container nomeado, isolado por worktree |
| Variáveis de ambiente entre worktrees | cp .env.feature .env.local e torcer | Template + substituição automática via published_env |
| Coding agent quebrando dev stack | Constantemente | Quase nunca — o agente opera num stack isolado, fora do seu |
| Teardown | Matar processos, limpar Docker órfão | lich nuke |
| Visibilidade | Abrir 4 terminais e rezar | lich stacks em uma linha |
A primeira coluna não é exagero. Quem já tentou rodar Codex em uma branch e continuar trabalhando em outra no mesmo repositório sabe que o retrabalho de gerenciar ambiente é o que consome o ganho de produtividade.
O que isso muda para o seu negócio
Você não precisa ser dev para se importar com isso. A onda é mais larga.
1. "Um dev rodando 3 agentes" sai da conversa e vira operação padrão. O efeito prático: times de engenharia dobram throughput em tarefas mecânicas (migração de API, refactor, geração de testes) sem dobrar headcount. Para uma PME brasileira com 2 a 5 engenheiros, isso é competitivo. Para uma com 1, é a diferença entre "fazer backlog andar" e "ficar preso no mesmo bug 3 meses".
2. O custo de manter ambiente de dev local para freelancer cai a zero. Hoje, contratar um freelancer de 2 meses significa 2 semanas para ele entender e subir o ambiente. Com Lich instrumentado, o freelancer clona, roda lich up, e está produzindo no dia 1. É o mesmo salto que Docker Compose deu para DevOps, agora para o desenvolvedor individual.
3. O fornecedor de software que integra agentes ao fluxo de entrega precisa pensar em isolamento. Se você é um SaaS que vende "agente de IA que faz X" para o cliente, o agente tem que rodar em algum lugar. Lich (e similares que vão aparecer) transforma a pergunta "como provisiono o ambiente?" em "como descrevo o ambiente?". A segunda é 10x mais barata de responder.
4. A categoria "AI dev infrastructure" amadurece. Lich é open source, MIT, com funding implícito (mantenedor ativo, releases em 0.4.0, skills para Claude). Concorrentes vão aparecer — e isso é o sinal de que a categoria está quente. Vale acompanhar o repo no GitHub para entender para onde vai.
5. O detalhe que ninguém fala: o impacto em retenção de dev. Engenheiro bom não quer mais perder sexta-feira consertando o ambiente local. Empresa que instrumenta o dev stack com Lich ganha ponto na guerra por talento. Não é o único fator, mas ajuda.
A parte que ninguém conta: o custo de orquestrar trabalho paralelo
Tem um efeito colateral interessante que a página do Lich não grita, mas que o README deixa escapar. A frase "agents get derailed running down bugs in tooling instead fixing actual problems" é a confissão de que a maior parte do tempo gasto por coding agents hoje é em debugging de ambiente, não em programação. É o equivalente, em 2026, do "funciona na minha máquina". O agente tenta rodar testes, o teste falha porque o banco não está acessível, o agente lê o erro, ajusta config, tenta de novo, gera novo erro, e meia hora depois está perdido em um buraco que não tem nada a ver com a feature pedida.
Lich fecha essa porta. O dev stack que o agente recebe é determinístico. Se a stack sobe limpa, ela sobe limpa para todo agente. O erro que aparece é o erro real da feature, não o ruído do ambiente. Para o humano supervisor, isso muda completamente o tipo de bug que aparece na revisão — quase todos viram problemas de lógica de negócio, não de setup.
Esse é o tipo de ferramenta que parece "infra de dev" e termina sendo "produtividade de IA".
Limites honestos
- Lich assume que sua stack é conteinerizável ou roda como processo local bem-comportado. Sistemas legados com 15 variáveis de ambiente herdadas, sem
Dockerfile, vão exigir adaptação. - A skill
lich-instrumentestá otimizada para Claude. Outros agentes (Cursor, Codex, Aider) podem usar olich.yamlresultante, mas o trabalho de gerar o YAML depende mais de você do que a página inicial sugere. - Telemetria opt-in, mas existe. O
distinct_idé um hash one-way, mas se sua empresa tem compliance rígido, vai precisar setarLICH_TELEMETRY=0no ambiente. - É jovem (0.4.0). Funciona, mas espere arestas. Não é produção-dependente ainda.
Nada disso tira o mérito. O problema que ele resolve é real, e a abordagem é a certa.
Referência natural Agendai
A Agendai constrói agentes de IA para varejo brasileiro. A lógica do Lich se aplica direto: cada cliente tem dados sensíveis (catálogo, clientes, vendas) que não podem ser compartilhados entre agentes. Quando rodamos um agente que faz follow-up de vendas e outro que detecta ruptura de estoque para o mesmo varejista, eles precisam de bancos isolados — exatamente o problema que Lich resolve. É o tipo de ferramenta que entra no nosso playbook em 2026 para acelerar deploy de novos agentes por cliente sem reescrever a orquestração a cada projeto. Se você está implementando agentes no seu negócio e esbarra na parede do "como isolar ambiente", vale uma conversa.
Perguntas frequentes
O que é o Lich?
É um CLI open source (MIT) que sobe uma cópia isolada do seu dev stack para cada worktree do Git. Cada branch vira um ambiente independente, com portas e bancos próprios, sem conflito. Feito para rodar coding agents em paralelo.
Como o Lich funciona na prática?
Você descreve seu dev stack em um arquivo lich.yaml (Postgres, API, Next.js, o que for). Aí, em cada worktree, roda lich up. Ele aloca portas dinamicamente, sobe containers com nomes únicos, e expõe uma URL por stack. Para desligar, lich down. Para limpar tudo, lich nuke.
Quanto custa implementar Lich?
Custo zero no software (MIT). O custo real é uma tarde para escrever o lich.yaml do seu repositório — ou algumas horas a mais se você deixar a skill lich-instrument fazer isso via Claude. Depois disso, é lich up para o resto da vida do projeto.
Quais os riscos de usar Lich?
É projeto jovem (versão 0.4.0). Arestas vão aparecer, especialmente em stacks não-convencionais (legado Windows, monorepo com serviços acoplados). A telemetria opt-in precisa ser desabilitada em ambientes com compliance rígido. Para stack moderna baseada em Docker e Node/Python/Go, o risco é baixo.
Lich substitui Docker Compose?
Não. Ele usa Docker Compose por baixo, mas adiciona a camada que falta: isolamento por worktree, alocação dinâmica de portas, nomenclatura única, e o painel lich stacks que mostra tudo rodando. Pense nele como "Docker Compose para o mundo de coding agents paralelos".
Posso rodar Lich com qualquer coding agent?
Sim, qualquer agente que opere em worktree do Git. O Lich em si não se importa com quem é o agente — ele provê o ambiente. As skills oficiais (lich, lich-instrument) são otimizadas para Claude, mas o YAML resultante é agnóstico.
Recomendamos também: O que é MCP (Model Context Protocol) e por que vai mudar os agentes de IA e Agente de IA vs Chatbot: qual a diferença real em 2026?.
Se você quer implementar agentes de IA no seu negócio sem virar refém de fornecedor, a Agendai constrói a stack completa para varejo — agentes plugáveis, isolados por cliente, prontos para conversar com seu CRM, seu ERP e seu WhatsApp.