I think that paradigm is shifting a bit with agents where there are more downtime waiting for things to run. It's definitely not for everyone and the switching cost is real. We're trying to make that better with better UX / auto-summary, etc.
I've played with git worktrees a few years back but until agents it was never that practical to have more than 2 worktrees at once. Now that it is practical, solving the poor usability makes sense for us.
Appreciate your input but I don't understand what you mean here.
You had use cases before in which you wanted more than 2 worktrees at once in the past and needed to juggle between them at the speed of "practical"?
What were you doing back then (a few years back and before agents as you implied) that required this and that your solution now solves?
What poor usability are you referring to here? Is the rate of utilizing git-worktrees a metric you are measuring? That does not make sense to me.
I also watched the demo video, and I don't understand the value here. Perhaps I am not your target demographic, but I am trying to understand who is. Is this for vibe-coding side projects only? Would be nice if you had a more practical/real stakes example. The demo video did not land for me.
Hmm I guess two good questions to check to see if this tool is useful for you is 1) do you use a cli coding agent for the vast majority of your work and 2) are you interested in using more than one at once? If those two assumptions are true, I think our UI is a nice way to make the git worktree workflow (a very common path to running multiple agents) a bit easier to manage! It handles copying over environment variables for you, setting up containers, and a lot of the other small things you need to think about when using git worktrees basically.
Having a more practical video is a great call-out though, we should probably have a more deep dive video of an actual session!
Agreed. I generally see much better results for smaller, well-scoped tasks. Since there's very little friction to spinning up a worktree (~2s), I open one for any small tasks, something I couldn't do while working on a single branch.
I currently prefer Cursor to CC, does Superset play well with Cursor too? Is this a replacement for their work tree feature?
I haven’t setup worktrees yet, so if I have a quick task while working in main, I currently just spin up another agent in plan mode, and then execute them serially. In parallel would be really nice though. I often have 5-10 agents with completed plans, and I’m just slogging through executing them one at a time.
This is super interesting! Cursor CEO mentioned in interviews that they initially started with building AI for 3D models, but pivoted because they couldn't get enough data for the models to be effective.
I wonder if you think this is still true given how much better the foundation models are now.
In all the commercial mechanical CAD packages I've seen, the default libraries are pretty weak. Each organization needs to dig in to build out the standard parts libraries to cover the basics of fasteners, bearings, etc. I think the data needed for CAD AI to work properly is going to be processing the various industrial standards from SAE, DIN, ISO, AGMA, etc to properly implement standard interfaces. I suspect it is going to be more of a tool matching AI, where there are library calls that have the explicit technical definitions of various mechanical items, and the AI is coordinating them.
But a lot of the data needed to train an AI is probably locked up in user company product lifecycle management systems. Autodesk is probably going to be out front in any AI wave of CAD with all the data they are accumulating in their Fusion 360 cloud. The main question for me is whether they will pull a Kodak and not develop it for fear of cannibalizing their current market, or not.
yes i saw that! imho the latest foundation models have enabled a whole host of new possibilities. particularly improvements on SWE-BENCH and other software related benchmarks seem to translate fairly well to openSCAD as we're generating code. however there is still a lot of work to do, as these models struggle to reason spatially. gemini 2.5 is probably the best here rn.
the future of cad generation will undoubtedly extend far beyond simple code-gen to generating human-readable features. this is where the data will be important!
I think this is a cynical take on OSS. As a for-profit company, we have already commercialized the desktop version and plan on commercializing the web version as well.
I don't think this is unhealthy for open-source, and I hope we're transparent about that. The code is still free and self-hostable under Apache 2.0.
> What's up with the recent trend of YC being open source?
To be fair, we were open source before we got into YC. YC didn't mandate any business model, and the vast majority of our batchmates (empirically, 90%) were closed-source.
> Is it an ideology thing, a sign of confidence, or is it really that consumers prefer open source software?
I personally think it's a competitive advantage for distribution, differentiation, and attracting talent. Also as an engineer, I just like OSS.
It's more to keep scope small until we feel confident about the experience.
Theoretically, we can scale to other declarative frameworks, but we'd have to implement a parser for each. We're sticking with React/Next for now since that is the majority of use cases with plans of supporting other frameworks when the experience feels good enough.
There's a comment under about Svelte support as well (which is what the initial prototype supported) and I gave a similar answer there.
Maybe this is just a naive opinion it I do not get why you must target a framework at all VS just pure CSS/HTML and later allow people to convert into their framework.
I feel that at the design stage a framework should not be discussed, since that is an implementation detail.
