Claudeex testado: Claude Code e Codex em um loop de planos

Claudeex testado: Claude Code e Codex em um loop de planos

O plano parecia limpo. Doze etapas numeradas. Diagrama de arquitetura em markdown. Ordem de migração do banco de dados explicada. Eu estava prestes a clicar em "implementar" quando me lembrei que tinha o Claudeex instalado, então decidi deixá-lo rodar antes de enviar qualquer coisa.

A primeira rodada voltou com sete questões. Três deles eram sérios. Um deles - "o plano chama um webhook antes que a linha do banco de dados exista" - teria me custado uma tarde inteira de depuração às 23h de uma terça-feira. O plano que eu estava prestes a enviar tinha uma condição de corrida incluída na etapa quatro.

Foi nesse momento que parei de pensar no Claudeex como uma curiosidade e comecei a pensar nele como o tipo de coisa que eu deveria estar executando nos últimos seis meses.

Se você ainda não viu - Claudeex é um pequeno bash e chicote YAML que transforma Claude Code e a CLI OpenAI Codex em um loop de planejamento. Claude Code elabora um plano, Codex o audita, Claude Code revisa, Codex audita a revisão e assim por diante até atingir um limite redondo configurável. O padrão são três rodadas. A coisa toda depende do gancho de parada do Claude Code, que pausa a execução entre os turnos para que o script bash possa desembolsar para codex exec para a aprovação de auditoria.

Passei as últimas duas semanas executando-o no trabalho real do cliente - uma página de análise de visitantes, um refatorador de webhook do Stripe, um pequeno painel de administração do Laravel - e há o suficiente aqui para que eu queira examinar o que funciona, onde as costuras aparecem e por que os loops de planejamento de dois modelos estão prestes a se tornar o padrão para qualquer coisa mais complexa do que um formulário CRUD.

O que Claudeex realmente é (além do README)

A proposta é direta: Claude Code é bom em elaborar planos, Codex é bom em encontrar buracos neles, e a maioria dos bugs de planejamento são detectáveis se você apenas tiver um segundo modelo lendo o plano com um olhar crítico. Então, em vez de pedir a você para ser o segundo modelo, o Claudeex automatiza as idas e vindas.

Mecanicamente, são quatro peças:

1. Um iniciador bash que recebe um prompt, grava um arquivo de estado YAML e inicia Claude Code com a configuração do gancho direito carregada
2. Um arquivo de estado YAML que rastreia o prompt, o total de rodadas, a iteração atual e quaisquer arquivos de contexto fixados (como scope.md ou architecture.md)
3. Um gancho de parada Claude Code que é acionado depois que Claude termina um turno de planejamento, lê o arquivo de estado e decide se invoca Codex ou deixa Claude terminar
4. Três comandos de barra — /plan, /review e /cancel — além de um /rollback para limpar o estado do plano quando você quiser uma lousa limpa

O gancho de parada é a parte inteligente. O gancho de parada é acionado uma vez por turno quando Claude termina de responder de Claude Code, e um gancho de parada que sai com o código 2 força Claude a continuar trabalhando. Claudeex usa esse truque exit-2 para injetar a transcrição de auditoria Codex de volta na conversa como se o próprio Claude tivesse recebido feedback de um revisor e, em seguida, pede a Claude para revisar. De dentro do contexto de Claude Code, parece apenas outra virada – mas a virada contém uma crítica estruturada de um modelo de fronteira diferente.

Se você leu meu detalhamento do fluxo de trabalho de dois agentes Claude Code e Codex, o modelo mental é semelhante. A diferença é que Claudeex incorpora o loop na própria sessão Claude Code - você não precisa canalizar manualmente as transcrições entre terminais ou copiar e colar críticas. O gancho faz isso.

Por que o planejamento de dois modelos supera o planejamento de um modelo

Quero ter cuidado aqui porque o enquadramento óbvio – “dois modelos são melhores que um” – é o tipo de afirmação vaga que eu normalmente cortaria de um rascunho. Então, deixe-me ser específico sobre o que realmente muda.

