Launching today
Singularity
Run AI coding agents in parallel, one ticket at a time
37 followers
Run AI coding agents in parallel, one ticket at a time
37 followers
Chatting with AI coding agents burns context and time. Singularity replaces the chat with atomic tickets: one scope, one isolated Git worktree, minimal context. Run agents in parallel across repos, review the diff, merge. Free, local-first, bring your own key.
Free
Launch Team
Customer.ioAutomate Messaging Everywhere — Startups Get 12 Months Free
Promoted
I use conductor, how does it compare ?
Hey @bengeekly , Singularity don't use conversation with ai but instruction. So the AI ask question only in required cases.
Also we use kanban, AI product proof of work, build, merge and test.
I created Singularity after a test of Conductor. I need AI work on multiple project at the same time (frontend, backend, ci/cd) and when i change "workspace", some project use same project (backend can be used by an mobile app or frontend) and AI will work only on your workspace.
I don't know if conductor act like this today but I remember Conductor want github connexion. Here you don't need anything, A project create a git repository if it's needed but you can choose your provider and follow your gitgraph without software like fork or gitkraken.
Can tickets depend on each other, or does each agent always work independently?
Hello @johnnie_kuvalis ,
It depends. Every ticket is first prequalified by a quick AI request, and the AI has access to all the tickets in your workspace. If a development needs to build on previous work, the ticket is flagged as dependent on that other ticket.
Otherwise, tickets can run independently: the AI and Singularity merge the work without merge conflicts.
the 2 messages per ticket number is the part I'd want to pressure-test before trusting this. that's believable for self-contained tickets (add a field, fix a lint rule) but the tickets that actually eat my time are the ones where the fix touches three files I didn't expect and the agent needs a round of "no, not like that" before it lands. does the isolated-worktree model hold up when 8 parallel tickets turn out to overlap in the same file, or is the merge step where all the actual babysitting just moves to instead of disappearing?