Fallow: o ESLint para problemas de código gerado por IA

Fallow: O ESLint para os problemas do código gerado por IA

No mês passado, lancei uma funcionalidade que o Claude Code escreveu quase inteiramente sozinho. Funcionou. Os testes passaram. O PR foi mesclado. Me senti ótimo por cerca de uma semana.

Então voltei para fazer uma pequena alteração e encontrei três cópias da exata mesma lógica de extração de áudio no mesmo arquivo. Nomes de variáveis diferentes, comportamento idêntico. Uma função exportada chamada extractAllAudio que nada no codebase importava. Uma dependência de dev instalada nas dependencies de produção. Nada disso quebrava nada. Tudo era deterioração, se acumulando silenciosamente.

Esse é o segredo sujo da codificação rápida com IA: o código funciona, então você para de olhar. E a ferramenta que você normalmente usaria — ESLint — não detecta nada disso. ESLint te avisa sobre um ponto e vírgula faltando. Não diz nada sobre o bloco de 100 linhas que você copiou e colou em quatro rotas.

Então quando encontrei o fallow, uma ferramenta gratuita de qualidade de código gerado por IA em linha de comando, construída especificamente para as falhas de manutenibilidade que as ferramentas de codificação com IA introduzem, separei uma tarde e apontei para o meu repositório mais bagunçado. O que ele revelou mudou a forma como eu reviso a saída dos agentes. Deixe-me mostrar exatamente o que ele encontrou — e onde conquistou seu lugar no meu workflow versus onde não conquistou.

Por que o código gerado por IA deteriora de formas que o ESLint nunca vê

O ponto sobre um LLM escrevendo código é o seguinte: ele não tem memória do que escreveu quatro arquivos atrás. Ele otimiza para este prompt, agora, produzir saída funcional. A manutenibilidade em todo o codebase simplesmente não está na sua função de perda.

Isso produz três modos de falha específicos, repetidamente, tanto em projetos codificados manualmente quanto em projetos vibecoded — embora seja muito pior quando um agente está digitando.

Duplicação. O modelo precisa da mesma lógica em dois lugares, então a escreve duas vezes. Depois uma terceira vez. Ele não extrai um helper compartilhado porque extrair requer manter todo o codebase na memória de trabalho, e ele não faz isso. Já vi mais de 100 linhas idênticas repetidas em um único arquivo. ESLint dá de ombros para isso. O código é válido.

Inchaço e complexidade. Peça a um agente para "lidar com todos os casos de borda" e ele vai — empilhando condicionais dentro de loops dentro de condicionais até que uma única função tenha 1.500 linhas e ninguém, humano ou máquina, consiga manter na cabeça. Cada ramificação está correta. O todo é um pântano.

Peso morto. Arquivos não utilizados. Funções exportadas que nada importa. Dependências adicionadas para um experimento e nunca removidas. Agentes criam scaffolding constantemente e raramente limpam depois, porque a limpeza não era a tarefa.

E a cruel ironia? Ferramentas de IA são ruins em detectar sua própria deterioração. Pergunte ao Claude ou Cursor "há duplicação neste arquivo?" e você receberá uma resposta confiante, plausível e frequentemente incorreta. É um palpite probabilístico sobre sua própria saída. O que você realmente precisa é algo determinístico — algo que analise o código em vez de raciocinar sobre ele.

Essa é a lacuna que o fallow preenche. E a forma como ele preenche é a parte interessante.

O que o fallow realmente é (e por que Rust importa aqui)

Fallow é inteligência de codebase para TypeScript e JavaScript, construída inteiramente em Rust. A equipe por trás — a organização fallow-rs no GitHub — o descreve como a consolidação de todo um conjunto de ferramentas de análise estática em um único binário que executa em menos de um segundo. No início de junho de 2026, está na linha de versões 2.8x, lançando atualizações quase diariamente.

O modelo se divide claramente em dois:

• Inteligência estática — inteiramente gratuita e de código aberto. Analisa a estrutura do seu código: dead code, duplicação, dependências circulares, complexidade, limites de arquitetura. Esta é a parte que eu uso e sobre a qual todo este artigo é escrito.
• Inteligência em tempo de execução — uma camada paga opcional que adiciona revisão de caminhos quentes e evidência de eliminação de caminhos frios baseada em tráfego real de produção. Ela te diz qual código "morto" está realmente morto com base no que roda em produção. Útil para grandes equipes tomando decisões de eliminação. Eu não paguei por ela, e quero ser honesto sobre isso: estou avaliando a camada estática gratuita, que é onde vive o valor do dia a dia.

