github can be found here: https://github.com/syncable-dev/syncable-cli
1 karma · joined March 29, 2026
Cracking pipelines, taming Kubernetes clusters, and turning \"works on my machine\" into \"runs everywhere.\" Currently obsessed with internal developer platforms, supply chain security, and making CI/CD feel less like a chore.
Strong opinions, loosely held — about GitOps, observability, and the right way to write a Dockerfile.
Ask me anything about pipelines, platform thinking, or why your deploy is slow.
Analysis Engine, made to engineers get a quick overview of their codebase, security scannings, vulenrability checks and dependency checks.
It also comes with skills giving Claude Code/Codex/Gemini build in native linting capabilities for Dockerfiles, Helm charts, k8s manifest alongside validation and assessment capabilities.
Still early days but would love some extra hands!
I think whats important is, that you keep atomical small tasks and increments, and whenever possible merge things. to many hanging worktrees can quickly also become a nightmare managing
The pitch is "use Claude Code without Anthropic limits." What's actually happening is you're getting GPT/Codex responses dressed up to look like Claude. Those are different models with different failure modes. If you picked Claude Code because you trust how Claude reasons about your code, this swaps it out silently. No indication at the UI level.
The ToS angle is what I'd worry about more. Anthropic isn't being hurt here, they're not serving the requests. But OpenAI is, under a Codex subscription that definitely wasn't priced for "act as someone else's backend." Using your ChatGPT sub as a proxy for a third party product is the kind of thing that gets your account killed. Could also expose you to liability, depending on how seriously OpenAI wants to push it.
The project's own disclaimer says something about how use "may be subject to the terms of service of third party platforms." That one sentence is doing a heroic amount of work.
If the real complaint is that Claude's API is too expensive, fair enough. But this doesn't solve that. It just shifts the bill and the risk onto OpenAI's infra and your account.
I think one of the bigger issues, is the o(n) orchestration to agent calls that often feels uncontrolled .. ending up making the orchestrator of sub-agents the main bottleneck due to the large context it sometimes ends up with.
I'm working on an idea where agents delivers briefs & deliveres as real artifacts, and then having each spawned sub-agent read briefs, and if they need further information pick up the delivery for that specific brief.
It helps drift detection across agents, and the best part is orchestrator only delegates jobs, but doesn't do much further than that.
Whenever sub-agents has delivered their tasks, orchestrator can then read a merged brief/delivery for that specific round.
So far it helps cutting that extra tool call where each sub-agent answers the orchestrator - but it also helps the orchestrator only dwelve into deliveries which it believes are relevant rather than trying to understand and comprehend every small detail.
I can share more when I'm a bit further maybe you could get some inspiration here.
But also ensuring you start new fresh context threads, instead of banging through a single one untill your whole feature is done .. working in small atomic incrementals works pretty good