Quando Claude Code elabora um plano sozinho, ele está operando a partir de uma única distribuição de "como são bons planos". Tem seus próprios preconceitos de treinamento. Tem seus próprios pontos cegos. Quando peço para "verificar novamente o plano", estou essencialmente sendo solicitado a discordar de si mesmo, algo em que os modelos de linguagem são notoriamente ruins. Há pesquisas sobre bajulação e autoconsistência que explicam o porquê – modelos treinados com RLHF tendem a se comprometer com sua primeira resposta e depois defendê-la, mesmo quando solicitados a criticar.

Codex é um modelo diferente com um pipeline de treinamento diferente. O modelo de produção atual na CLI Codex é GPT-5.5 (com GPT-5.4 como substituto se sua conta ainda não tiver sido alterada). Quando Codex audita um plano de autoria de Claude, ele está lendo prosa escrita em um estilo cognitivo ligeiramente diferente e está muito mais disposto a sinalizar coisas que Claude encobriram. A assimetria é o valor. Codex captura coisas que Claude escreveu; Claude captura coisas que Codex teria perdido se tivesse elaborado o plano.

Na prática, nos projetos que executei Claudeex nas últimas duas semanas, a taxa de captura de bugs em estágio de planejamento está em torno de 80% nas primeiras duas a três rodadas. Após a terceira rodada, os retornos marginais diminuem – Codex começa a sinalizar preferências estilísticas em vez de problemas reais. É por isso que o padrão de três rodadas está correto. Tentei defini-lo como cinco em um trabalho complexo e a quarta rodada foi Codex discutindo se deveria usar um enum ou uma string para um campo de status. A quinta rodada foi Codex mudando de ideia sobre a quarta rodada. Três rodadas é o ponto ideal.

A superfície de slash commands

Existem quatro comandos de barra e você só precisa de dois deles no dia a dia.

/plan <prompt> é o carro-chefe. Você entrega uma descrição do que deseja construir, opcionalmente fixa alguns arquivos de contexto como scope.md ou architecture.md e o loop é executado. Rascunhos de Claude, auditorias de Codex, revisões de Claude. No final você obtém um plano final com as exclusões e adições de cada rodada mostradas em vermelho e verde para que você possa ver como o plano evoluiu. Se você já fez uma revisão séria do código e observou a transformação PR de um engenheiro júnior entre v1 e v3, a visualização diff é exatamente assim.

/review é a versão somente leitura. Ele pega um plano existente – um que você escreveu, um que um colega de equipe escreveu, um Claude escreveu em uma sessão anterior – e executa Codex sobre ele sem qualquer etapa de revisão. Você recebe os comentários da auditoria e pronto. Eu uso isso em planos que estou prestes a entregar a outro desenvolvedor; é uma segunda opinião barata antes do início do trabalho.

/cancel é uma parada de emergência. Se o loop sair dos trilhos - Codex começa a alucinar dependências, Claude começa a reescrever a mesma seção em círculos - você pode interromper a execução de forma limpa, sem deixar o arquivo de estado YAML em um meio estado quebrado.

/rollback apaga completamente o estado do plano. Útil quando você deseja recomeçar do zero sem reiniciar o Claude Code.

A sintaxe é mais importante do que você esperaria. A primeira vez que executei o /plan, dei uma mensagem de uma frase - "crie uma página de análise de visitantes que não use terceiros". Claude escreveu um plano razoável, mas genérico. Codex auditou e o primeiro comentário foi "o prompt é muito vago para avaliar; qual é o critério de sucesso?" Isso é um recurso, não um bug. A ferramenta opcional de solicitação de entrada do usuário que acompanha o Claudeex existe especificamente para esses momentos - quando um prompt é muito vago para ser planejado, ele pausa o loop e faz perguntas esclarecedoras antes de continuar. Aprendi a liderar com /plan mais um parágrafo de contexto e um scope.md fixado, e a qualidade de cada rodada depois disso melhorou visivelmente.

Qual é a aparência real do Bash e do YAML

O iniciador é pequeno o suficiente para ler de ponta a ponta. Aqui está o formato dele, com o corte de ruído:

#!/usr/bin/env bash
set -euo pipefail

PROMPT="$1"
ROUNDS="${2:-3}"
STATE_FILE=".claudeex/state.yaml"

mkdir -p .claudeex

cat > "$STATE_FILE" <<EOF
prompt: |
  $PROMPT
rounds_total: $ROUNDS
rounds_completed: 0
phase: drafting
context_files:
  - scope.md
  - architecture.md
EOF