Você não precisa instalar nada para experimentar. Um único comando:

# Execute uma análise completa no repo atual, sem instalar nada
npx fallow

Na primeira execução, o fallow auto-detecta seu stack. No meu projeto com Vite + TanStack Query, ele carregou os plugins para Vite, TanStack Query e Tailwind CSS sem eu configurar nada — ele vem com cerca de 95 plugins de framework e conecta os corretos baseado no seu package.json. Ele também cria um diretório de cache .fallow para que execuções subsequentes sejam rápidas.

Por que Rust importa? Porque a velocidade muda o comportamento. Um linter que leva 40 segundos é executado uma vez por semana. Um linter que termina antes de você mover a mão do teclado é executado a cada salvamento, em cada PR, por cada agente em loop. Análise em menos de um segundo é o que torna o fallow viável dentro de um workflow agêntico, o que — argumentarei mais adiante — é onde ele se torna genuinamente poderoso.

Mas primeiro, o relatório. Porque a primeira vez que você lê um relatório do fallow sobre código escrito por IA, é um pouco humilhante.

Lendo um relatório do fallow: as quatro seções que importam

Quando eu executei, a saída se dividiu em categorias claras. Vou percorrer cada uma da forma como as li, começando pelo pior infrator.

Dead code: o que você esqueceu que escreveu

Esta seção encontra três coisas, e os workflows com IA geram as três em volume:

• Arquivos não utilizados — módulos que nada importa. Scaffolding de agentes que nunca foi conectado.
• Exportações não utilizadas — aquele extractAllAudio que mencionei. Exportado, com aparência pública, importado por nada. Fallow marca com a localização exata.
• Dependências não utilizadas — e esta é sorrateira. Ele detectou uma biblioteca de testes instalada nas dependencies de produção que deveria estar nas devDependencies. Isso não é apenas desordem; são bytes enviados aos usuários sem razão.

Dead code é a vitória fácil. Também é a categoria onde a auto-correção do fallow brilha, o que abordarei em breve.

Duplicação: a seção mais importante, ponto final

Esta é a que mais me importa, e é onde o código de IA está no seu pior. Fallow reporta a duplicação com faixas de linhas específicas — não "há alguma duplicação em algum lugar" mas "as linhas 412-518 aqui coincidem com as linhas 1.090-1.196 lá." Concreto. Acionável.

A funcionalidade que me fez prestar atenção foram as clone families: em vez de despejar 40 avisos de duplicatas aos pares, ele agrupa padrões recorrentes em famílias. Assim, uma lógica que o agente colou em cinco handlers de rota aparece como uma família com cinco membros, não dez pares barulhentos. Esse agrupamento é a diferença entre um relatório sobre o qual você age e um relatório que você fecha.

A duplicação funciona em dois modos, e a diferença importa:

• Modo mild (o padrão) detecta duplicatas onde os nomes de variáveis são idênticos. Conservador, poucos falsos positivos.
• Modo semântico detecta duplicatas onde a lógica é a mesma mas os nomes de variáveis diferem — exatamente o tipo de coisa que um LLM produz quando reescreve a mesma função com nomes ligeiramente diferentes cada vez. Mais rigoroso, mais completo, mais ruído.

Para um codebase com muita IA, o modo semântico é o que você quer, porque a variação de nomes de variáveis é a assinatura do LLM. Mais sobre como alternar modos abaixo.

Complexidade: a revisão de saúde que ninguém executa

Esta seção é um check-up para funções que cresceram fora de controle. Quatro números fazem o trabalho:

• Tamanho da função — marca os monstros. Eu tinha uma chegando perto de 1.500 linhas.
• Complexidade ciclomática — o número de ramificações independentes através de uma função. Uma leitura de 115 ramificações significa 115 caminhos distintos. Impossível de testar na prática.
• Carga cognitiva — quão difícil é para um humano acompanhar o código, dando peso extra a loops e condicionais aninhados. Uma bagunça aninhada pode pontuar 133 mesmo se a complexidade ciclomática parecer apenas ruim.
• Pontuação CRAP — Change Risk Anti-Patterns (Padrões Anti-Risco de Mudança). Esta é a inteligente. Ela combina complexidade com cobertura de testes. Uma função complexa que está bem testada pontua baixo — você pode alterá-la com segurança. Uma função complexa sem testes pontua brutalmente alto, porque alterá-la é cara ou coroa. CRAP é o número que te diz onde está o perigo real.

