Wow that interface tingles something inside my brain.
A good tingle or bad tingle? haha
Show HN: Oak – Git alternative designed for agents
151–160 of 216 posts
Re: Show HN: Oak – Git alternative designed for agents
#152The 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.
Re: Show HN: Oak – Git alternative designed for agents
#153This 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 if we want to avoid mass-psychosis.
Re: Show HN: Oak – Git alternative designed for agents
#154[flagged]
Re: Show HN: Oak – Git alternative designed for agents
#155Interesting to see more dev tools designed specifically for agent
workflows. I've been building a local tool that monitors AI agent
API calls and costs in real time — the "I have no idea what my
agent just did" problem feels like it's only going to get bigger
as agentic coding tools spread.
Re: Show HN: Oak – Git alternative designed for agents
#156Re: Show HN: Oak – Git alternative designed for agents
#157Oh, it’s “for agents,” you say. Well, I’m sure that makes all the difference.
Re: Show HN: Oak – Git alternative designed for agents
#158Earlier quoted context omitted.
I do wonder how far you can make git work like google3. Partially why I'm making Oak is because I think it might be hard to impossible to implement the necessary features for monorepos to work correctly in Git. I don't doubt that it can be done, I do wonder how it will feel though.
If the goal is just to make it work like google3, then hg and jj and sapling can all already achieve this. There’s no need for a new contender here. The differentiation must come from something else. But of course at Google the file system part (CitC) is a layer beneath the version control system and is shared across different vcs tools.
I do think hosting is an important part of the VCS story. I agree that hg and jj and sapling are capable of being front ends to a google3 like backend GitHub like thing to support it (Google has this internally for jj). Of course some people are working on hosting solutions for these but it feels wrong to me that hosting platforms and their underlying VCS are not made by the same team. IMO people like google3 so much because it’s one integrated system which is the approach I’m trying with Oak.
Re: Show HN: Oak – Git alternative designed for agents
#159Anything "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…
> Models know git because there's a monstrous amount of git in their training data. Models never heard of a new thing "for agents", so you have to teach them to use it via skills and docs. Another option: when model invokes standard tool, rewrite the invocation to newfangled tool. Bunch of ways of doing it: (a) Invocation of standard tool returns error saying to use newfangled tool instead (b) Invocation of standard…
Options (a) and (b) add more bloat to the model’s context window and option (c) seem to reduce to having similar functions that already existed. There is also the option to trick the LLM that it’s using the old function exactly as-is, while the harness abstracts away a completely different methodology. Cursor often does exactly this: they use an internally built vectorized search when the model calls the default “find” bash command. The LLM is none the wiser that the function’s implementation is completely different.
Regardless, in any of these cases, the implementation for any of these above options may be vastly superior to the “naive” implementation for agents — but then the parent comment here is right that an engineer would need to justify their implementation to users, not just make a loud conjecture. It’s a non-trivial claim to say that a bespoke solution not present in tool-use training and accounting for context-rot would result in a better performing model. Moreover, justifying an agent-specific efficiency gain that humans wouldn’t benefit from makes the claim even more non-trivial. Using Sagan’s razor, it’s then reasonable for people to ask for a comparably non-trivial amount of evidence.
Re: Show HN: Oak – Git alternative designed for agents
#160Earlier quoted context omitted.
I do wonder how far you can make git work like google3. Partially why I'm making Oak is because I think it might be hard to impossible to implement the necessary features for monorepos to work correctly in Git. I don't doubt that it can be done, I do wonder how it will feel though.
If the goal is just to make it work like google3, then hg and jj and sapling can all already achieve this. There’s no need for a new contender here. The differentiation must come from something else. But of course at Google the file system part (CitC) is a layer beneath the version control system and is shared across different vcs tools.
[deleted]