hoakiet98

Superset (YC P26) | Founding Engineer, Founding Design Engineer | San Francisco | ONSITE | Full-time | $175K-$225K + 1.0-1.5% equity | https://superset.sh/careers

We're building a self-improving IDE for running coding agents in parallel. Tens of thousands of engineers use it as their main IDE, at companies like Netflix, DoorDash and Wix. It's source-available: https://github.com/superset-sh/superset

We're 4 people, including 3 ex-YC CTOs. The work goes from the pty and stream transport up to the UI, all TypeScript. You'd own big features end to end and likely ship something in your first week.

Interviews: a 15 min call, 1 hr TypeScript, 1 hr system design, then a week with us in SF. We tell you where you stand within 48 hours of each step.

Email me: kiet@superset.sh

I've been sitting in the same camp recently. We maintain both an internal MCP and CLI for our app which our devs use locally. The CLI so far feels like a much smoother experience both in terms of setup, control and performance.

But i can see how MCP being able to plug into a remote agent that doesn't have terminal access is very useful. Seems like it's a best tool for the job conversation or am I missing some other advantage?

biggest thing is flexibility on what harness you use. we don't build on the claude code /codex sdk. instead, we just let you bring whatever CLI agents you prefer and just optimize the terminal experience for using CLI agents (track running / needs attention state, set up worktrees, split pane, etc)

yeah us and similar categories of tools prescribe a lot of our specific workflow for worktrees, review, code editing where iterm + tmux is much more flexible. we have to tow the line of what's useful as a built-in feature vs being very agnostic.

i do agree that there's a more novel UX than the same left sidebar with worktrees and middle chat/terminal that is not yet explored.

we've been spiking on what the UI is like to program and monitor the specific steps in the workflow from triggering agent -> planning -> coding -> review -> merge.

Conductor and t3 - We don't build on top of the SDKs and don't plan to. As a terminal first we give you the flexibility to work between the different CLI agents CC, Opencode, Codex, etc. to get the latest features.

Emdash more similar but we're planning on investing more into allowing you to script and automate the app + agents more with our CLI.

looks awesome! very interesting how similar these tools all look. i do think we're at an intermediate state here with the current UI where it doesn't scale as well for the future where triggering agents and review becomes much more important than the writing code part.

there's a lot of cases that works for me with multiple, spiking or triaging issues generally take long so i usually can kick off a few different workspaces for to check back in after a while. what i don't want to do is wait around for minutes while an agent is coding or exploring.

ah very interesting will have to give gstack another try

I think Abhi meant Dec 26, 2025

That’s awesome to hear!

Definitely some exciting stuff coming with better automations, mobile and remote workspaces

sorry to hear about the issue. we really messed up on the performance and balancing that with more features. looking into the imported projects did no projects show up on the sidebar for you?

will continue working bugs and hope you'll give it a try later in the future when the product's more stable :)

yes, bad choice on my part. the origin was i was planning for it to be a superset of all your dev tools, not thinking about apache superset at all since it was a different domain

we monetize on teams and, in the future, cloud. the bet is that teams will want to centralize their set up for this type of work, especially shared Linear, GitHub, skills, etc.

yes, we surface agent states automatically so you can see what's running or needs attention across the different workspaces. there's a set of tasks where having 5-6 running in parallel is still productive for me such as running spikes and fixing small issue.

As we're investing more into integration test and self-validating for the agents we're able to increase the number without sacrificing quality.

biggest difference is it's terminal first, and optimized for CLI agents. we don't prescribe a specific harness and instead try to work with any CLI harness you bring.

yes, it's essentially a terminal with extra agent hooks tracked and more customized review flow. if it runs in a terminal it runs in Superset.

awesome to hear this! 40-50 is definitely on the high end. Are you adding any workflow on top to manage that many?

I'm obviously biased but in my bubble this is where things are shifting. Similar to tabbing vs typing debate, just another way to move faster.

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 think you get dirty PRs like that which makes partial rollback more difficult. Isolating changes in separate PRs is much cleaner in my experience.

ghostty-web looks interesting. full xterm compatibility as well. will give it a try!

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.

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.

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.

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.

https://news.ycombinator.com/item?id=44127653

I would say we're much more focused on the infinite canvas and Figma-like experience. We also do not build on top of WebContainer [1], which is commercially restrictive and closed source [2].

1. https://webcontainers.io/enterprise

2. CodeSandbox is also not open source, but I'm planning on adding other providers/local container options

This is good feedback. I updated the Get Started video here. Thank you :)

https://github.com/onlook-dev/onlook/pull/2009

In case someone else sees this thread, this is now resolved with the CSB team.