Essa última métrica reformulou como eu penso sobre dívida técnica. Não é "esta função é complexa." É "esta função é complexa e nada vai me pegar quando eu a quebrar." Esses são níveis de urgência completamente diferentes.

As pontuações: saúde, risco e a que classifica seu trabalho por você

Fallow resume tudo em alguns números compostos:

• Pontuação de saúde do arquivo — um composto de 0-100 de dead code, conectividade de import/export, complexidade e CRAP. Mais alto é mais manutenível. Você pode obter a versão do projeto com fallow health --score e receber uma nota em letra junto.
• Pontuação de risco — fortemente influenciada pelo CRAP. Este é o seu indicador de "o que tem mais chance de explodir".
• Pontuação geral do resumo — um número para toda a execução, para que você possa comparar projetos entre si ou acompanhar o mesmo repositório ao longo do tempo.

Uma pontuação sozinha é apenas uma métrica de vaidade. A seção que realmente te diz o que fazer é a próxima — e é a coisa mais inteligente da ferramenta.

A seção de hotspots: onde o fallow deixa de ser um linter

A maioria das ferramentas de qualidade te dá uma lista plana de problemas ordenados por severidade. Fallow faz algo que não vi feito de forma tão limpa: ele correlaciona a complexidade com o seu histórico de commits do git.

Pense no que isso significa. Uma função pode ser horrivelmente complexa, mas se ninguém a tocou em dois anos, ela está congelada — arriscado mudar, mas você não está mudando, então deixe-a em paz. O arquivo perigoso é o que é tanto complexo quanto modificado constantemente. Cada commit nele é um lançamento de dados, e você está lançando semanalmente.

Essa intersecção — complexidade × frequência de mudanças — é o hotspot. Você executa assim:

# Arquivos mais arriscados = frequência de mudanças no git cruzada com complexidade
npx fallow health --hotspots

A lista de hotspots é sua fila de prioridade de refatoração, ordenada por onde a limpeza dá o melhor retorno do seu tempo. Você pode até adicionar sinais de propriedade e drift (--hotspots --ownership) para ver o risco de bus factor — arquivos que apenas uma pessoa entende.

Esta é a seção que agora verifico primeiro. Não "o que está errado" mas "o que está errado e é custoso e está sendo modificado." Essa é uma pergunta fundamentalmente melhor, e é a que transforma um relatório em um plano.

Se você preferir que uma equipe audite e refatore um codebase com muita IA por você em vez de aprender as ferramentas, construir esse tipo de pipeline de limpeza é exatamente o tipo de projeto que eu aceito — mas honestamente, o fallow torna o caminho DIY realista para a maioria das equipes agora.

Colocando o fallow em um workflow real

Um relatório que você lê uma vez e esquece não vale nada. A razão pela qual o fallow ficou para mim é que ele vive em quatro lugares onde eu realmente trabalho. Isso se conecta diretamente com o ciclo de vida de desenvolvimento agêntico sobre o qual escrevi antes — as portas de qualidade precisam passar de "revisão humana ocasional" para "contínua, automatizada, legível por máquinas" quando agentes estão escrevendo a maior parte do código.

1. A CLI, filtrada para uma coisa por vez

Um relatório completo é esmagador em um repositório legado. Então você reduz. Quer apenas dead code? Apenas saúde e complexidade? Passe um filtro de métrica e o fallow mostra aquela fatia e nada mais:

npx fallow dead-code   # apenas arquivos, exportações e dependências não utilizados
npx fallow dupes       # apenas duplicação
npx fallow health      # complexidade, pontuações, hotspots

Eu ataco uma categoria por sessão. Elimino todo o dead code na segunda-feira. Ataco as piores clone families na terça. Mantém o trabalho sem parecer infinito.

2. A extensão do VS Code: deterioração, sublinhada

