Live data from Hacker News

Show HN: Oak – Git alternative designed for agents

oak.space

201–210 of 216 posts

Re: Show HN: Oak – Git alternative designed for agents

#202

Anything "for agents" needs to provide some kind of evidence it's better than what the agents already have baked into the model training data. It can't just be "easier" on some dimension, because the model has already learned the hard parts of the old thing and models can't make new memories to learn new things, so there is always a context cost for the new thing. Models know git because there's a monstrous amount of…

* It dramatically improves the speed and context your agents need when working on serious projects: 50% fewer VCS-related tokens and 90% faster per operation.

Sounds like a good optimization to me. VCS is a waste of tokens for sure. I’m intrigued to hear more.

Re: Show HN: Oak – Git alternative designed for agents

#203
post #68

I have absolutely no idea what this offers that makes it better than git (or any over VCS for that matter) for agents. There’s some mention about performance, which is great, but the performance of git isn’t a bottleneck for agents. There’s some mention about token use being reduced, which is great, but how have they achieved that vs gits porcelain modes. And why does token count require a whole new VCS, and thus inc…

The main site mentions being able to "mount" a branch, vs. cloning a new repo or using git worktrees. And messageless commits for intermediate work. Besides that tho I don't see a compelling reason to ditch git, but looks interesting enough that I want to keep an eye on it

[dead]

Re: Show HN: Oak – Git alternative designed for agents

#204

How is downloading stuff remotely the bottleneck here?

Agents in the cloud (and locally) need to have a full repo, even if they only need a small percentage of a repo to make a change. You can also imagine if changes are being made in the cloud by multiple agents, each one of these agents need a shallow clone at the very least. If you're spinning up many agents in the cloud this becomes a bottleneck. So not really that downloading things is a bottleneck, it's that agents need to download way less to make the same decisions and changes.

Re: Show HN: Oak – Git alternative designed for agents

#205

Oh, it’s “for agents,” you say. Well, I’m sure that makes all the difference.

It's also made for humans as well :) We have some nice TUI stuff in the CLI that you might like. Check it out if you're curious and let me know if you have any thoughts.

Re: Show HN: Oak – Git alternative designed for agents

#206

The focus on speed is interesting here, it's something I think less and less about with agents. I'm not waiting for git operations, and at the rate agents run it's just not a major factor. Agentic development is all about throughput, not latency. This looks interesting regardless, but I do wonder if the latency focus is the wrong way to sell this.

True, I do wonder if we focused more on the parallelism aspect with mounts that it would resonate with people more. Thanks for the thoughts!

Re: Show HN: Oak – Git alternative designed for agents

#207
post #153

This project falls into the classic "More" trap. Agents are fast at creating code so let's make them even faster (more). However any rational observer can see that the bottlenecks for throughput are no longer at this segment of the process. Human decision-making, communications and awareness are the key bottlenecks, not code generation and commit speed, by several orders of magnitude. And I think that's a good thing…

Do you think it's possible in the next few years or so that agents will improve to the point that some of approval work can be offloaded to them?

Re: Show HN: Oak – Git alternative designed for agents

#208

Earlier quoted context omitted.

> I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly. I highly doubt that your tool is like this: > git branch -vv | grep ': gone]'| grep -v "*" | awk '{ print $1; }' | xargs -r git branch -d Or: > ffmpeg -i main_course.mp4 -i reaction_cam.mov \ -filter_complex \ "[1:v]scale=480:27…

It’s really wild watching LLMs construct those calls. They batch so many different checks and stuff into a single tool call, delimit them with markers, etc. The crazy thing to me is that this kind of “composition of small tools to create something bigger” is the biggest vindication of the Unix philosophy I can think of. I have to wonder how much of that behavior was trained into the model and how much it is the secre…

Totally breaks the permission model in Claude Code.

Re: Show HN: Oak – Git alternative designed for agents

#209
post #176

Earlier quoted context omitted.

Git has worktrees, which provide a means of creating branch linked physical working directories. I built in UI assistance for creating worktress associated with the agent session in https://www.agentkanban.io (an agent integrated kanban board for use with copilot / claude and vs code). I agree, I would rather try and make use of a tool that the agent is already familiar with, unless it's missing features that the age…

Yes but each of these require an entire materialization of all files and assets which for some repos can be a non-trivial amount of waiting time and disk space when you are doing lots of things in parallel. You can also use worktree workflow in oak by cloning into separate spaces. This is sometimes ideal for even our own workflows depending on context, I personally do it often. Mount can be super advantageous in a lo…

Running builds on FUSE all the time is likely more wasteful than cloning a typical repo once per session.

Re: Show HN: Oak – Git alternative designed for agents

#210
post #153

This project falls into the classic "More" trap. Agents are fast at creating code so let's make them even faster (more). However any rational observer can see that the bottlenecks for throughput are no longer at this segment of the process. Human decision-making, communications and awareness are the key bottlenecks, not code generation and commit speed, by several orders of magnitude. And I think that's a good thing…

Do you think it's possible in the next few years or so that agents will improve to the point that some of approval work can be offloaded to them?

That’s like asking if a relationship can improve to a point that communication is no longer necessary. It misses the point.
Post reply on HN