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
PrivOSChat, Docs, Kanban Tasks and AI agents that act, self-hosted
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.
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?
Hello @galdayan , great question. Singularity is built to go straight to the goal of the ticket and avoid the back-and-forth as much as possible.
The key is tests: for each ticket, Singularity tends to write unit and end-to-end tests that lock in the requested behavior. So when 8 parallel tickets overlap in the same file, the merge isn't just about resolving text conflicts, it's about keeping every ticket's tests green. Each intended behavior is preserved because it's encoded in tests, not just in the diff.
On top of that, git hooks are supported natively. You can ask Singularity to set up hooks (lint, tests, anything you need), and every ticket has to pass them before it commits and merges.
For what it's worth: across 5000+ tickets so far, I haven't hit a single merge conflict Singularity couldn't resolve on its own. Happy to show you a run with overlapping tickets if you want to see it in action.
@antony_kervazo_canut tests passing is reassuring but it doesn't fully answer the overlap case for me - two tickets can both pass their own tests and still disagree on what the shared function should do, since neither ticket's tests know the other ticket exists. does Singularity flag that kind of semantic conflict (not a text conflict, a "both green but contradictory" one) before merging, or does a human still need to eyeball it? would take you up on seeing a real overlapping run if you post one
@galdayan In fact, Singularity can run tests to validate behavior correctly. It acts as its own test harness, replacing the one initially set up by tools like Claude Code, Codex, or Cursor.
It is important to note that during the ticket pre-qualification phase—which occurs when the ticket is being written—the AI reviews all active tickets. If any involve overlapping functionality, Ticket A becomes a blocker for Ticket B; consequently, the AI will only begin work on Ticket B once Ticket A is complete.
As a result, the code generated for Ticket B within its worktree will already include the code produced by Ticket A.
Furthermore, if you write a ticket containing multiple features, Singularity uses its harness to break those features down into separate tickets. These can then be executed either concurrently or sequentially, depending on their dependencies.
The resulting parent ticket is placed on hold, and its role becomes verifying the correct implementation of the child tickets.
@galdayan The pre-qualification step simply checks whether the work associated with two tickets might overlap. It is extremely lightweight and incurs negligible token costs. It does not examine the source code. However, since the user retains the right to force two competing tickets to run concurrently, Singularity provides the AI with a mechanism to resolve potential ticket-merging issues.
It is worth noting that, because a ticket is linked to a worktree located in a specific spot at the time of merging, the AIs have access to the other tickets. Consequently, in the event of a merge conflict, the AI examines the code to understand the logic while also checking the ticket associated with the worktree—specifically its ticket number—to discern the underlying intent.
This is how I avoid merge issues across a vast volume of tickets—some running simultaneously—that the pre-qualification step might have missed.