O QUE ME LEVOU A DESENVOLVER A JULIA CODE

Pra contextualizar eu sou Aleksander Palamar sou dev e engenheiro de software tech lead trabalho remoto para uma empresa de Portugal que é especializada no desenvolvimento sistemas e aplicações para área da saúde, sempre fui entusiasta por tecnologia e todo esse meu fascínio começou lá em 2004 com a minha primeira distro Linux que instalei no meu PC Slackware também tive o meu primeiro contado com a linguagem de progamação shell script, desde lá procurei estudar e aprofundo os meus conhecimentos na area da tecnologia.

E essa origem no Linux moldou muito a forma como eu penso sobre software. Quem começou com Slackware sabe que não tinha nada mastigado, você tinha que compilar kernel na mão, configurar o X11 editando arquivo texto, resolver dependência uma por uma. Isso te ensina a entender o que tá acontecendo por baixo e a não ter medo de meter a mão. Essa mentalidade ficou comigo até hoje.

Motivação

Desde sempre tive essa filosofia de fazer você mesmo, e com os conhecimento que possuo pensei comigo porque não construir uma ferramenta CLI estilo Claude Code, mas pensando que ela seja totalmente open-source e gratuita, otimizada e o usuario não dependesse das big techs...

E olha, não é que eu tenha algo contra o Claude Code ou o Cursor, muito pelo contrário, são ferramentas excelentes e eu mesmo uso no dia a dia. O ponto é outro. Eu comecei a perceber que toda vez que eu dependia dessas ferramentas eu tava basicamente alugando inteligência de alguém. E como dev que cresceu no mundo Linux, isso me incomodava. A gente sempre teve essa cultura de que se algo não existe ou não te atende, você constrói. Simples assim.

O gatilho mesmo veio num dia comum de trabalho. Eu tava usando uma ferramenta de AI coding e a API caiu. Pronto, fiquei parado. Naquele momento pensei: cara, eu tenho uma GPU razoável aqui, tenho modelos open-source cada vez melhores rodando local, por que eu preciso depender de um servidor lá nos EUA pra ter um assistente de código?

O problema que eu vi

Quando comecei a analisar o cenário com mais calma percebi que o problema era maior do que eu imaginava. Vou listar o que me incomodava:

Dependência de cloud: A maioria das ferramentas de AI coding depende de uma API externa. Sem internet, sem assistente. Pra quem trabalha remoto como eu, nem sempre a conexão é perfeita. E mesmo quando é, ter uma dependência externa pra algo tão central no seu fluxo de trabalho é arriscado.

Custo: Assinaturas mensais, tokens pagos, limites de uso. Pra um dev individual ou uma equipe pequena isso pesa. E o pior é que você paga e não tem controle nenhum sobre o que tá rodando por trás. Amanhã o preço sobe, o modelo muda, o rate limit aperta e você fica refém.

Privacidade: Esse ponto pra mim é crítico. Eu trabalho com sistemas na área da saúde. Cada linha de código que eu mando pra uma API cloud tá passando por servidores de terceiros. Eu sei que as empresas dizem que não usam seus dados pra treinar, mas a realidade é que seu código sai da sua máquina. Pra muitos contextos isso simplesmente não é aceitável.

Falta de controle: Você não escolhe o modelo, não ajusta o comportamento, não sabe como o contexto tá sendo gerenciado. É uma caixa preta. E como engenheiro eu gosto de entender o que tá acontecendo, quero poder abrir o capô e mexer.

Esses quatro pontos juntos me convenceram de que existia espaço pra algo diferente. Não necessariamente melhor que o que já existe, mas diferente na proposta.

A ideia tomou forma

Decidi que ia construir. Não como um experimento de fim de semana, mas como um projeto de verdade. Algo que eu pudesse usar no meu trabalho real e que outros devs também pudessem usar.

As primeiras decisões técnicas vieram naturalmente:

Node.js e TypeScript: Porque é o ecossistema que eu domino, tem um tooling maduro e me permite iterar rápido. Além disso o ecossistema npm facilita muito a distribuição, qualquer dev instala com um npm i -g juliacode e já sai usando.

Ollama: Porque é a forma mais simples e robusta de rodar modelos locais hoje. Você instala, faz pull do modelo que quiser e tem uma API local rodando. Sem complicação. E o mais importante: funciona offline.

SQLite: Pra persistência de sessões, memória e histórico. É um banco embedded, não precisa de servidor, o arquivo fica na sua máquina. Simples, rápido e confiável. WAL mode habilitado pra não ter problema com concorrência.

React + Ink: Pra interface no terminal. Eu queria uma TUI que fosse bonita e responsiva, não só texto cru. O Ink me permite usar o modelo de componentes do React pra renderizar no terminal, com streaming em tempo real.

O nome Julia veio da ideia de ser algo pessoal, próximo. Não é uma marca corporativa, é o nome de uma ferramenta feita por um dev pra devs. Na linha de comando ela atende por juju, que é como a gente chama no dia a dia.

Como funciona na prática

A Julia roda 100% na sua máquina. Você precisa ter o Ollama instalado e pelo menos um modelo baixado. Aí é só abrir o terminal:

