Live data from Hacker News

Show HN: Sculptor – A UI for Claude Code

imbue.com

21–30 of 92 posts

Re: Show HN: Sculptor – A UI for Claude Code

#21
post #19

Even design wise this looks virtually identical to https://terragonlabs.com/

Imbue team member here. The biggest difference between Sculptor and Terragon is the collaboration model. With Terragon, the agent outputs PRs. This works well for simple tasks that agents can one-shot, but is a bit clunky to use for more complex tasks that require closer human-agent collaboration imo. On the other hand, Sculptor is designed for local collaboration. Our agents run in containers too, but we let you (bidirectionally) sync to the containers, which lets you stream in the agent's uncommitted changes, and collaborate in real time. So basically, it feels like you are using Claude Code locally, but you get the safety and parallelism of running Claude in containers. I find this much more usable for real world engineering tasks!

Re: Show HN: Sculptor – A UI for Claude Code

#24
post #11

Wasn't imbue training models for coding having raised a huge fund? Is this a pivot?

Since our launch 2 years ago, we've focused more on the "agents that code" part of our vision (so that everyone can make software) rather than the "training models from scratch" part (because there were so many good open source models released since then)

This is from our fundraising post 2 years ago:

> Our goal remains the same: to build practical AI agents that can accomplish larger goals and safely work for us in the real world. To do this, we train foundation models optimized for reasoning. Today, we apply our models to develop agents that we can find useful internally, starting with agents that code. Ultimately, we hope to release systems that enable anyone to build robust, custom AI agents that put the productive power of AI at everyone’s fingertips.

- https://imbue.com/company/introducing-imbue/

We have trained a bunch of our own models since then, and are excited to say more about that in the future (but it's not the focus of this release)

Re: Show HN: Sculptor – A UI for Claude Code

#26

got to try this a bit and really liked the UI! It felt very transparent and understandable even for someone without a coding background

Thanks!

Please feel free to join discord if you run into any bugs or have any issues at all, we're happy to help: https://discord.gg/sBAVvHPUTE

Suggestions welcome too!

Re: Show HN: Sculptor – A UI for Claude Code

#27
It's not clear to me what a "container" and "pairing" is in this context. What if my application is not dockerized? Can Claude Code execute tests by itself in the context of the container when not paired? This requires all the dependencies, database, etc. - do they all share the same database? Running full containerized applications with many versions of Postgres at the same time sounds very heavy for a dev laptop. But if you don't isolate the database across parallel agents that means you have to worry about database conflicts, which sounds nasty.

In general I'm not even sure if the extra cognitive overload of agent multiplexing would save me time in the long run. I think I still prefer to work on one task at a time for the sake of quality and thoroughness.

However the feature I was most looking forward to is a mobile integration to check the agent status while away from keyboard, from my phone.

Re: Show HN: Sculptor – A UI for Claude Code

#30
post #27

It's not clear to me what a "container" and "pairing" is in this context. What if my application is not dockerized? Can Claude Code execute tests by itself in the context of the container when not paired? This requires all the dependencies, database, etc. - do they all share the same database? Running full containerized applications with many versions of Postgres at the same time sounds very heavy for a dev laptop. B…

in this context, the container contains the running claude instance, and pairing synchronizes its worktree with your local worktree.

under sculptor, claude code CAN execute tests by itself when not paired. that will also work for non-dockerized applications.

sharing a postgres across containers may require a bit of manual tweaking, but we support the devcontainer spec, so if you can configure e.g. your network appropriately that way, you can use a shared database as you like!

regarding multiplexing: the cognitive overhead is real. we are investigating mechanisms for reducing it. more on that later.

regarding mobile integration: we also want that! more on that later.

Post reply on HN