claude --hook-config .claudeex/hooks.json \
       --slash-command "/plan $PROMPT"

Esse é todo o ponto de entrada. Todo o resto reside na configuração do gancho e no arquivo de estado. A configuração do gancho registra um gancho de parada apontado para um pequeno script de shell:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": ".claudeex/audit.sh"
          }
        ]
      }
    ]
  }
}

E audit.sh é a ponte para Codex. O script lê o estado YAML, verifica a fase atual e a contagem de rodadas e decide se invoca Codex ou deixa Claude terminar:

#!/usr/bin/env bash
set -euo pipefail

STATE_FILE=".claudeex/state.yaml"
ROUNDS_TOTAL=$(yq '.rounds_total' "$STATE_FILE")
ROUNDS_DONE=$(yq '.rounds_completed' "$STATE_FILE")
PHASE=$(yq '.phase' "$STATE_FILE")

if [ "$PHASE" = "drafting" ] && [ "$ROUNDS_DONE" -lt "$ROUNDS_TOTAL" ]; then
  PLAN=$(cat .claudeex/plan-current.md)
  CRITIQUE=$(codex exec "Audit this plan for correctness, missing edge cases, race conditions, and broken dependencies. Be specific. Cite line numbers." --input "$PLAN")

  echo "$CRITIQUE" > .claudeex/critique-round-$((ROUNDS_DONE + 1)).md
  yq -i ".rounds_completed = $((ROUNDS_DONE + 1))" "$STATE_FILE"

  # Exit 2 forces Claude Code to keep working with the critique injected
  cat <<EOF >&2
Round $((ROUNDS_DONE + 1)) audit from Codex:

$CRITIQUE

Please revise the plan addressing each point.
EOF
  exit 2
fi

exit 0

O padrão exit-2 está fazendo todo o trabalho pesado. Como a referência de ganchos Claude Code descreve, um gancho de parada saindo com status 2 força Claude a continuar trabalhando, com a saída stderr do gancho injetada de volta na conversa. Claudeex usa isso para alimentar a crítica de Codex de volta a Claude como se fosse uma nova virada - e Claude responde revisando o plano em vigor.

Vale dizer: isso é fita adesiva, mas é fita adesiva boa. O sistema de gancho não foi projetado para loops adversários de modelos cruzados. Ele foi projetado para coisas como "formatação automática na edição" ou "bloqueio de comandos perigosos". O fato de poder ser reaproveitado para algo tão elaborado é uma pequena prova de quão bem os primitivos foram escolhidos.

A demonstração que criei para testar a resistência

Eu precisava de um caso de teste real, então escolhi algo que realmente pretendia entregar: uma ferramenta de análise de visitantes de página única que rastreia as interações em meu site sem enviar dados a nenhum serviço de terceiros. Sem Google Analytics, sem Plausível, sem Fathom. Apenas meu próprio back-end coletando cliques, rolagens e tempo na página de meus próprios visitantes.

A razão pela qual este é um bom caso de teste Claudeex é que ele fica em uma estranha interseção entre instrumentação de front-end, armazenamento de back-end e lei de privacidade. Existem pelo menos quatro maneiras de errar, e a maioria dessas maneiras são erros de planejamento, não erros de codificação. Você pode escrever o JavaScript corretamente e ainda assim enviar algo ilegal sob GDPR. Você pode projetar o esquema do banco de dados corretamente e ainda criar um sistema que trave a página em redes lentas. Os bugs se escondem no upstream do código.

Fixei dois arquivos de contexto: scope.md (requisitos funcionais, incluindo a regra "sem terceiros" e uma lista de eventos a serem rastreados) e architecture.md (um esboço da stack - backend Laravel, frontend JS vanilla, MySQL para armazenamento, Redis para buffer de eventos de alta frequência). Então eu corri:

/plan Build a visitor interaction tracking page following scope.md and architecture.md. Plan should cover schema, frontend instrumentation, backend ingestion, and the consent flow.

