hoakiet98

4 ms·

1.
by hoakiet98 3mo ago
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 c
2.
by hoakiet98 4mo ago
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 (trac
3.
by hoakiet98 4mo ago
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
4.
by hoakiet98 4mo ago
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 sim
5.
by hoakiet98 4mo ago
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 mor
6.
by hoakiet98 4mo ago
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
7.
by hoakiet98 4mo ago
ah very interesting will have to give gstack another try
8.
by hoakiet98 4mo ago
I think Abhi meant Dec 26, 2025
9.
by hoakiet98 4mo ago
That’s awesome to hear! Definitely some exciting stuff coming with better automations, mobile and remote workspaces
10.
by hoakiet98 4mo ago
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
11.
by hoakiet98 4mo ago
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
12.
by hoakiet98 4mo ago
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.
13.
by hoakiet98 4mo ago
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 sp
14.
by hoakiet98 4mo ago
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.
15.
by hoakiet98 4mo ago
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.
16.
by hoakiet98 4mo ago
awesome to hear this! 40-50 is definitely on the high end. Are you adding any workflow on top to manage that many?
17.
by hoakiet98 9mo ago
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.
18.
by hoakiet98 9mo ago
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 / a
19.
by hoakiet98 9mo ago
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.
20.
by hoakiet98 9mo ago
ghostty-web looks interesting. full xterm compatibility as well. will give it a try!
21.
by hoakiet98 9mo ago
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.
22.
by hoakiet98 9mo ago
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 bran
23.
Show HN: Superset – Run 10 parallel coding agents on your machine(github.com)
24 points by hoakiet98 10mo ago|3 comments
24.
by hoakiet98 1y ago
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 s
25.
by hoakiet98 1y ago
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&#x27
26.
by hoakiet98 1y ago
> 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-sour
27.
by hoakiet98 1y ago
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 no
28.
by hoakiet98 1y ago
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&#x2F
29.
by hoakiet98 1y ago
This is good feedback. I updated the Get Started video here. Thank you :) https://github.com/onlook-dev/onlook/pull/2009
30.
by hoakiet98 1y ago
In case someone else sees this thread, this is now resolved with the CSB team.

More ›