I don't think your Github example is accurate. The vast majority of developers started using git after Github became a thing. They may have used svn or another type of collaboration system before, but not git. And the main reason they started using git is because Github was such massive value on top of git, not because git was so amazing.

It seems at this point, everyone and their mother, i.e. "We", are building the "tools" for which "we" mostly hope that the VC money will materialise. Use-cases are not important - if OpenAI can essentially work with Monopolly money, whey can´t "we" do it too?

I do not think that's how it worked out for GitHub: I'd rather say that Git (as complex as it was to use) succeeded due to becoming the basis of GitHub (with simple, clean interface).

At the time, there were multiple code hosting platforms like Sourceforge, FSF Savannah, Canonical's Launchpad.net, and most development was still done in SVN, with Git, Bazaar, Mercurial the upstart "distributed" VCSes with similar penetration.

Of the thousands, a handful will prevail. Most of it is vaporware, just like in any boom. Every single industry has this problem; copy-cats, fakes & frauds.

"Buy my fancy oil for your coal shovel and the coal will turn into gold. If you pay for premium, you don't have to shovel yourself."

If everything goes right, there won't be a coal mine needed.

I'd bet that less people had their source code on git in 2008 than the number of developers using the various coding agents today. And the open-source project that we published today hooks into the existing workflow for those developers, in Claude Code and in Gemini CLI. Time will tell the rest. We will publish regular updates and you can judge us on those results.

The hype is the product

the workflow exists

my code is 90% ai generated at this point

We are building tools and hoping an exit materializes. There’s so much funny money in AI right now, getting life-altering money seems easily attainable

HN is full of AI agents hype posts. I am yet to see legitimate and functional agent orchestration solving real problems, whether it is scale or velocity.

> Entire, backed by a $60 million

This is the point of that post and helpfully it was added at the top in a TL;dr and was half of that t sentence TL;dr. Will succeed or not? Well, that's a coin toss, always been.

I mean, pretty much all big startups begin as "niche" things that people might care about later. Tesla, Airbnb, Twitch... and countless failures too. It's just how the game is.

What kind of barrier/moat/network effects/etc would prevent someone with a Claude Code subscription from replicating whatever "innovation" is so uniquely valuable here?

It's somewhat strange to regularly read HN threads confidently asserting that the cost of software is trending towards zero and software engineering as a profession is dead, but also that an AI dev tool that basically hooks onto Git/Claude Code/terminal session history is worth multiples of $60+ million dollars.

I currently develop small utilities with the help of AI, but am far from vibe coding or using agents. I review every single suggestion and do some refactoring at each step, before any commit (sometimes heavy refactoring; sometimes reorganizing everything).

In my experience LLMs tend to touch everything all of the time and don't naturally think about simplification, centralization and separation of concerns. They don't care about structure, they're all over the place. One needs to breathe on their shoulders to produce anything organized.

Maybe there's a way to give them more autonomy by writing the whole program in pseudo-code with just function signatures and let them flesh it out. I haven't tried that yet but it may be interesting.

Sure... you `git add` the context text generated by AI and `git commit` it, could be useful. Is that worth 60 million?

For the last three or four months, what I've been doing is anytime I have Claude write a comment on an issue, it just adds a session ID, file path and the VM it is on. That way, whenever we have some stuff that comes up, we just search through issues and then we can also retrace the session that produced the work and it's all traceable. In general, I just work through gitea issues and sometimes beads. I couldn't stand having all these MD files in my repo because I was just drowning in documentation, so having it in issues has been working really nicely and agents know how to work with issues. I did have it write a gitea utility and they are pretty happy using/abusing it. Anytime I see that they call it in some way that generates errors, I just have them improve the utility. And by this point, it pretty much always works. It's been really nice.

I haven't read the article yet but this conversation reminds me of Docker. Lots of people "didn't get it." I told them at the time: if you don't get it you aren't ready for it yet so don't worry about it. When you do need it, you'll get it and then you'll use it and never look back. Look at where we are with containers now.

Wow, read through the comments and you weren't joking. I attribute this to crossroads of "this release is v0.1 of what we are building" and the HN crowd who have been scrolling past 120 AI frameworks and hot takes daily and have no patience for anything that isn't immediately 100% useful to them in the moment.

I find the framing of the problem to be very accurate, which is very encouraging. People saying "I can roll my own in a weekend" might be right, but they don't have $60M in the bank, which makes all the difference.

My take is this product is getting released right now because they need the data to build on. The raw data is the thing, then they can crunch numbers and build some analysis to produce dynamic context, possibly using shared patterns across repos.