Cerca de 15 a 20 minutos de iteração depois, eu tinha um plano que realmente enviaria. A primeira rodada produziu um primeiro rascunho razoável que ignorou completamente o fluxo de consentimento – Claude tratou GDPR como uma nota de rodapé em vez de um requisito de restrição. A crítica da primeira rodada de Codex começou com "o fluxo de consentimento está totalmente ausente; sem ele, nenhum evento deveria ser acionado", que é exatamente o tipo de coisa que teria me incomodado na produção. A segunda rodada adicionou o portão de consentimento, mas introduziu um problema diferente: ele tinha eventos de buffer de frontend em localStorage antes do consentimento ser concedido, o que é em si uma violação GDPR em algumas interpretações. Codex percebeu isso na segunda rodada. A terceira rodada teve uma versão limpa em que o frontend não armazena nada até que o consentimento seja dado e, em seguida, libera uma fila de eventos gravados com intenção para o backend.

A visão diferente no final foi a parte que mais me surpreendeu. Claudeex mostra o plano com exclusões riscadas em vermelho e acréscimos destacados em verde, rodada por rodada. Você pode ver exatamente o que a auditoria detectou e onde o plano foi fortalecido. É a coisa mais próxima que vi de uma experiência de revisão de código para planos, em vez de código.

Claudeex vs Claude Code sozinho

Aqui está a comparação à qual sempre volto. Depois de duas semanas executando ambos – às vezes o mesmo prompt em ambos, às vezes alternando com base na complexidade do projeto – as diferenças se classificam em um padrão claro.

recursos de íon, trabalho sensível à segurança, qualquer coisa que envolva dados |

O custo do token é real e vale a pena ser honesto. Três rodadas de planejamento Claude mais três rodadas de auditoria Codex não são gratuitas. Para um script rápido ou protótipo, a sobrecarga não vale a pena - você pode simplesmente executar um plano, digitalizá-lo você mesmo e enviá-lo. Para qualquer coisa em que um bug de planejamento custaria mais de 30 minutos de depuração, o Claudeex se paga no primeiro salvamento.

O comportamento de esclarecimento é o benefício subestimado. A ferramenta opcional de solicitação de entrada do usuário transforma solicitações vagas em conversas produtivas, em vez de planos errados. Na minha experiência, cerca de um terço dos prompts que escrevo são muito vagos para serem planejados - e Claudeex é a primeira ferramenta que usei que detecta isso de forma consistente antes de gerar um plano que interpreta mal o que eu queria.

Se você quiser uma comparação relacionada, o fluxo de trabalho de dupla dinâmica do plug-in Claude Code e Codex é a versão manual do que Claudeex automatiza. A rota do plugin é mais flexível; Claudeex é mais opinativo. Eu uso os dois, dependendo do trabalho.

Onde Claudeex fica aquém

Quero ser honesto sobre isso porque, de outra forma, o artigo seria inútil.

É frágil em contextos longos. Quando o plano e a transcrição da auditoria ficam longos o suficiente – algo além de 30.000 tokens combinados – Claude começa a perder o controle de em qual rodada está e às vezes regenera seções inteiras que Codex já aprovou. Este é um problema de gerenciamento de contexto, não um bug Claudeex em si. Mas é na costura que fica a fita adesiva.

O arquivo de estado YAML não é ótimo para trabalho paralelo. Se você tentar executar duas sessões Claudeex no mesmo repositório ao mesmo tempo, elas atropelarão os arquivos de estado uma da outra. Não há isolamento por sessão por padrão. Eu contornei isso criando subdiretórios por recurso, mas é uma verdadeira verruga.

Codex às vezes alucina dependências. Isso acontece aproximadamente uma em cada dez rodadas. Codex criticará um plano por "perder a configuração do Redis Streams" quando o plano não precisa realmente do Redis Streams. Claude, dada essa crítica, adicionará de forma útil a configuração do Redis Streams. Acabamos por ter um plano mais complexo do que o necessário, com infra-estruturas introduzidas por uma alucinação de auditoria. A solução é ler você mesmo as diferenças de cada rodada e rejeitar alterações que não correspondam à realidade. O que significa que Claudeex na verdade não remove o humano do loop - apenas facilita o trabalho do humano.

Não é mágico para trabalho greenfield. Quando você não tem um scope.md ou um architecture.md para fixar, as primeiras rodadas do loop passam muitos ciclos discutindo sobre o escopo. Claudeex funciona melhor quando você já fez o pensamento estratégico e deseja ajuda com o planejamento tático. Se você ainda está descobrindo o que construir, o loop não o ajudará a decidir. Isso apenas continuará refinando um plano para a coisa errada.