A extensão do fallow para VS Code executa a análise ao vivo através de um servidor de linguagem. Você ganha uma barra lateral com avisos e erros agrupados por tipo, e — a parte que eu gosto — indicadores inline direto no editor. Arquivos não utilizados e exportações não utilizadas são marcados. Linhas duplicadas ganham sublinhados ondulados, para que você veja o copy-paste enquanto passa por ele. Ele até mostra contagens de referências via CodeLens, para que você saiba de relance quantas coisas realmente usam uma dada exportação.

Ver a duplicação destacada no editor, enquanto você lê o código, impacta diferente de ler em um relatório. É a diferença entre uma nota do médico e um espelho.

3. A skill do agente de IA: código que se auto-revisa

Esta é a que genuinamente mudou meu modelo mental, e merece sua própria seção. Pule para baixo — mas primeiro, a última peça do workflow.

4. CI/CD: a porta de qualidade antes do merge

Fallow inclui um workflow pré-construído para GitHub Actions (e suporte para GitLab CI) que roda em cada push e PR. Ele posta um comentário em markdown direto no pull request resumindo o que mudou, e pode impor uma porta de qualidade — falhar a build se a pontuação de saúde cair abaixo de um limite:

# Falha o PR se a saúde do projeto cair abaixo de 70
- run: npx fallow health --min-score 70

Você escolhe se os achados são bloqueantes (inline, correção obrigatória) ou informativos (um comentário que informa sem bloquear). Um aviso da documentação que vale conhecer: GitHub Actions faz checkout com fetch-depth: 1 por padrão, o que quebra as baselines baseadas em histórico do git. Configure fetch-depth: 0 se estiver comparando com uma tag baseline de longa duração. Perdi vinte minutos com isso antes de ler as letras miúdas, então considere este seu atalho.

A funcionalidade matadora do CI, porém, é a comparação de branches. Em vez de auditar todo o seu repositório em cada PR — o que te inunda com problemas pré-existentes que ninguém vai corrigir hoje — o fallow pode comparar sua branch de feature contra main e reportar apenas os problemas novos ou modificados que sua branch introduziu. Essa é a unidade de análise correta para um PR. Você não é responsável por toda a história do codebase. Você é responsável pelo que você (ou seu agente) acabou de adicionar. Incremental, justo, e mantém o sinal limpo.

A skill do agente: deixando a IA avaliar seu próprio dever de casa — corretamente

Aqui é onde fica realmente interessante, e onde o fallow deixa de ser "um linter melhorado" e se torna algo que acredito que mais stacks agênticos vão copiar.

Há um repositório complementar, fallow-skills, que instala um módulo de skill para agentes via npx. Ele ensina um agente de IA — Claude Code, Cursor, Codex, Gemini CLI, mais de 30 deles — como invocar o fallow por conta própria e ler a saída JSON estruturada.

Reflita sobre o que isso possibilita. O agente que escreveu o código desleixado agora pode executar uma ferramenta determinística que detecta o desleixo, receber achados legíveis por máquina e corrigir sua própria saída antes que ela chegue a você. Cada problema no JSON do fallow carrega um array actions com uma flag auto_fixable — então o agente sabe não apenas o que está errado, mas se pode corrigir automaticamente.

Você pode pedir diretamente. Eu literalmente digitei no Claude Code: "Execute o fallow e me diga quais cinco arquivos eu deveria refatorar primeiro." Ele executa a análise de hotspots, analisa o JSON e volta com uma resposta classificada e fundamentada baseada em dados reais analisados — não um palpite baseado em vibes sobre seu próprio código. Essa distinção é tudo. O agente não está mais raciocinando sobre sua saída; ele está medindo.

Isso fecha o ciclo que está quebrado desde que a codificação com IA decolou. A coisa que produz a deterioração agora tem um instrumento determinístico para detectar e remover a deterioração, por conta própria, na mesma sessão. Se você está construindo workflows de agentes, skills são o mecanismo que torna esse tipo de auto-correção composável — fallow-skills é um dos exemplos do mundo real mais limpos que eu vi.

A saída JSON não é apenas para agentes, também. Qualquer script de CI pode analisá-la e agir sobre ela programaticamente. Estruturada, tipada, determinística — o oposto de pedir a um LLM que analise um diff a olho nu.

Configuração: eliminando falsos positivos antes que eles eliminem sua confiança