Despite what HN thinks, $60M doesn't just fall in your lap without a clear plan. The moat is the trust people will have to upload their data, not the code that runs it. I expect to see some interesting things from this in the coming months.

I know about "the entire developer world has been refactored" and all, but what exactly does this thing do?

Runs git checkpoint every time an agent makes changes?

100% agree because there’s a lot of value in understanding how and why past code was written. It can be used to make better decisions faster around code to write in the future.

E.g., if you’ve ever wondered why code was written in a particular way X instead of Y then you’ll have the context to understand whether X is still relevant or if Y can be adopted.

E.g., easier to prompt AI to write the next commit when it knows all the context behind the current/previous commit’s development process.

A year ago I added memory to my Emacs helper [0]. It was just lines in org-mode. I thought it was so stupid. It worked though. Sort of.

That's how a trillion dollar company also does it, turns out.

0: https://github.com/karthink/gptel

ehhhh is it really that useful though? Sounds way more noisy than anything, and a great way to burn through tokens. It's like founding a startup to solve the problem of people squashing their commits. Also, it sounds like something Claude Code/Codex/etc could quickly add an extension for.

Maybe use critical thinking instead of a mindless dismissal?

The fact that you aren't haven't offered a single counterargument to any other posters' points and have to resort to pearl-clutching is pretty good proof that you can't actually respond to any points and are just emotionally lashing out.

This is literally what claude code already does minus the commit attachment. It’s just very fancy marketing speak for the exact same thing.

I’m happy to believe maybe they’ll make something useful with 60M (quite a lot for a seed round though), but Maybe not get all lyrical about what they have now.

I see the utility in this as an extension to git / source control. But how do VCs make money of it?

I built out the same thing in my own custom software forge. Every single part of the collaborative development process is memoized.

[flagged]

I have CURRENT_TASK.md that does more or less the same thing. It also gets committed to git. So I guess that’s entire? Wish I’d realized I was sitting on a 60M idea…

Maybe he prefers to set someone else’s money on fire.

I am going lower level - every individual work item is a "task.md" file, starts initially as a user ask, then add planning, and then the agent checks gates "[ ]" on each subtask as it works through it. In the end the task files remain part of the project, documenting work done. I also keep an up to date mind map for the whole project to speed up start time.

And I use git hooks on the tool event to print the current open gate (subtask) from task.md so the agent never deviates from the plan, this is important if you use yolo mode. It might be an original technique I never heard anyone using it. A stickie note in the tool response, printed by a hook, that highlights the current task and where is the current task.md located. I have seen stretches of 10 or 15 minutes of good work done this way with no user intervention. Like a "Markdown Turing Machine".

  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "mix format ${file} 2>/dev/null || true"
          }
        ]
      }
    ],
    "TaskCompleted": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "reminder: run mix test if implementation is complete"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "Check if all tasks are complete. If not, respond with {\"ok\": false, \"reason\": \"what remains to be done\"}."
          }
        ]
      }
    ]
  },

Me too. I've been using spec-kitty [0], a fork of Spec Kit. Quite amazing how a short interview on an idea can produce full documents of requirements, specs, tasks, etc. After a few AI projects, this is my first time using spec driven development, and it is definitely an improvement.

[0]: https://github.com/Priivacy-ai/spec-kitty

Task management is fundamentally straightforward and yet workflow specific enough that I recommend everyone just spend a few hours building their own tools at this point.

Beads is a nightmare.

To add to your comment, I think the next logical question is, “then what?” Surely one can’t build a sustainable business storing these records alone.

> won't it make just doing a "git checkout" start to be really heavy?

not really? doesn't git checkout only retrieve the current branch? the checkpoint data is in another branch.

we can presume that the tooling for this doesn't expect you to manage the checkpoint branch directly. each checkpoint object is associated with a commit sha (in your working branch, master or whatever). the tooling presumably would just make sure you have the checkpoints for the nearby (in history) commit sha's, and system prompt for the agent will help it do its thing.

i mean all that is trivial. not worth a $60MM investment.

i suspect what is really going on is that the context makes it back to the origin server. this allows _cloud_ agents, independent of your local claude session, to pick up the context. or for developer-to-developer handoff with full context. or to pick up context from a feature branch (as you switch across branches rapidly) later, easily. yes? you'll have to excuse me, i'm not well informed on how LLM coding agents actually work in that way (where the context is kept, how easy it is to pick it back up again). this is just a bit of opining based on why this is worth 20% of $300MM.

if i look at https://chunkhound.github.io it makes me think entire is a version of that. they'll add an MCP server and you won't have to think about it.

finally, because there is a commit sha association for each checkpoint, i would be worried that history rewrites or force pushes MUST use the tooling otherwise you'd end up screwing up the historical context badly.