npm i -g juliacode
juju

E pronto, você tá conversando com um assistente de código que não depende de nada externo.

A Julia tem acesso a 10 ferramentas que ela executa de forma autônoma:

exec     → roda comandos no shell (git, npm, make...)
read     → lê arquivos com número de linha
write    → cria ou sobrescreve arquivos
edit     → edita trechos específicos de arquivos
glob     → busca arquivos por padrão
grep     → busca conteúdo com regex
fetch    → acessa URLs e APIs
memory   → memória persistente entre sessões
sessions → gerencia sessões salvas
subagent → orquestra subagentes paralelos

O diferencial que eu mais me orgulho é o sistema de subagentes paralelos que utiliza o ACP (Agent Client Protocol). Quando você pede algo complexo, tipo "cria um servidor REST com 3 endpoints", a Julia detecta que dá pra paralelizar e automaticamente spawna subagentes independentes, cada um com sua própria sessão e contexto:

┌──────────────────────────────────────────────────┐
│  julia> create a REST server with 3 endpoints    │
│                                                  │
│  🔀 Complex task — spawning 3 subagents...       │
│    → Subagent: endpoint GET /users               │
│    → Subagent: endpoint POST /users              │
│    → Subagent: endpoint DELETE /users/:id         │
│  ✅ 3 completed, no failures                     │
└──────────────────────────────────────────────────┘

Cada subagente pode inclusive usar um modelo diferente. Você pode ter um modelo mais pesado pro raciocínio principal e modelos mais leves pros subagentes que fazem tarefas mais simples. Tudo configurável.

Outro ponto que fez diferença no meu fluxo foi a memória persistente. A Julia lembra de coisas entre sessões. Preferências suas, padrões do projeto, configurações do sistema. Você não precisa ficar repetindo contexto toda vez que abre uma sessão nova.

E sobre segurança, isso pra mim era inegociável. A Julia tem um sistema de permissões onde cada ferramenta é classificada por nível de risco. Comandos perigosos como rm -rf / ou curl | sh são bloqueados por padrão. Operações que podem ser destrutivas pedem aprovação antes de executar. Seu código nunca sai da sua máquina.

O que aprendi construindo isso

Construir uma ferramenta de AI coding do zero te ensina muita coisa que você não aprende só usando essas ferramentas.

Context window é um recurso precioso, modelos locais geralmente têm janelas de contexto menores que os modelos cloud. Aprendi na marra que você precisa ser muito inteligente na hora de gerenciar o que entra e o que sai do contexto. Implementei um sistema de compaction que faz uma sumarização estruturada das conversas antigas, preservando decisões importantes e caminhos de arquivo, mas liberando espaço pro que é relevante agora.

Tool calling com modelos locais é desafiador, modelos como o Qwen, DeepSeek e outros open-source melhoraram muito no tool calling, mas ainda tem suas peculiaridades. Tive que implementar lógicas de fallback e validação que com APIs cloud você não precisa se preocupar. É mais trabalho, mas o resultado é que a Julia funciona com uma variedade grande de modelos.

Honestidade sobre trade-offs, eu não vou mentir, rodar local tem limitações. Modelos locais não são tão bons quanto o Claude Opus ou o GPT-5.3 codex em tarefas muito complexas. A velocidade depende do seu hardware. Se você tem uma GPU modesta, vai sentir. Mas pra grande maioria das tarefas do dia a dia, editar arquivos, rodar comandos, refatorar código, criar boilerplate, funciona muito bem. E a tendência é só melhorar conforme os modelos open-source evoluem.

A ferramenta mudou meu próprio fluxo, depois que comecei a usar a Julia em meus side projects, percebi que ter um assistente que roda local, que não tem rate limit, que não cobra por token, me fez usar mais. Sem aquela ansiedade de "será que vale gastar tokens com essa pergunta?". Simplesmente pergunto, peço pra fazer, e ela faz. Isso é libertador.

O futuro e um convite

A Julia tá na versão 0.3.0 agora e o roadmap tem muita coisa pela frente. Quero melhorar o suporte a MCP (Model Context Protocol) pra integrar com ferramentas externas, expandir o sistema de skills, e continuar otimizando o uso de memória e contexto.

Mas o mais importante é que ela é open-source. Qualquer dev pode usar, contribuir, adaptar pro seu fluxo. É isso que eu quero: que a comunidade participe, que outros devs que compartilham dessa mesma filosofia de independência e controle sobre suas ferramentas venham construir junto.

Eu comecei lá em 2004 instalando Slackware num PC velho e aprendendo shell script. Vinte e dois anos depois eu tô aqui construindo um assistente de código AI que roda na minha máquina, sem depender de ninguém. A tecnologia mudou completamente, mas a filosofia é a mesma: entenda como funciona, e se não existe o que você precisa, construa.

Se você é dev e já pensou "eu consigo fazer isso", provavelmente consegue. Vai lá e faz.

A Julia Code tá disponível no npm: npm i -g juliacode. O código tá no (GitHub)[https://github.com/aleksanderpalamar/julia-code] site do projeto (juliacode.dev)[https://juliacode.aleksanderpalamar.dev/], aberto pra quem quiser contribuir.