Um analisador estático só é útil se você confia nele, e a confiança morre no momento em que ele grita sobre coisas que você fez de propósito. Fallow te dá válvulas de escape reais. Inicialize uma configuração na raiz do seu projeto:

npx fallow init

Isso gera um arquivo de configuração que você ajusta com o tempo. (Uma nota honesta: a documentação referencia alguns formatos de configuração — JSON via algo como .fallowrc.json e uma opção TOML através de fallow init --toml. O nome exato do arquivo depende da sua versão, então verifique o que init realmente gera no seu setup em vez de confiar no nome de arquivo de qualquer blog post, incluindo este.) Veja como eu configuro:

Ignore caminhos gerados e de duplicação intencional. Eu tenho uma pasta /src/data/productinfo cheia de definições de cards geradas — cada entrada parece duplicada porque são feitas para serem uniformes. Ignorar esse caminho cortou uma quantidade enorme de ruído. O mesmo para testes: um glob **/tests/**, porque arquivos de teste duplicam configuração de propósito e tudo bem.

Escolha seu modo de duplicação deliberadamente. Modo mild padrão para uma baseline tranquila; mude para o modo semântico quando especificamente quiser caçar os clones com variáveis renomeadas que os LLMs adoram produzir.

Use overrides inline para as exceções pontuais:

// fallow-ignore  -> desativa o fallow para este arquivo inteiro
// fallow-ignore-next-line  -> pula apenas a próxima linha
export const publicApiShim = whatever // fallow-ignore-next-line

Esse último é perfeito para uma exportação que você sabe que não é usada internamente porque é uma superfície de API pública. Você reconhece, o fallow para de incomodar, e o relatório continua confiável. Um relatório em que você confia é um relatório sobre o qual você realmente vai agir — esse é todo o jogo.

A auto-correção: 20 problemas eliminados em um comando

Ler problemas é uma coisa. Corrigi-los manualmente é a parte que todo mundo pula. O comando fix do fallow lida com o mecânico automaticamente — removendo exportações não utilizadas, limpando dead code, atualizando o grafo de import/export para que nada fique pendente após uma exclusão.

Sempre faça um dry-run primeiro:

npx fallow fix --dry-run   # pré-visualize cada mudança, sem tocar em nada
npx fallow fix             # aplique as correções mecânicas e seguras

Em uma das minhas execuções, ele resolveu 20 problemas em uma única passada — principalmente exportações mortas e importações órfãs, o tedioso que eu nunca teria limpado manualmente. Ele não tenta auto-refatorar uma função de 1.500 linhas ou mesclar uma clone family; isso requer julgamento humano sobre a abstração correta, e o fallow está certo em não adivinhar. Ele corrige o que é seguro e deixa as decisões arquiteturais para você. Essa contenção é exatamente o que você quer de um auto-corretor.

Onde o fallow fica aquém (a parte honesta)

Não vou fingir que esta ferramenta é mágica, porque não é, e você me pegaria de qualquer forma na primeira vez que a executasse.

É apenas TypeScript e JavaScript. Se seu stack é Python ou Go, esta não é sua ferramenta hoje.

A camada estática não sabe o que realmente roda. Um trecho de código "morto" pode ser invocado por reflexão, uma importação dinâmica ou uma rota baseada em strings que o parser não consegue seguir. É literalmente para isso que existe a camada paga de runtime — e é por isso que você deve revisar antes de deletar, não confiar cegamente na lista de código não utilizado.

O modo de duplicação semântica produz falsos positivos. Duas funções genuinamente diferentes que compartilham uma forma serão marcadas. Você vai gastar tempo triando e vai se apoiar naquelas regras de ignore. Esse é o custo de detectar os clones sutis — não existe almoço grátis.

E ele não vai consertar sua arquitetura. Ele te diz que uma função é um hotspot de 1.500 linhas com 115 ramificações. Não vai te dizer a forma correta de decompô-la. Esse julgamento ainda é seu. Fallow aponta a lanterna; você ainda tem que limpar o cômodo.

Nada disso é um impedimento. É a forma normal de uma ferramenta afiada: ela faz uma categoria de coisas excepcionalmente e fica fora do trabalho que não pode fazer com segurança. Prefiro isso a uma ferramenta que auto-refatora meu código com confiança em algo sutilmente quebrado.

O que mudou depois que comecei a executá-lo

Não vou citar um falso "reduziu os bugs em 47%" porque não tenho esse número e nem tem ninguém que diga que tem. O que posso te dizer é o que realmente mudou na minha forma de trabalhar.

Parei de confiar em "funciona" como definição de "está pronto." A saída do agente agora recebe uma passada do fallow antes de eu lê-la, da mesma forma que eu rodaria os testes. A lista de hotspots se tornou meu backlog real de refatoração em vez de uma vaga sensação de culpa sobre "os arquivos bagunçados." E no CI, a porta de comparação de branches significa que o PR vibecoded de um colega não pode silenciosamente despejar 200 linhas de lógica duplicada no codebase sem que um comentário apareça no PR — a conversa acontece antes do merge, que é o único momento em que é barata.

O resultado realista que você deve esperar: não zero dívida, mas dívida visível, classificada e diminuindo. Você vai conhecer seus cinco piores arquivos por nome. Vai detectar a nova deterioração no PR em vez de descobri-la três sprints depois. Para uma ferramenta estática gratuita que se instala com npx, esse é um retorno notável.

A maior mudança é mental. Uma vez que uma IA está escrevendo a maior parte do seu código, seu trabalho passa de autor para editor e porta de qualidade. Fallow é uma das primeiras ferramentas construídas nativamente para esse trabalho — determinística, rápida e igualmente utilizável por você e pelo próprio agente.

Então aqui está meu desafio para as próximas 24 horas: aponte npx fallow para o repositório com muita IA do qual você mais se orgulha. Aquele que você tem certeza de que está limpo. Leia a seção de duplicação primeiro. Eu apostaria que você encontra pelo menos uma clone family que não sabia que existia — e uma vez que você a veja, não vai conseguir deixar de vê-la. Esse é exatamente o ponto.

Perguntas Frequentes

O fallow é gratuito?

Sim — toda a camada de inteligência estática do fallow é gratuita e de código aberto, cobrindo dead code, duplicação, complexidade, hotspots e análise de arquitetura. Há uma camada paga opcional de runtime que adiciona evidência de tráfego de produção para revisão de caminhos quentes e eliminação de caminhos frios, mas a camada estática gratuita é onde vive o valor do dia a dia. Execute com npx fallow, sem conta necessária.

Como o fallow é diferente do ESLint?

Fallow se concentra em falhas de manutenibilidade em todo o seu codebase — duplicação, dead code, complexidade e hotspots — enquanto o ESLint se concentra em regras de estilo e correção por arquivo. ESLint não vai marcar 100 linhas que você copiou e colou em quatro arquivos; fallow as agrupa em uma clone family com faixas de linhas exatas. São complementares, não concorrentes. Consulte as seções de duplicação e hotspots acima para ver o que o fallow detecta e os linters não.

O fallow pode auto-corrigir problemas de código gerado por IA?

O comando fix do fallow auto-resolve problemas mecânicos e seguros — removendo exportações não utilizadas, deletando dead code e atualizando o grafo de import/export — e uma única execução pode limpar mais de 20 problemas. Sempre pré-visualize com npx fallow fix --dry-run primeiro. Ele deliberadamente não auto-refatora funções gigantes nem mescla duplicatas, já que essas precisam de julgamento arquitetural humano.

O fallow funciona com agentes de IA como o Claude Code?

Sim — o módulo fallow-skills (instalado via npx) ensina agentes como Claude Code, Cursor, Codex e Gemini CLI a invocar o fallow e ler sua saída JSON estruturada. Isso permite que um agente auto-revise e auto-corrija seu próprio código antes de abrir um PR. Você pode pedir coisas como "quais cinco arquivos eu deveria refatorar primeiro?" e obter uma resposta baseada em dados. Consulte a seção da skill do agente acima para o workflow completo.

Quais linguagens o fallow suporta?

Fallow analisa projetos de TypeScript e JavaScript apenas, com cerca de 95 plugins de framework que auto-detectam stacks como Vite, Next.js, TanStack Query e Tailwind CSS. Não há suporte para Python ou Go na linha de versões 2.8x em junho de 2026. Se seu projeto é JS/TS, ele se configura sozinho na primeira execução com zero preparação.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar workflows ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (desenvolvimentos personalizados e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io