A assimetria do modelo pode mudar. Codex é bom em auditorias na maioria das vezes. Mas quando o tópico se volta para as áreas mais fortes do Claude - qualquer coisa relacionada a ferramentas específicas do Antrópico, fluxos de trabalho de agentes ou o próprio sistema de ganchos do Claude Code, por exemplo - o rascunho do Claude às vezes é melhor do que a auditoria do Codex. Nesses casos, o loop adiciona ruído em vez de sinal. Você aprende a reconhecer quando está em uma dessas zonas e apenas executa /plan uma vez sem a etapa de auditoria ou usa /review com um limite de terceira rodada mais longo.

Além do código: onde mais esse padrão funciona

O que realmente me surpreendeu é o quão bem o padrão se estende ao código anterior. Tenho testado Claudeex em tarefas de planejamento sem código na última semana e os resultados são interessantes o suficiente para serem mencionados.

Eu o apresentei em um esboço de apresentação de slides para um workshop que darei em maio. O primeiro rascunho de Claude era sólido – um fluxo lógico, detalhamentos de seções decentes, estimativas de tempo razoáveis. A auditoria do Codex sinalizou que o workshop não tinha exercícios no terço médio, o que significaria 40 minutos de conversa direta após o pico de energia por volta do minuto 25. Eu não tinha percebido. Eu teria percebido no ensaio, mas o ensaio teria acontecido na noite anterior. Claudeex pegou antes que eu perdesse qualquer tempo de preparação.

Executei-o em uma especificação de recurso para um cliente freelance - não no código, apenas no documento de descrição do recurso que estava incluído na proposta. A primeira rodada passou. Na segunda rodada, Codex sinalizou que o documento descreveu o caminho feliz, mas nunca mencionou o que acontece quando o API de terceiros está inativo. O cliente assinou uma v3 que incluía um parágrafo de degradação elegante. Esse parágrafo agora faz parte contratualmente do que devo a eles.

Ainda não experimentei em modelos Excel ou documentos financeiros, mas não vejo razão para que não funcione. O padrão é genérico: em qualquer lugar onde você possa escrever um plano em markdown e pedir a outro modelo para auditá-lo, o loop se aplica. É aqui também que vejo convergência com o padrão mais amplo que abordei no modo ultraplano do Claude Code - ambos tratam de formalizar a etapa de planejamento em vez de tratá-la como um preâmbulo de codificação orientado por vibrações.

Configuração, custo real e como executá-lo

Colocá-lo em execução leva cerca de dez minutos se o seu ambiente já estiver configurado.

Pré-requisitos:

• Claude Code instalado e conectado
• CLI Codex instalada (npm i -g @openai/codex ou brew install --cask codex) e conectada
• yq instalado (brew install yq no macOS)
• Um repositório onde você deseja executá-lo

Instalar:

git clone <claudeex-repo-url> .claudeex
chmod +x .claudeex/*.sh

Primeira execução:

.claudeex/run.sh "build a visitor analytics page following scope.md"

Na primeira vez, espere de 15 a 20 minutos para um plano moderadamente complexo. A CLI Codex usará qualquer modelo ao qual sua conta tenha acesso – GPT-5.5 se você estiver no mais recente, GPT-5.4 se não. Ambos funcionam bem para críticas de estilo de auditoria; GPT-5.5 é significativamente mais nítido na detecção de problemas sutis.

Em termos de custo, um loop de três rodadas em um plano moderadamente complexo custa cerca de três a quatro vezes o custo de um único turno de planejamento Claude Code. Para trabalhos freelance e de clientes, isso é um erro de arredondamento. Para experimentos pessoais, você pode querer executá-lo apenas nos problemas mais difíceis e deixar o /plan (sem o loop) lidar com as pequenas coisas.

O que executar primeiro: qualquer recurso em que um erro de planejamento custaria mais de meio dia de retrabalho. Fluxos de autenticação. Integrações de pagamento. Migrações de dados. Qualquer coisa com simultaneidade. Qualquer coisa que toque em GDPR ou HIPAA. Estas são as áreas onde 15 minutos de auditoria automatizada se pagam dez vezes mais. Se você estiver realizando um trabalho adjacente à segurança, a mesma lógica se aplica — e o padrão do agente de varredura de segurança em Claude Code emparelha naturalmente com Claudeex no lado do planejamento.

Ignore: correções de bugs onde o bug já está isolado, pequenos ajustes na interface do usuário, qualquer coisa que você tenha feito antes e possa escrever o plano enquanto dorme. A sobrecarga não vale a pena.

Perguntas frequentes

O que é Claudeex e como funciona?

Claudeex é um loop de planejamento iterativo onde Claude Code elabora um plano, a CLI OpenAI Codex o audita e Claude Code revisa - repetindo para um número configurável de rodadas (três por padrão). Ele usa um gancho de parada Claude Code com código de saída 2 para injetar a crítica de Codex de volta na conversa como se fosse um novo turno. Para obter um passo a passo completo da implementação do bash e do YAML, consulte a seção acima sobre o inicializador e o script de auditoria.

Quantas rodadas o Claudeex precisa para detectar a maioria dos bugs de planejamento?

Duas a três rodadas detectam cerca de 80% dos bugs de planejamento em meus testes. A quarta rodada e além produzem retornos decrescentes e muitas vezes trazem à tona preferências estilísticas em vez de questões reais. O padrão de três rodadas está bem ajustado. Consulte a tabela de comparação acima para obter o contexto completo sobre tempo e custo do token.

Claudeex funciona para tarefas de planejamento sem código?

Sim. O padrão funciona para qualquer plano escrito em markdown que outro modelo possa auditar – esboços de slides, especificações de recursos, propostas de projetos. Eu testei em apresentações de workshops e especificações de clientes freelance com bons resultados. A seção "Além do Código" acima apresenta exemplos específicos.

Qual é a diferença entre /plan e /review em Claudeex?

/plan executa o loop iterativo completo: rascunhar, auditar, revisar, repetir. /review é somente leitura – ele executa Codex uma vez em um plano existente e retorna os comentários de auditoria sem qualquer etapa de revisão. Use /review quando quiser uma segunda opinião sobre um plano que você ou um colega de equipe já escreveu.

Claudeex vale o custo extra do token?

Para recursos de produção, trabalhos sensíveis à segurança ou qualquer coisa em que um bug de planejamento custaria mais de 30 minutos de depuração – sim. O custo do token de 2,5–3x se paga na primeira vez que detecta uma condição de corrida. Para protótipos, scripts descartáveis ​​ou trabalhos que você já realizou muitas vezes, a sobrecarga não se justifica.

O que eu tirei

Na manhã seguinte à minha primeira execução real do Claudeex, voltei e olhei três planos que havia enviado no mês anterior - planos com os quais fiquei satisfeito na época. Executei cada um deles em /review para ver o que Codex teria capturado.

Todos os três tiveram pelo menos um problema. Dois tiveram condições de corrida que eu perdi. Um deles tinha um caminho de reversão ausente em uma migração destrutiva que, para ser justo, teria sido detectado na revisão do código – mas apenas se o revisor estivesse prestando muita atenção. Nenhum deles foi catastrófico. Todos os três teriam sido menos embaraçosos se a auditoria tivesse sido realizada antes do meu envio, em vez de duas semanas depois, em retrospectiva.

Essa é a parte que me pegou. Não a demonstração. Não a visão diferente. A percepção de que eu estava enviando planos de qualidade média e os chamando de concluídos porque nada em meu fluxo de trabalho os impedia. Claude Code não recua. Não recuo, porque escrevi o aviso e estou torcendo para que o plano seja bom. A única coisa neste loop que não tem skin no jogo é Codex.

O modelo que não se importa se o seu plano é bom é o modelo que você deseja auditar.

O plano que quase enviei antes de instalar o Claudeex – aquele com a condição de corrida incluída na etapa quatro – teria passado por mim. Teria passado de Claude. Não teria passado de Codex, porque Codex não o escreveu e não tinha motivos para defendê-lo. Essa é a assimetria que o loop está explorando, e é essa assimetria que faz com que valha a pena executá-lo.

Esta noite, antes de enviar o próximo plano que você está prestes a enviar, execute-o em um segundo modelo. Se você tiver o Codex instalado, faça isso manualmente. Se você quiser automatizar, instale Claudeex. De qualquer forma – deixe algo que não se importa com o seu plano lhe dizer o que há de errado com ele. Você não vai se arrepender dos dez minutos.

Vamos trabalhar juntos

Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.

• Fiverr (comstackções e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e marca): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io